Linux System Administration Lx03

Linux System Administration (Course Code LX03)

Student NotebookERC 2.0

Worldwide Certified MaterialIBM Learning Services

V1.2.2.2

over

Student Notebook

The information contained in this document has not been submitted to any formal IBM test and is distributed on an “as is” basis withoutany warranty either express or implied. The use of this information or the implementation of any of these techniques is a customerresponsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. Whileeach item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results willresult elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk. The originalrepository material for this course has been certified as being Year 2000 compliant.

© Copyright International Business Machines Corporation 2001, 2002. All rights reserved.This document may not be reproduced in whole or in part without the prior written permission of IBM.Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to restrictionsset forth in GSA ADP Schedule Contract with IBM Corp.

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:

Intel and Pentium are trademarks of Intel Corporation in the United States, other countries, or both.

Linux is a registered trademark of Linus Torvalds in the United States and other countries.

Windows is a trademark of Microsoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Other company, product, and service names may be trademarks or service marks of others.

AIX Hummingbird IBMPerform XT 400

June 2002 Edition

Student NotebookV1.2.2

TOC
Contents
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

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

Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

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

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

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

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

© Copyright IBM Corp. 2001, 2002 Contents iii

Student Notebook

Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-26Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-27

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

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

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


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


TOC
Sample /etc/X11/XF86Config-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16Starting X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17Stopping X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19Session Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20X Networked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-21X Applications Networked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22Applications over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23X Sessions Networked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25X Sessions over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26Chooser Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28Font Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-29Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-31Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32
Unit 7. Block Devices, RAID and LVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2Block Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3Block Device Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4Floppy Disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5Hard Disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6Hard Disk Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8Partitioning Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10RAM Disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11The "loop" Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13Logical Volume Management (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14Logical Volume Management (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16LVM Implementation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17Physical Volume Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18Volume Group Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19Logical Volume Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-21Additional LVM Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-24RAID Levels (1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-25RAID Levels (2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27Linux RAID Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-28Linux Software RAID Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29Additional RAID Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-30Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-32Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-33

Unit 8. Filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2What is a File? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3What is a Filesystem? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4Filesystems Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5A Typical UNIX Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6Superblock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7Inodes (Index Nodes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8


© Copyright IBM Corp. 2001, 2002 Contents v

Student Notebook

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

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

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


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


TOC
Unit 11. Scheduling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3Vixie Cron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4User Crontab Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5crontab Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-7System crontab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-9Anacron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10/etc/anacrontab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-12batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-14Controlling at Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-15Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-16Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-17
Unit 12. Backup and Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2Why Back Up? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3Devising a Backup Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4Backup Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5Sample Backup Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6Backup Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-8Default Backup Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10tar Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-11cpio Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13dump Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-15Other Backup Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16Document Backup Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-17Additional Backup Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-19Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-20Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-21

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


© Copyright IBM Corp. 2001, 2002 Contents vii

Student Notebook

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

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

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


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


TOC
Unit 17. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-2Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-3Identifying the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-5strace, ltrace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-7Fixing the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-8Rescue Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-10Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-12Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-13
Unit 18. Policies and Procedures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-1Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-2About Your Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-3The Dilemma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-4Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-5User Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-6Administrator Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-8Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-10Procedure Handbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-11Management of System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-12Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-14Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-15

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


© Copyright IBM Corp. 2001, 2002 Contents ix

Student Notebook


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


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:

Intel and Pentium are trademarks of Intel Corporation in the United States, other countries, or both.

Linux is a registered trademark of Linus Torvalds in the United States and other countries.

Windows is a trademark of Microsoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Other company, product, and service names may be trademarks or service marks of others.

AIX Hummingbird IBMPerform XT 400


© Copyright IBM Corp. 2001, 2002 Trademarks xi

Student Notebook


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


ref
Course Description
Linux System Administration

Duration: 5 days

Purpose

The purpose of this course is teach experienced Linux users the techniques, methods and policies used in Linux System Administration.

Audience

The intended audience for this course are experienced Linux users who want to become the administrator of one or more Linux servers.

Prerequisites

• IBM Linux course LX02 (Linux Power User)

• Practical experience in running Linux as a user

Objectives

After completing this course, you should be able to:

• Physically plan and manage the system and its environment

• Install Linux from a network install server

• Manage system startup and shutdown

• Select and use system administration tools when appropriate

• Use packaging tools to create, install and deinstall packages

• Configure and manage the X Window System

• Manage hard disks, partitions, RAID and LVM

• Create and manage filesystems

• Recompile the Linux kernel

• Perform memory management

• Use scheduling tools

• Create and restore backups

• Perform user administration


© Copyright IBM Corp. 2001, 2002 Course Description xiii

Student Notebook

• Apply user-level security

• Manage logging

• Configure and manage printers

• Troubleshoot Linux problems

• Discuss policies and procedures

Contents

• Physical system management and planning

• Advanced Linux installation

• System startup and shutdown

• System Administration tools

• Packaging tools

• X Window System

• Managing hard disks, partitions, LVM and RAID

• Filesystems

• Kernel compilation

• Memory management

• Scheduling

• Backup and restore

• User administration

• User-level security

• Logging

• Printers

• Troubleshooting

• Policies and procedures


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


ref
Agenda
Day 1

Unit 1 - Physical Planning and Maintenance Exercise 1- Physical Planning and Maintenance Unit 2 - Advanced Linux installation Exercise 2 - Advanced Linux installation Unit 3 - Startup and Shutdown Exercise 3 - Startup and Shutdown Unit 4 - System Administration Tools Exercise 4 - System Administration Tools

Day 2

Unit 5 - Packaging Tools Exercise 5 - Packaging Tools Unit 6 - X Window System Exercise 6 - X Window System Unit 7 - Block Devices, RAID and LVM Exercise 7 - Block Devices, RAID and LVM Unit 8 - Filesystems Exercise 8 - Filesystems

Day 3

Unit 9 - Kernel Compilation Exercise 9 - Kernel Compilation Unit 10 - Memory management Exercise 10 - Memory management Unit 11 - Scheduling Exercise 11 - Scheduling

Day 4

Unit 12 - Backup and Restore Exercise 12 - Backup and Restore Unit 13 - User Administration Exercise 13 - User Administration Unit 14 - User level security Exercise 14 - User level security


© Copyright IBM Corp. 2001, 2002 Agenda xv

Student Notebook

Day 5

Unit 15 - Logging Exercise 15 - Logging Unit 16 - Printers Exercise 16 - Printers Unit 17 - Troubleshooting Exercise 17 - Troubleshooting Unit 18 - Policies and procedures


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

Student NotebookV1.2.2 BKM2MIF

Uempty
Unit 1. Physical Planning and Maintenance
What This Unit Is About

This unit discusses various subjects that have to do with physically planning and managing your Linux systems.

What You Should Be Able to Do

After completing this unit, you should be able to:

• Discuss issues to be considered when planning the physical installation of the system

• List best practices for physical maintenance

How You Will Check Your Progress

Accountability:

• Checkpoint questions


© Copyright IBM Corp. 2001, 2002 Unit 1. Physical Planning and Maintenance 1-1

Student Notebook

Figure 1-1. Objectives LX032.0

Notes:

��

��

��

��


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


Uempty

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

Notes:

When planning for the physical installation, several issues will have to be considered. These will be covered in the subsequent visuals.

��

��

��

��

��

��

��

��

!��



Student Notebook

Figure 1-3. Computer Room LX032.0

Notes:

In most cases, servers will be placed in separate computer rooms. This might be a simple basement closet, or a high-tech computer room with so much glamour that your CEO is giving all customers a tour around it.

Placing servers in a separate room has distinct advantages:

• Computer rooms will typically have raised floors, overhead cable racks or other features that make it easy to keep the spaghetti of network, power and other cables organized and out of the way, while still keeping them easily accessible if needed.

• Having a separate computer room allows you to customize your settings for the air conditioning to the optimum settings for your computer equipment. This is not necessarily the optimum settings for human beings.

• Computer rooms typically only have a few access points, which can be equipped with additional access control systems (ranging from simple locks on doors to sophisticated biometric devices). This helps keeping unauthorized people out. This is important since

��

" ��#��

��#� ��$��%��%�� #�� &��

��#� ��




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

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

Notes:

Most computer-related equipment on the market today can be bought in two variants: rack-mounted and stand-alone.

Rack-mounted means that the physical dimensions and external fittings are optimized so that the system can fit in an industry-standard, 19 inch wide rack. These racks are typically mounted in an enclosure which also contains rails for convenient mounting of various cables, and contain power strips. Most racks also come with front and back doors (glass or perforated steel) with locks to make console access to systems harder.

A variety of hardware is currently available in rack-mounted form: servers, server blade enclosures, network equipment, monitors, keyboards, mice, KVM (keyboard video mouse) switches, UPS equipment etc. There are even manufacturers who have combined a KVM switch, an LCD monitor, a mouse and a keyboard in a 19 inch wide, 1 inch high drawer. When pulled out of the rack, the LCD panel pops up to a vertical position. This saves you a lot of space in (or next to) your rack, while still allowing console access to a system.

�� !�� "��

" �� '()*+��%�� #��"�,��

��#��#�� -��%��.�� /� ��%��01/��2�

��#� �� 3��3��%��%��

��#� ��$��%,�� .�� 4� ��#�� #� �� %��




Uempty
The advantages of rack-mounting all your equipment is obvious:
• Rack-mounting equipment saves a lot of floor space. The footprint of a typical rack is about 1 m2, and a typical rack is nearly 2 m tall. This means that a typical rack can house 10-40 servers, depending on the height of each server. Server blade enclosures (boxes 3 inches high containing 18 blades, each blade being a full server) even allow you to put 400 or more servers in one rack. Having to store the same amount of servers on the floor or on tables would require far more floor space.

• Since racks typically come with lockable front and back doors, it is easier to limit physical access to the systems. This is especially useful in large organizations where one computer floor might be used by several departments.

• Since racks typically come with power strips and fixtures for network cables, it is far easier to keep them tidy and organized. Plus, racks typically have an open bottom which allows you lead cabling straight under the raised floor, instead of having to string it out the back of a standalone server through a hole in the floor.

• Last but no less important: Having a whole computer room full of rack-mounted equipment looks far better than having a computer room full of different sized and colored standalone servers.

But there are several disadvantages as well:

• Rack-mounted equipment, especially servers, are generally a little more expensive than comparable stand-alone servers. The reason for this is economics of scale: Most servers sold are still stand-alone servers, which therefore benefit of bulk production optimization.

• Physical access to systems in a rack is usually less convenient. This is especially apparent when having to replace hardware in the systems. Instead of just pulling a stand-alone server forward, you typically need to first take the whole server out of the rack, before you can do any hardware maintenance on it.

• The last disadvantage is usually forgotten, but is really important to consider: A rack full with computer equipment might need floor reinforcement.

A typical building floor is designed and constructed to be able to carry about 300 kg/m2. A full rack, which has a footprint of about 1 m2 can easily weigh more than 500 kg. If you plan on dense-packing your racks, make sure to consult a building engineer first to verify that your floor is strong enough to carry the load.



Student Notebook

Figure 1-5. Power Considerations LX032.0

Notes:

Just about every device used in the IT world consumes electric power to a certain extent. The amount of power that is consumed by a devices is measured in "Watt". Obviously, the total amount of power consumed should not be more than the amount of power that the power grid can handle.

Power usually comes into your building through a high-capacity cable. To limit the damage that a short-circuit in your building might cause, you do not connect your devices directly to this cable, but shield them with fuses or circuit breakers. A "circuit" is simply all electric cabling that is protected by the same fuse or circuit breaker.

Fuses and circuit breakers come in various shapes and sizes, but also in various current levels ("Amps") at which they will pop or blow.

In the US, the end user power grid operates at 120 Volt and is typically protected by 20A fuses or breakers. This means that the total power consumption of all devices in a circuit may not exceed 2400 Watt.

��#��

5�� #��

�� *��*�� 4��1��6��

2 ��(781678��9�7:88��3��7:816(;��9�<=:8��

!� �� %�� >

!� �� 2 � �� '2� +�� %��#�� %��%��

2��,��0��(8,<8�� ?�� #��




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

Figure 1-6. Air Conditioning LX032.0

Notes:

Most computer rooms will need to be equipped with an air conditioner. This air conditioner is needed for two things, basically:

• Maintaining a stable temperature.

• Maintaining a constant humidity.

It is important that computer equipment is kept at a constant temperature, typically 17-20 degrees Celsius (64-68 degrees Fahrenheit), because fluctuating temperatures might cause damage from expansion/contraction of components, and high temperatures might lead to overheating of internal components. (Note that the interior of a computer is typically a few to ten degrees higher than the exterior.)

It is equally important that the humidity in your computer room is kept between about 40 to 60%. If the humidity is too low, then static electricity might build up and cause damage. If the humidity is too high, then condensation might occur, which might lead to short-circuiting of equipment.

$��

/��

"��(@,78!�';:,;=�+2 ��4� �� A�� #��

"��:8B,;8B��

�A!�� *5�2*��*�� *? ��*��*�� <>:(7�5�2�� ? ��*�� *��.��(7�888�5�2




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



Student Notebook

Figure 1-7. Fire Detection and Suppression System LX032.0

Notes:

Your computer room will almost certainly need to be equipped with a fire detection and suppression system. This system usually consists of two parts.

The first part of the system is aimed at detecting smoke and fire. Smoke detectors typically are able to detect small particles of pure carbon in the air, while carbon monoxide detectors are able to detect carbon monoxide molecules. Both are a product of fire. If you have a raised floor and/or lowered ceilings, don't forget to place detectors in these spaces too, and test them regularly.

The second part of the system is aimed at suppressing a fire. How this is done depends a lot on the type of equipment installed in your computer room, local regulations and financial considerations. It is best to consult your local fire department for the best solution.

Since most of the fires in computer rooms are caused by electricity, it is a good idea install a master switch somewhere at an accessible place which terminates the power to the whole computer room at once. This might kill an electrical fire instantly, and might prevent a non-electrical fire into becoming one.

%��&�� "�� "��

/�%�� %�� 4�� #��

!� �� C�!?7C�" ��C!� ��

!� ��




Uempty

Figure 1-8. Best Practices LX032.0

Notes:

When physically maintaining your equipment, there are a few things to keep in mind.

The first thing you need to remember is that static electricity might cause damage. Memory chips are especially vulnerable to this, but other components are not totally immune too. A few simple guidelines can help you prevent damage from static electricity though:

• Make sure that all components are properly grounded.

• Before putting your hands inside a box to replace components there, make sure that you yourself are discharged. This can simply be done by touching the outer case or a grounded connector for a second or so. Do not move or shuffle your feet afterwards though.

• Almost all replacement computer components come in anti-static bags. Leave components in these bags for as long as possible. Before opening the bags, make sure they are discharged as well, for instance by laying them on the (grounded) metal case of your server, or by holding them in your hand while touching something else that is grounded.

��

5�� D�� A�� ,�� #��!� �� ,�� ,��

2�� &��A��A�� .��

!��%��

0��4��



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




Uempty

Figure 1-9. Checkpoint LX032.0

Notes:

Write down your answers here:

1.

2.

3.

��

Rack-mounted equipment is generally a little more expensive than regular, non-rackmounted equipment.

You have 25 servers, each rated at 450 watt. How many tons of air conditioning do you need for this?

a. 38,385b. 3.20c. 11,250d. None of the above

What different methods do you use to limit the risk of static electricity damage to a minimum?______________________________________________

______________________________________________

______________________________________________

1)

2)

3)

T/F



Student Notebook

Figure 1-10. Unit Summary LX032.0

Notes:

' ��"��

/�� #� �� %,�� .��

��4�� 4��

�� .�� %��

�� E�� #��




Uempty
Unit 2. Advanced Linux Installation

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



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


Accountability:

• Checkpoint questions • Machine exercises


© Copyright IBM Corp. 2001, 2002 Unit 2. Advanced Linux Installation 2-1

Student Notebook


Notes:

��

��

�� %��

�� %�� #��

��%��%��




Uempty

Figure 2-2. Network Installations LX032.0

Notes:

Most Linux systems are installed from the distribution CD-ROMs (or DVDs). This is a convenient method if you only need to install one or a few systems, but quickly becomes tedious if you need to install 10 or more systems, especially if each system has to be installed with the same settings.

More advanced installation methods exist which are convenient for these situations, and in all but a few cases, this comes down to network installations, where the RPMs to be installed are downloaded from the network.

Various network protocols exist to retrieve the installation RPMs, and the protocols that are supported depends on your distribution. Support might be included for NFS, FTP, HTTP and SMB.

An obvious requirement for a network-based install is that somewhere on the network you need to configure a network install server, which holds all the RPMs for your distributions.

Another requirement is that your systems to be installed are equipped with a network adapter, which is supported by your network boot diskette. If your network adapter is not

(��#��

" �� $�/�� %

-��%�� -� �� /5

$�.�� %�� #��

2��.�� %,� ��%��"�� %�� %�� %�� %��



Student Notebook

supported by the boot diskette, you might also need an additional diskette which contains the device support in the form of Linux kernel modules.

A Red Hat system requires a special "bootnet.img" diskette to perform a network install, while a SuSE system can use the regular "bootdisk" for both CD-ROM and network installs.




Uempty

Figure 2-3. Network Install Server LX032.0

Notes:

A Network Install Server is typically a Linux/UNIX server, although Windows NT/2000 servers can sometimes also be used. The content of all relevant CDs is copied to disk and made available. It is a good idea to use a naming scheme that allows multiple versions of multiple distributions to be copied to disk.

Almost all network install servers export the CDs via NFS, but (anonymous) FTP, HTTP and SMB may also be used.

If you decide to use NFS, be aware of the fact that the newer distributions typically use NFS version 3, while older distributions typically use NFS version 2. This might lead to compatibility problems, which can be solved easily by forcing the NFS server to always use version 2.

If you decide to offer anonymous FTP installs, then you need to create your directory structure somewhere in the /var/ftp directory, since the ftp daemon will perform a chroot to this directory when anonymous FTP is requested.

(��#�� "��

�� 4A2-"F��#��

!� �� #� ��!��%2�� #�� A�� 4��>�>�A�4��A��@8��A�4��A��@(��A�4��A��@7�

��-� ��'� � ��+�� /55��-� �#>7�#�>�#><��G�� A#��A��A

��$��$��A�� A��

�� 3��A��%�A�� > 6��



Student Notebook

If you decide to offer HTTP installs, you can simply create a symbolic link from your document_root directory to the directory where your CDs are copied into, as long as "FollowSymLinks" is set in your web server configuration.

After creating the installation directory, you need to copy the contents of the relevant CDs to that directory. This needs to be done with all preservations of permissions, users and so forth intact, and can best be done with the cp -a command.

For a Red Hat distribution, make sure you copy at least the RedHat/ and images/ directories. For a SuSE distribution, make sure you copy at least the suse/ and disks/ directories and all .S* files.




Uempty

Figure 2-4. Red Hat "Kickstart" Installs LX032.0

Notes:

"Kickstart" is Red Hats method of automating installations. It involves creating a ks.cfg file, which contains three sections:

• The first section, which starts at the top of the file, contains the answers to all questions of the installation process. For instance, if the statement lang en_US is present in the kickstart file, the question "What language do you want to use during the installation process?" will not be asked, but US English is used.

• The second section starts with the %packages identifier. It contains a list of all packages (RPMs) to be installed. Just as with the install process itself, it can also use the package groups that are defined in the RedHat/base/comps file. These package groups are identified with an ampersand, for instance "@ Networked Workstation".

• The third section starts with the %post identifier. It contains a series of shell commands that are executed once the installation has finished. These commands are executed on the newly installed system, with all paths, networking and so forth intact. This means that virtually anything is possible, including mounting remote filesystems, creating user accounts, and so forth.

��)��*+��*��

$��

" #��#��*%�>��*�� " �� .�� B��%�� %��A��%�� B��B�� ,� �� 4��

%�>�� >�� -� ��#��

-� ��.��!��#��

0��%�� !�� !��,�� 4��,��

3�� 4>��



Student Notebook

It is also possible to create a %pre section, which is executed before the installation starts. This is generally used only to implement custom partition schemes.

An example kickstart file will look like this:

install nfs --server 10.0.0.1 --dir /export/rh73 lang en_US langsupport --default en_US.iso885915 en_US.iso885915 keyboard us mouse generic3ps/2 --device psaux skipx network --device eth0 --bootproto dhcp rootpw ibmlnx firewall --disabled authconfig --enableshadow --enablemd5 timezone Europe/Amsterdam bootloader clearpart --all part /boot --fstype ext3 --size=32 part /usr --fstype ext3 --size=2000 part / --fstype ext3 --size=150 part /var --fstype ext3 --size=150 part /home --fstype ext3 --size=50 part /tmp --fstype ext3 --size=100 part swap --size=64 %packages @ Network Support @ Printing Support @ Classic X Window System @ X Window System @ GNOME @ KDE @ Software Development @ Kernel Development @ Network Server %post adduser tux1 echo tux1 | passwd --stdin tux1 adduser tux2 echo tux2 | passwd --stdin tux2




Uempty
The kickstart configuration file can be stored on the bootnet.img diskette, or can be stored on an NFS server. Kickstart installs are then started by typing linux ks (when ks.cfg is located on an NFS server) or linux ks=floppy (when ks.cfg is located on floppy).
When your ks.cfg file is located on an NFS server, then you also need to have a DHCP server to supply the system to install with its IP address. The DHCP server may also need to supply the system to install with two other bits of information:

• The NFS server where the kickstart file is located. This should be included in the "next-server" DHCP option. If no next-server is given, then it is assumed that the DHCP server is the NFS server too.

• The NFS exported directory where the kickstart file is located. This should be included in the "filename" DHCP option. If this filename ends with a forward slash (/), then it is assumed to be a directory in which the file <IP>-kickstart is located. This makes it possible to create different kickstart files for individual systems. If no filename is given, then it is assumed that "/kickstart/" is used.

To fully automate kickstart installations, modify the syslinux.cfg file on your bootnet.img disk, and make kickstart the default. You might also turn off the delay. The top of this file will then look like this:

default linux ks prompt 0

Kickstart files are usually updated by hand. Red Hat has released a tool which may help you generate initial kickstart files: ksconfig. This tool is available on the distribution CDs in the ksconfig RPM. As an added bonus, the Red Hat installer, Anaconda, generates a kickstart file for you based on the choices made during the installation process itself. This file is called /root/anaconda-ks.cfg.



Student Notebook

Figure 2-5. SuSE "autoinstall" Installs LX032.0

Notes:

SuSE also supports autoinstallations via CD-ROM and NFS. To configure a SuSE autoinstallation, create an "info" file on the bootdisk, with general settings regarding keyboard and so forth. This file may also include pointer to pre- and post install scripts. An example file looks like this:

Language: english Display: color Keytable: us Bootmode: Net IP: 10.0.0.2 Netmask: 255.255.255.0 Gateway: 10.0.0.1 Netdevice: eth0 Server: 10.0.0.1 Serverdir: /export/suse71 AUTO_FDISK 2

"�"-�*�� *� ��

� 3��

��!�$?/�� -� ��

" #��#�� *� ��*�� %�� D� �� %��>�� ,��

�� %�� -� ��#��

��,�� %�� -� ��#��

�� 4��.�� 4>��




Uempty
AUTO_FDISK_DISK /dev/hda FAST_INSTALL 2 AUTO_LILO 2 AUTO_NET 1 AUTO_NAME 1 AUTO_NAMESERVER 1 AUTO_SERVICES 1 AUTO_INSTALL $I:/suse/setup/descr/Minimal.sel INSTALL_WAIT 0 CDROM_DEVICE /dev/hdb NO_ASK_SWAP 1 END_MESSAGE 0 END_STARTUP 0 CHECK_DEPENDENCY 0 NEVER_STOP 1
You also need to create a file named part_NNNNN on your NFS server, in the directory suse/setup/descr. This file contains the partitioning scheme for any disk of size NNNNN MB and higher. Such a file might look like this:

/boot size=10 swap size=64 / size=0

Then, modify your syslinux.cfg file on the boot disk so that it looks like this:

default linux label linux kernel linux append initrd=initrd rw ramdisk_size=65536 linuxrc=auto timeout 1

Then, insert the boot disk into the system to be installed and switch it on.



Student Notebook


Notes:


1.

2.

3.

��

A network installs server needs to be a Linux system.

Which of the following install methods does not require a network server?

a. NFSb. SMBc. FTPd. CD-ROM

What are the two possible locations where a Red Hat Kickstart file can be stored?

______________________________________________

______________________________________________

1)

2)

3)

T/F




Uempty


Notes:

' ��"��

-��%�� #�� #� ��

�� %�� #��4��#�� #��-� ��

�� %�� %�� %��

$��*%��%��*�� 3�*�� *��



Student Notebook




Uempty
Unit 3. Startup and Shutdown

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



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


Accountability:

• Checkpoint questions • Exercises


© Copyright IBM Corp. 2001, 2002 Unit 3. Startup and Shutdown 3-1

Student Notebook

Figure 3-1. Unit Objectives LX032.0

Notes:

��

��

�� 4��

!� ��

!� ��%��

!� ��

!� �� #��

5�� 4�� ,��

�� 4��




Uempty

Figure 3-2. Linux Startup Flow LX032.0

Notes:

This visual gives an overview of the Linux startup flow. In the subsequent visuals we will cover the details of each step.

�� !�"��%��#

��

��

5"?

�� 4�%��

� ��

��



Student Notebook

Figure 3-3. Basic Input Output System LX032.0

Notes:

Every Intel PC has a Basic Input Output System, or BIOS for short. This is a little program which is stored in an EEPROM (Electrical Erasable Programmable Read Only Memory, sometimes also called non-volatile memory) on your motherboard. It is the first program that runs once the power is switched on. It does a number of basic tasks:

• It checks the memory

• It loads various options from non-volatile memory, for instance memory timing parameters and the order of boot devices. These options can be set by the user when pressing Del, F1, F2 or some other key while the memory is being tested.

• It checks for the availability of boot devices, and

• Loads the Master Boot Record of the first available boot device. This first sector is stored in memory and executed.

�� "��

!��%��

�� ,#��/�� ?��#��

!��%��#��%�!�,$?/��%�

��/��5��$��#�� 4��




Uempty

Figure 3-4. Master Boot Record LX032.0

Notes:

The Master Boot Record or MBR is the first sector (512 bytes) of the boot device. It contains two things:

• A boot loader program: Software to bootstrap the operating system.

• The partition table: A table which describes how the rest of the disk is split up into partitions.

On systems fresh out of the shop, the bootloader is a very simple program which was configured with the MS-DOS command fdisk /mbr. This program goes through the partition table and looks for a partition that is marked "active". The program then loads the first sector of this partition and starts it. This concept is known as chain-loading.

When using Linux, the MBR is traditionally set up by the Linux Loader (LILO). It is a little more elaborate than the usual MBR, in that it can prompt the user for the operating system to load, and any options to pass to that operating system. Then, it loads the selected operating system, passing the options as it starts it.

��

��#��

!� �� *��*��

1� ��

!� �� H��.��5��*��#�*��

�� 4��/5$�� "�?�� 4�� 4�%�� !� ��

-�� 4�� D$25�� "�?

D$� ��2 ��5��$��4�� 4��>>> ��*�� *��



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.




Uempty

Figure 3-5. The Linux Loader (LILO) LX032.0

Notes:

The Linux Loader (LILO) is the program that configures the MBR. It must be run as root with the lilo command. It parses the command line options, reads and checks the configuration file, and configures the MBR accordingly. The default configuration file is /etc/lilo.conf, but this can be overridden with the -C option. Other important options include:

-v Gives a verbose output.

-v -v Gives a very verbose output. In fact, you can have a total number of eight '-v's, giving you more and more output, until you literally drown in debug output.

-t Only tests the validity of the config file; does not actually write to the MBR.

-u, -U With this option, lilo restores an older backup copy of the MBR to the MBR on disk. This backup was made the first time lilo was run and is called /boot/boot.0300 or /boot/boot.0800.1

1 The numbers are the major and minor numbers of the device. 0300 is your first IDE disk, 0800 is your first SCSI disk.

/�� !��0��1

��/5$

� ��4�� !��"��#"�� ,# #��,#�,# #��#��,! �� I�� A��A��>�� ,� ��

$��

!��%��#��

!� ��/5$��



Student Notebook

It can be used to recover from a mangled MBR for instance, and can be used for a complete deinstall of Linux.2

For more details, refer to the lilo manual page (man lilo)

2 Note that to clean up the MBR, you can also run the fdisk /mbr command from MS-DOS or Windows. This undocumented featurerestores the MBR to a pristine state.




Uempty

Figure 3-6. /etc/lilo.conf LX032.0

Notes:

The /etc/lilo.conf contains a number of general options, followed by specific information for each operating system which lilo should be able to boot. The complete list of options is described in the lilo.conf manual page, but here's the shortlist:

boot The place where lilo should write the information to. /dev/hda means the MBR of the first hard disk.

map The map file to use. This map contains the layout of the current kernel and is used to trace back kernel problems/panics.

install Which second stage boot loader to install. There are several, but boot.b is the most commonly used.

message A file which may contain a short message. This message is then displayed before the boot:-prompt.

prompt Do not boot straight into the first OS, but give the user the possibility to choose an OS.

.��.��

$�%��

��%�$��

��%�$��$��$

��%�$��

��

��%&'

��%�$��(

��$��%��

��%��&

��%)��%��*+)

��,

��%��

��$��%��

��$��%��

��'/5$+

��%��

��7 ��

��

��%��? ��

�� '(A(8�+

��? �� 4��%��

A��A#�� &

�� A��#A��J��

�� ,� ��

��*�9(7=/*�� %��

�� ,�� 4��

�� *��*��

�"�?��>



Student Notebook

default Identifies the image that will be the default (if the user just hits Enter). If no default image is specified, the first image will be the default image.

timeout The timeout to wait for a user response, measured in deciseconds (1/10th of a second).

image The Linux kernel image to use

label The label given to this operating system. This is the text the user has to type when he or she wants to boot this OS.

root The root filesystem to be used for this OS.

append Default options to pass to the kernel when it boots, for instance the amount of memory in your system when Linux is not able to detect this correctly.

read-only Mount the root filesystem read-only, so that a proper fsck is possible. fsck will be covered later.

other The partition where another (non-Linux) operating system resides.

table The partition table to use for this operating system.

linear Use linear block addressing (LBA) mode instead of Cylinder/Head/Sector. This is typically needed for large disk drives.

lba32 Use linear block addressing (LBA) mode instead of Cylinder/Head/Sector, and use int32 BIOS calls. This allows lilo to overcome the 1024 cylinder/8 GB limit which is present in the original BIOS specification.

linear and lba32 are mutually exclusive.

password The (unencrypted) password a user has to enter before this image will boot. Obviously, since the password is plain text in /etc/lilo.conf, you will have to change the permissions to 600 or 400 so that no user can read this file. Some people even go as far as to change the /etc/lilo.conf file to include the password, then run lilo and then change /etc/lilo.conf again, removing the password.

restricted Only ask for a password if the user supplied any options - do not ask for a password for a straight, normal boot.

Certain distributions also use the initrd option. This option specifies the name of a compressed image of an ext2 filesystem which holds some kernel modules. This is needed for instance when booting from a SCSI disk. SCSI support is usually modularized in the kernel, meaning that before a SCSI disk can be accessed, the SCSI modules will have to be loaded - from that SCSI disk... To prevent this chicken-and-egg problem, a very small filesystem, with the SCSI modules on it, is loaded into memory by Lilo when the kernel boots. Initially, this filesystem is mounted as root, the SCSI modules are loaded, and only then will the real root filesystem be mounted. (Initrd = INITial Root Disk.) If for some reason you need to change this Initial Root Disk, use the mkinitrd command and read the mkinitrd manual page for details. Obviously this initial root disk needs to reside in /boot too.




Uempty

Figure 3-7. GRand Unified Bootloader (GRUB) LX032.0

Notes:

GRUB, as LILO, consists of a number of separate stages:

• The first stage, called stage1 on disk, is usually stored in your MBR.

• The 1.5th stage, called *_stage1_5 (e2fs_stage1_5, fat_stage1_5, minix_stage1_5, reiserfs_stage1_5, ...) is stored on disk, typically in /boot/grub. Several 1.5th stage files exist, each for a different filesystem.

This stage is used to add filesystem capabilities to GRUB, so that GRUB is able to use regular filename references when loading configuration files, kernels and such, instead of disk block locations.

Because of this stage, GRUB is able to read its configuration file directly, and does not need to be configured beforehand, like LILO.

• The second stage, called stage2. This gives a menu interface which allows you to boot your predefined operating systems, or enter commands to boot a non-predefined operating system.

2�� ' �� 02�' 1

�� /5$�'��+�� A��A��'(>J�� +

2 �� -�� #�� "�?

!� �� A��A��A��>��

" �� /5$��3� ��

�� ? ��2�� ,�� ? !��

D$25�� /�J�� A2 �� -��%��



Student Notebook

If a "splashimage" was included in the GRUB configuration, then the second stage will display the menu in a graphical mode, with the splash image as background.

The GRUB configuration file is typically stored in your /boot filesystem, in a separate GRUB directory, and called grub.conf.3 On a regularly booted Linux system, this file is thus referenced as /boot/grub/grub.conf. It contains all predefined operating systems and their options and peculiarities.

To install GRUB, either use the shell script grub-install or start the grub program and use GRUB commands to install GRUB manually.

GRUB has some additional features that make it far more useful than LILO:

• GRUB supports MD5-encrypted passwords to protect normal users from supplying parameters and options to predefined operating system, or to define their own operating system boot procedure.

• GRUB can perform hiding and unhiding of Windows partitions. This is a requirement for running multiple Windows operating systems from the same disk.4

• If configured properly, GRUB can be used to boot from the network. This requires the netboot package, and requires you to set up a DHCP and TFTP server though. Network booting is outside the scope of this course.

3 On some distributions, a symbolic link "menu.lst" is created, which points to this file.4 The problem lies in Windows 9x itself: When a Windows system boots, it goes through the partition table and assigns a drive letter toevery partition type it recognizes, starting with C:. Furthermore, Windows is only able to boot from the C:-drive. Thus, if you want multipleWindows 9x operating systems on your partition, you need to "hide" all partitions that are not in use. This is done by changing thepartition 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 multipleoperating systems on one disk.




Uempty

Figure 3-8. /boot/grub/grub.conf LX032.0

Notes:

The GRUB configuration file, /boot/grub/menu.lst, is nothing more than a predefined series of commands that could just as well have been entered on the GRUB command line. Storing these commands in a file though makes booting far more convenient...

The file starts with a few general configuration options:

default=0 This specifies the default operating system to be started.

GRUB also allows you to specify the fallback parameter, which specifies the operating system to boot in case the default fails.

timeout=10 Timeout before starting the default operating system, in seconds.

splashimage=(hd0,2)/grub/splash.xpm.gz This specifies the image to use as background for the GRUB boot screen. It is a compressed xpm image.

This line also introduces the way GRUB works with disks and partitions. Since GRUB runs at boot time, before filesystems have been mounted, it cannot use the filesystem path /boot/grub/splash.xpm.gz. It therefore has

.��.��.��

��"��%'

��%�'

��%-��'.�/��$��(

��0��&�1�12134��5��6�78�!2�9$�

�� :��-��;��'/

��-��'.�/

��(��;��'��%��&��%��+

��;��'��

��6��0��<&

��-��'.'/

��-��'.�/

��",�-��'.'/

��

��=�

��6��0��<*

��-��'.�/

��-��'.'/

��",�-��'.�/

��

��=�



Student Notebook

to identify the disk and partition that the filesystem is on, before the filename itself can be referenced.

Both disks and partitions start counting at 0, and this can be confusing, since /dev/hda3 is written down in GRUB as (hd0,2).5

password --md5 $1$U$JK7xFegdxWH6VuppCUSIb. This specifies the MD5-encrypted password that is needed if users want to make real-time changes to the configuration. It is created with the command md5crypt, which is part of the grub program.

Passwords can also be specified in the operating system sections below, in which case booting the operating system and making changes is not allowed for that particular operating system.

When general options are all defined, specific operating systems need to be predefined. For this, the following keywords may be needed:

title The title of the operating system, as it shows up in the GRUB boot screen.

root The root partition of the filesystem. All files that are referenced later on are stored on this filesystem.

kernel The kernel image that is to be loaded, and all options that need to be passed to the kernel.

initrd An initial root disk that needs to be loaded.

unhide Unhide the partition specified (i.e. change its type so that Windows systems will recognize it).

hide Hide the partition specified (i.e. change its type so that Windows systems will not recognize it).

rootnoverify The root of the operating system is the partition specified, but don't try to verify and access this as GRUB does not support the filesystem type.

makeactive Mark this partition active in the partition table.

chainloader +1 To boot this operating system, invoke the chainloader, which needs to load the first sector of the specified root partition.

5 There is a file, /boot/grub/devices.map, which is created automatically by GRUB, and which matches Linux device names to GRUBdevice identifiers.




Uempty

Figure 3-9. Kernel Booting LX032.0

Notes:

When the user selects a Linux operating system to boot at the lilo-prompt, lilo will load the Linux kernel and, if specified, the initial root disk into memory, and will start the Linux kernel.

Because of space constraints, the Linux kernel is compressed, but has an uncompress program prepended to it. Actually, it looks like a self-decompressing ZIP file in DOS.

The uncompress program uncompresses the Linux kernel and puts it into memory. Then, it starts that kernel proper.

The first thing the kernel does is try to detect all the hardware for which it has support built in. This includes hard disks, serial devices, mice, graphical adapters, keyboards, network adapters and the like. By far most of these adapters can indeed be autodetected, but some can't. In that case, their configuration parameters (most notably, IRQ, I/O and DMA levels) need to be passed to the kernel as boot options. If this is the case, consult the Hardware-HOWTO for details.

+��

��%�� "�?��D$25

?��

��%�� $�� %�� ,� ��%� ��?�� %�� ! "�� A��$�"��/��

��%�� "��(

/�� %�� #��



Student Notebook

After the kernel has detected all hardware, it switches the processor to the so-called "protected mode", which basically means that from that point on multitasking is possible in a multiuser environment.

After this, if specified, it mounts the initial root disk. From this disk, it loads any modules it needs to access the true root filesystem. Then it mounts the true root partition. This root partition is one of the boot options that was passed to the kernel by the boot loader.

After the kernel is started properly, it starts the /sbin/init process with Process ID 1. This init process will then continue the boot process. The kernel might also start a few additional kernel support daemons.

While booting, the kernel generates a lot of messages which will scroll off the screen very fast. And since no filesystem is available to store these messages on, they kind of vanish. If you wish to retrieve these messages later however, you can run the dmesg command to see them.




Uempty

Figure 3-10. System initialization LX032.0

Notes:

When init is started, it reads the /etc/inittab configuration file. In this file the "runlevel" is stored. This runlevel basically identifies the way the system is supposed to run (and thus, what applications to start) at this time.

There are seven runlevels, but on most distributions only runlevel 3 and 5 are really important for us. 3 means full multiuser mode with a text-based login (you'll need to start X-Windows yourself), and 5 is the same, but with an X-Windows based login screen.

The default runlevel is specified in the /etc/inittab file itself, and also specified in this file is what programs to run in each runlevel.

"�� 4��

� �� A��A� ��

�� #��

$� ��#��#�� >�� $��

8��(�� 7��-� <��:�� J�� ;��

� �� #��



Student Notebook

Figure 3-11. /etc/inittab LX032.0

Notes:

The most important lines of the /etc/inittab file are shown here.

The first line identifies the default runlevel, if no runlevel was specified somewhere else. In this case, the default is three.

The second line tells init always to run the /etc/rc.d/rc.sysinit script. This script does a number of important low-level tasks, such as:

• Activating swap spaces

• Setting the hostname

• Checking the root filesystem for errors, and remounting it read-write

• Turning on quota support

• Loading important kernel modules

• Checking all other filesystems and mounting them

• Deleting various lockfiles which may have been left over from a crash

.��.� ��

K�� #��

��<��

K� �� &�� >

�� A��A��>�A��>��

�8�8��A��A��>�A��8

�(�(��A��A��>�A��(

�7�7��A��A��>�A��7

�<�<��A��A��>�A��<

�:�:��A��A��>�A��:

�J�J��A��A��>�A��J

�;�;��A��A��>�A��;

K�� #�� #��>

�� A�� A��

K��!�$�,��,�3�3�3

��A�� A�� ,�<�,��

K�$� �� #��

(�(7<:J�� A�� A� ��(

7�7<:J�� A�� A� ��7

<�7<:J�� A�� A� ��<

:�7<:J�� A�� A� ��:

J�7<:J�� A�� A� ��J

;�7<:J�� A�� A� ��;

K�$� �4�� #��J

4�J�� A��AF((A��, ��

�� #��<

�� A��A��>�A��>��

$� �A��A��>�A�� #��

3 �� %

��,��

�� 4�#��

'1�� #��,�(��,�;+

�� '4�+�� #��J




Uempty
• Enabling the clock
The third set of lines tells init to run the /etc/rc.d/rc in runlevels 0 through 6, with the runlevel as parameter. We will look at this script in the next visual.

Then, the update daemon is started. This daemon ensures that cached write requests will actually be written to disk. It basically does this by issuing a sync command every thirty seconds or so.

After that, the trap for the Ctrl-Alt-Delete three-finger salute is set. This means that if you press this key combination, the command shutdown -t3 -r now is executed, effectively rebooting your system.

Then, six gettys are started on tty1 through tty6. This means that there will be six virtual terminals configured, allowing you to log in as different users six times. These six virtual terminals can be reached by pressing Alt-F1 through Alt-F6.

The last command, which is only run in runlevel 5, will start the xdm command. This will present a graphical login screen.

Note that some commands have the prefix once, some have wait as prefix, and others have respawn. This identifies what init should do after it has started the command:

• wait means that init should wait for the command to finish before it is allowed to go on with the rest of the init sequence.

• once means that init is allowed to go on with the init process even before the command has finished.

• respawn means that init should start this process, put it in the background, and monitor its existence. Once the process dies, init should start a new one. This is commonly used for login processes, because a new login screen will then automatically appear, even if the user manages to kill off all its processes.



Student Notebook

Figure 3-12. Starting Services (System V init style) LX032.0

Notes:

The /etc/rc.d/rc script is a very funny script. It is started somewhere after /etc/rc.d/rc.sysinit, but before all the gettys are active. And it has the runlevel as parameter.

What this script basically does is the following:

• It changes to the directory /etc/rc.d/rc<runlevel>.d

• In this directory, it makes a list of all scripts that start with a K, sorts this list on the two digits after the K, and executes these scripts with the stop parameter.6

• Then, it makes a list of all scripts that start with an S, sorts it, and executes them with the start parameter.

These scripts are in fact not scripts at all, but are symbolic links to generic scripts in /etc/rc.d/init.d or /etc/init.d.7 Every server program that is installed on a Linux system is supposed to have a corresponding control script in this directory, with the same name as

6 Obviously, kill scripts are not relevant when booting straight into a runlevel. It is possible however to change runlevels in a live systemby running the command init <new runlevel>. In that case, it might be necessary to stop services, for instance when switching from amultiuser to a single-user runlevel.7 Depends on the distribution used.

"�� "��0"��5�� 1

� ��

A��A� ��

A��A��>�A��>��

A��A��>�A��<

A�� A� ��(

>>>

A�� A� ��;

A��A��>�A��<>�A06��

A��A��>�A��<>�A 6��

>��?��

��0��0��0��+��7��@��4�'��A��

��0��0��0��+��7��@��4�'��A��

�

��0��0��0��+��7��@��'&��(��A��(�

��0��0��0��+��7��@��'��0��A��0��

��0��0��0��+��7��@��A��

�

��0��0��0��+��7��@��<<��A��




Uempty
that service. By making a symbolic link from /etc/rc.d/rc3.d to that particular script, the administrator ensures that a particular service is started (or stopped) in a certain runlevel. And by specifying a two-digit number after the S or K, he can even influence the order in which services are started and stopped.
This scheme was first used in AT&T's system V (five) Unix. That's why it is called the System V init style. It is used, among others, by Red Hat and SuSE. Other Linux distributions may use other init styles. But for all distributions the principle holds: init reads the /etc/inittab files and starts all the programs that are listed there. There is never a magic or secret program or script being started. That means that it doesn't really matter which distribution you use. Take a look at the /etc/inittab file and read the scripts that are listed here. This will tell you how the system is started.



Student Notebook

Figure 3-13. Configuring Services per Runlevel LX032.0

Notes:

The tksysv tool, its text brother ntsysv, its scriptable sister chkconfig and its competitors ksysv and serviceconf all allow you to select which services to start and stop in a certain runlevel.

The list of available services is in the left column, and is in fact just a list of scripts in /etc/rc.d/init.d or /etc/init.d (depending on distribution and version). By adding these scripts to one of the columns on the right, the link to that script is automatically created in the right directory. Plus, the priorities are all set up correctly.

To change runlevels use init <runlevel> or telinit <runlevel>. telinit is a symbolic link to init, so it really doesn't matter which one you choose.

�� "��

K��%��#

�� #��

K� ��#

K��%��

K�%��#

K��#��

�� #�� 6�� 7�� 6�� 7




Uempty

Figure 3-14. Starting and Stopping Services Manually LX032.0

Notes:

The scripts in the init.d directory can perfectly be used to start and stop individual services manually, for instance after changing configuration files. All scripts will always accept the status, start, stop and restart parameters. In addition to that, some scripts will also accept other parameters, like reload (only reread the database without restarting the server).

You can call the script directly using its full pathname,8 but on a Red Hat system, you can also use the service command. This does nothing more than calling the script for you, with the parameters you specified. But it saves you from typing a lot of slashes and dots.

8 The init.d directory is not in your $PATH, and for good reason: The scripts sometimes have the same name as the daemon itself.

"�� "�� "��

�� >�� A��#��

? �$��

��

?�� #��

>��,��

��0��@��B4�

��0��,��@��B4�

��,��@��B4�

��@��B4�



Student Notebook

Figure 3-15. Booting Linux in Single-User Mode LX032.0

Notes:

Sometimes it is necessary to have full control over your system, with no users or other programs doing all kinds of unexpected things. This is possible in Linux, and is called Single-User Mode.

For single-user mode, you will need to specify the single option to the kernel when your system boots. The Linux kernel will then boot as normal, but init will only run /etc/rc.d/rc.sysinit and then start a bash shell. It will not start all the normal services, so users can't log in over the network, and it will not ask for a root password. (So it can be used if you forgot your root password, to set a new one.)

Obviously, in single user mode the system is not very useful, except for you. So after your system maintenance, you need to switch back to normal mode (runlevel 3 or 5). This can be done by rebooting the system with shutdown -r now or by exit-ing the shell. In that case, init will just continue its boot process, which may or may not be the correct thing to do, depending on the actual changes you made.

Single-user mode may be protected by specifying restricted and passwords in /etc/lilo.conf. Refer to the manual page of lilo.conf for details.

�� !�� "� ��3'��

� ��,2��/��-�� %� ��'�� %��+-��#�� -�� %��

1��

��"�?��*�� *��,��

��D$25��

�� !�� #��# �3�� #��

��

��

��




Uempty

Figure 3-16. Shutting Down a Linux System LX032.0

Notes:

If you need to shut down a Linux system, don't just pull the plug, but ensure that somehow the shutdown command runs. We've in fact already seen how to do that: by pressing Ctrl-Alt-Delete, which was trapped in /etc/inittab, or by entering the command itself on the command line.

Some display managers allow the console user to perform a shutdown as well. This seems like a security exposure, but think of this: the console user can just as easily yank the power cord if he wants to do a shutdown. Allowing him to do a proper shutdown is probably a better way of doing things.

"�� &�# �� !�"��

�?�-?��

2��# �� !��,��,�� 2 �� $��

34��0��0��$��0��0��

��/� ��



Student Notebook


Notes:


1.

2.

��

Name the four steps that form the startup order of a Linux system:

______________________________________________

How would you select a graphical login screen (xdm)?

______________________________________________

1)

2)




Uempty


Notes:

"��

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

5�� "�?�� D$25��

�� 4�� # �� !��,��,��



Student Notebook




Uempty
Unit 4. System Administration Tools

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



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


Accountability:

• Checkpoint Questions • Exercises


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

Student Notebook


Notes:

��

��

��

�� ,��

�� ,��




Uempty

Figure 4-2. System Administration Tools LX032.0

Notes:

System Administration Tools are integrated tools for system management. This means that these tools allow you to manage your whole system configuration from within that one tool.

System Administration Tools typically use one or more different interfaces, based on the way you connect to them. Typical choices include:

• Text-based: The tool typically uses the curses library to present a menu-driven interface in a text-based terminal. This is typically used when logged in via a text console or via a telnet or ssh session.

• X-based: The tool typically uses some X library to present a graphical interface. This can only be used in an X-based environment.

• Web-based: The tool typically listens on a TCP port for HTTP traffic. The menu screens themselves are generated using HTML. This requires you to use a browser which connects to the right port.

The landscape of system administration tools is constantly changing. There is a number of reasons for this:

"��$�� /��

" ��

��%��

/�� 4�,��F,��,��

�� .�� ,�� C? �� C!� ��4�� C

��4��C



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.




Uempty

Figure 4-3. Red Hat "setup" LX032.0

Notes:

setup is Red Hat’s menu-based front-end for the various tools that are part of a text-based installation. That means that using this front-end you can start the following tools:

• authconfig: Authentication configuration

• kbdconfig: Keyboard configuration

• mouseconfig: Mouse configuration

• ntsysv: Management of system-V init scripts

• sndconfig: Sound configuration

• timeconfig: Timezone configuration

• Xconfigurator: X Window configuration

All these tools can also be started directly from the command line.

��)��*��*

/� �,�� ,� ��#��4�,��

�� %�� #� �� F��



Student Notebook

Figure 4-4. SuSE "YaST", "YaST2" LX032.0

Notes:

YaST and YaST2 are the preferred system administration tools on a SuSE system. They were created by SuSE to work specifically with SuSE and do not work on any other distribution. It cannot be easily extended but, within its limitations, is quite powerful and works well.

Although the names are similar, YaST and YaST2 differ a lot in their functionality.

"�"-�*8�"/*9�*8�"/:*

L��

L� ��4��

L� �7��F��

��




Uempty

Figure 4-5. Caldera "LISA" LX032.0

Notes:

LISA is the system administration tool written for Caldera OpenLinux. Just as YaST, it is not easily extendible but, within its limitations, it works well.

��*�"$*

�� 4�" ��

��4��



Student Notebook

Figure 4-6. Webmin LX032.0

Notes:

Webmin is a fairly new tool. It is from the ground up designed as an open-source, cross platform system administration framework. This means that it does not include the actual administration tools itself, but is only a series of perl scripts that allow people to write administration modules for various operating systems and administration tasks. The default webmin distribution comes with a whole load of administration modules though.

Webmin is licensed according to the BSD Open Source license, but modules may be licensed with other licenses, such as the GPL.

;��

��AA��>�� >��

?� � �� #�� %

5 ��?� � ��

2�� /��

��M��2 �4�#�� M�� 4

��,��

-�� /��




Uempty

Figure 4-7. Webmin Installation LX032.0

Notes:

Webmin installation is basically very simple. Untar the file you downloaded from http://www.webmin.com and run the setup.sh script. This script will answer a series of questions and will configure, setup and start webmin for you.

When this script is finished, you can access webmin immediately. This is done by launching a web browser such as netscape or lynx, and connecting to port 10000. You need to login with a username and password, and can then use any of the available modules to configure your system.

;��

�� ,��>��>�&��AA��>�� >��

��.��.��

��34!��.��.#�� 3��4

��#�� 3��

�.�� .��

�� (8888



Student Notebook

Figure 4-8. Webmin Screenshot LX032.0

Notes:

This is an example screenshot of Webmin.

;�� "��




Uempty


Notes:


1.

2.

��

Name some distribution specific tools.______________________________________________

______________________________________________

______________________________________________

What are the steps to install Webmin?

______________________________________________

______________________________________________

______________________________________________

______________________________________________

______________________________________________

1)

2)



Student Notebook


Notes:

"��

�� %��,��

�� 4��F��

/�� 4�� #��

�� ,��




Uempty
Unit 5. Packaging Tools

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



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


Accountability:

• Checkpoint Questions • Exercises


© Copyright IBM Corp. 2001, 2002 Unit 5. Packaging Tools 5-1

Student Notebook


Notes:

��

��

�� $�/

" ��$�/��%��

��$�/��

!�� 3!��




Uempty

Figure 5-2. Red Hat Package Manager (RPM) LX032.0

Notes:

The Red Hat Package Manager or RPM is a tool which was developed by Red Hat Software, who still maintain it, but released under the Gnu General Public Licence (GPL) and has proven to be so popular, that a lot of other distribution manufacturers use it as well.

RPM is a very versatile program which solves a lot of problems that a distributor of software typically faces:

• Management of source files

• Management of the build process

• A distribution method and format for binary files, including pre- and postinstall scripts.

RPMs can be created by anyone, not only the manufacturer of your distribution.

When a certain system uses RPMs to install packages, a database of installed packages is stored in /var/lib/rpm. The database itself is in rpm format too, so it cannot be read directly. You will have to access the database using the rpm command.

��)�� 0��1

2��%�� /� �� 5��

��#��$�� " ��D��H��?�� 4�� >�>�!�� 3

>�� $��

$�/��'A#��A��A�+�� %��

!� ��D�AD�D��%�� '#�� +�



Student Notebook

Figure 5-3. RPM Philosophy LX032.0

Notes:

The creators of RPM made an important observation: In the Linux world, the person or organization writing the software would in most cases not be the person or organization that would distribute the software. Because of this, RPM uses the philosophy of “pristine sources”. This means that the software that was developed is contained into a “Source RPM” file in a pristine state, exactly as it came from the developer. In this source RPM file (normally identified with the extension .src.rpm), you will also typically find patches and sample configuration files from the distributor, and most importantly, a SPEC file.

The SPEC file contains all the information to unpack the pristine source, to patch it and to compile it on any architecture. It also contains information on what files are included in a binary RPM.

With a correctly configured SPEC file, the only thing required to compile a package is the rpm -bb (build binary) command on the target architecture. The binary RPM can then be distributed to all users of the distribution on that architecture.

��#��

�� >��>�& �� >��>�& �3!��

��

�� >�<=;>� �� >�<)8>�� >��>�

��3��

��3�� <=; ��3�� <)8

��

�� >��>�

��




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


Student Notebook

Figure 5-4. RPM Installing, Freshening and Upgrading LX032.0

Notes:

Installing an RPM can only be done if it was not already installed. If the RPM was already installed, you need to do an upgrade or a freshen. The difference between an upgrade and a freshen is that an upgrade will always install an RPM, even when a previous version was not installed. (It will act like a regular installation in that case.) A freshen only installs packages that actually have been installed previously. A freshen therefore is very handy to use if you downloaded a lot of patches from the Red Hat site, and you are not sure which patches you actually need. You can then just freshen all the packages, and only the things you need will actually be installed.

The basic syntax for installing, freshening and upgrading is respectively:

rpm -i package-filename.rpm

rpm -F package-filename.rpm

rpm -U package-filename.rpm

�� 9�%�� '��

" �� $�/�� $�/�� 2�� $�/��

5�� 4��"��5��"��

��2��"��

?�� ,# #��,�� J8��%�,, �� H��%��

�� #��4�� >��#�

��%�� 2$��




Uempty
Note that there is a difference between the package name and the package filename. The RPM file which contains the package foo would generally be called foo-version-release.architecture.rpm.
There are a number of options which make life a little easier on you:

-v gives more information on what rpm is doing (verbose).

-h prints 50 hash marks while installing, so that you can track the progress. If you run rpm from a script, you can use these hash marks to make your own progress bar.

--nodeps disables dependency checking.

Files in an RPM are marked as program, documentation or configuration files. When doing an upgrade or freshen, all files which were marked as configuration file, will be saved with the .rpmsave extension. You will then need to make all configuration changes to the old configuration file to the new configuration file as well. The reason behind this is that configuration files tend to undergo syntax changes between versions, and rpm is not intelligent enough to incorporate the old configuration changes into the new configuration format.

When installing, freshening or upgrading packages, you may also specify the Web address of the package file instead of the package file itself. This allows you to do upgrades even on systems which are very tight on disk space, but do have access to a network (for instance the Internet). Just ensure that the RPM files can be reached, either through FTP or HTTP, and you can do an upgrade. If you need to go through a proxy, there are options available to specify this proxy as well. Look at the rpm manual page for details.



Student Notebook

Figure 5-5. RPM Uninstalling LX032.0

Notes:

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

��' � ��

2 � �� $�/

5�� 4��

?�� ,, �� %�




Uempty

Figure 5-6. RPM Querying LX032.0

Notes:

RPM Querying is the process of retrieving information about installed packages. The basic syntax is rpm -q package-name, but that will only display the package name. It's the options that make querying interesting:

-a queries all packages which are installed on the system.

-f <file> queries which package contains <file>.

-p <package-file> queries the (not yet installed) <package-file>.

-i displays all package information: name, version, release, install date, group, size, summary, description, build information and so forth.

-l lists all files in the package.

-s displays the state of each file in the package. The state is either normal, not installed or replaced.

-d displays all files that are listed as documentation.

-c displays all files that are listed as configuration files.

��<��

N�� $�/

5�� 4��C��

?�� ,� .�� %��,��O��P .��%�� >,�O��%��,��P .��%��,��,�� %�� ,�� %��,�� ,�� ,��



Student Notebook

With these options you can do a number of great things. Below are some examples:

• Do you want to know which package the nslookup program is in? Try rpm -q -f `which nslookup` or rpm -q -i -f `which nslookup`

• Need to know what documentation is available for a specific command, and man -k commandname does not work? Try rpm -q -d -f `which nslookup`

• Need a lot of data to test a network connection? Try rpm -q -i -l (Oh well, you can always cat /dev/zero too...)

• Need to know which not yet installed RPM package file contains the program "pico"? Sorry, you are out of luck here. RPM only queries one rpm package at a time, so you need to do something like this:

for package in `ls *.rpm` do rpm -q -l -p $package | grep -q pico if [ $? = 0 ] then echo $package fi done




Uempty

Figure 5-7. rpmdb Database LX032.0

Notes:

The dependency information that is used by the RPM system is not based on actual package names, but rather on capabilities. This is done because multiple packages might actually offer the same capability. Suppose for instance that a certain package requires the availability of a mail reader. Then it doesn't matter whether pine, elm, mail, mailx or netscape messenger is installed, as long as at least one of these is present.

This makes it a little difficult to determine which packet to install if a certain capability is missing though. For this, the rpmdb database is created. What basically happens is that, when the distribution is created, all rpm files are queried for the capabilities they provide. This is stored in the rpmdb database, which is an rpm file itself and can be installed like any other rpm. When installed, this database can be queried using the --redhatprovides option.

See the example in the visual to determine how this works. Note that not all distributions support this scheme.

��&��

��,#�� >��$�/H��#��

��,,��#��

>��$��'�'��''''*?'��?*7��

��$��

>��$��;�'��?��?*7��

��@�"��@

��$,��$��;�'��?

>��C��

��;�'��*'�7

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

��

>��$��;�'��?��?*7��

�$��



Student Notebook

Figure 5-8. RPM Verifying LX032.0

Notes:

The verify option verifies all files that are supposed to be present in the RPM against the files that are available on disk. This is a very easy way to check for any unauthorized configuration changes.

The following checks are performed on each file in an RPM:

5 MD5 checksum. This is a very hard to fool checksum which verifies that the contents of a file have not changed.

S File size. This verifies that the size of the file has not changed.

L Symbolic link. This verifies that a certain symlink has not changed.

t File modification time. This verifies that no one has altered the file.

d Device. This verifies that the major and minor numbers of a device are still intact.

U User. Is the owner of the file still the same?

G Group. Is the group of the file still the same?

��5��

1�� $�/��&�/�J��%��

5�� 4��8��

?�� ,��O��P 1��,� 1��%��,�O��%��,��P 1�� $�/��




Uempty
M Mode. Are permissions, SUID, SGID bits and the file type still the same?
If a file checks out ok, there will be no output. If there is a discrepancy however, the name of the involved file will be listed, prepended by the discrepancy information. The output line will then look like this:

# rpm -V sendmail SM5....T c /etc/sendmail.cf

This means that a discrepancy was found in the file /etc/sendmail.cf. This is to be expected, since this file is a configuration file (hence the "c" in the line. The discrepancy information in this case is SM5....T, in which each letter denotes a certain discrepancy from the list above. In this case the following discrepancies were found: size, mode, MD5 checksum, modification time.



Student Notebook

Figure 5-9. RPM Signatures LX032.0

Notes:

The RPM Package format also features the ability to include a digital signature of a package, and most distribution builders actually make use of this feature as an effective measure against trojan horses introduced in an RPM after release by the distribution builder.

Verifying this signature is a two-step process. The first step is to obtain the public key of the distribution builder. This key is stored in a text file which can usually be found on the original CD-ROMs or on the distribution website. This public key needs to be added to your "keyring", your database of public and secret keys in your home directory. This is done with the following command: gpg --import /mnt/cdrom/RPM-GPG-KEY.

The second step is to verify each individual package. This is done with the command rpm --checksig packagename. If the output is "gpg OK", then you can be sure that it was indeed the distribution builder that built this individual package, and that no one has tampered with it since.

��"��

$�/H��

��#�� ?�� %��

!�,$?/" ��

��%��%�� 1��%��

>�� D+�EDE�4FG

>��0��'�7;��?*7��

��0��'�7;��?*7��&��B4




Uempty

Figure 5-10. Creating RPMs LX032.0

Notes:

As said before, the SPEC file contains all the information to create a binary RPM from the pristine sources. It is divided into eight sections:

• The preamble section contains information about the package in general. Here you will find things like the name, the version number, a description, a summary, a list of source files and other general information.

• The prep section contains all commands that are needed to prepare for the build process. This includes unpacking the pristine source and applying patches, if needed

• The build section contains all commands that are needed to actually build the software.

• The install section contains all commands to install the software in its proper location (on the build system).

• The install and uninstall scripts are scripts that are executed on the users system before or after the software is installed or uninstalled. These scripts might for instance add user accounts to the system, check for disk space, and so forth.

• The verify script can be used to verify whether the install was successful.

��

$�/�� #�� 3!�� .�� $�/�� =��

��" �� %�� 5��!�� " ��!�� " �� 4��%�� A� � ��1�� #�� !�� %�� $�/

2�� $�/ �3!�� $�/



Student Notebook

• The clean script can be used to clean the build system after a built of the software.

• The file list is the list of files that are to be contained in the binary RPM.

Since the SPEC file lists both the source files (in the preamble section) and the binary files (in the files section), it can be used to create both the source and binary RPMs. The SPEC file is typically stored in the source RPM as well.




Uempty

Figure 5-11. Example Scenario: Hello, World! LX032.0

Notes:

The visual introduces a simple scenario which we are going to use in the next few visuals. Suppose you are the distributor of Useless Linux 1.0, and you want to include a program “hello”, which prints the text “Hello, World!” on the screen. Instead of writing this program yourself, you’ve searched around the internet and found such a program. The source file is called hello-1.0.tar.gz and contains three files:

• A file called hello.c, which is the C source code for the program.

• A file called Makefile, which contains the information for make, which builds the binary.

• A file called README, which contains information about the program, including the copyright statement, a short description of the program, and a description about the build process.

It is your job to create the SPEC file so that this program can be integrated into your distribution build process.

��3=�>.��?>�H��A

��-/

I

��"-)��.�6��JK�)/L

M

��3=�>.��?��@��

��@��

��

��@

��"��

��@��

��$��

��3=�>.�-$&�-?-�/�9N+�!,��''�

O��ED:�

O��)��.�6��J)��,��O��0�,��,��,��$��"��,��J

O�$��.��,��,��

O��.��,��,��

K��,&�#��,(>8>��>�&

��,(>8A��>�

��,(>8A/�%��

��,(>8A$3��/3

-!��"�� ?�)��9�;��@



Student Notebook

Figure 5-12. hello.spec Preamble Section LX032.0

Notes:

The first section of a SPEC file is always the preamble section. As you can see in the visual, it contains a number of one-line statements, describing several parameters of the package. It also contains a multi-line description.

Note the difference between the version and release numbers: The version number is something that was decided upon by the developer, while the release number is assigned by the distributor. This makes it possible to separate different trial SPEC files and their output from each other.

>

>��DF!�"��"��0��

>

��,@��.�6��

P��@��

8��@��'

��@��

!,��@�ED:

E��@�Q��2��

��@��'��(

R��$��@�2��:��'

8��@�9N+�:��

D��@�6��:��"��H��"��S��$��A

T��

O��)��.�6��J)��,��

O��0�,��,��,��

��$��"��,

��J

��"��




Uempty

Figure 5-13. Visual Caption LX032.0

Notes:

The visual shows the contents of the next four sections: prep, build, install and files.

The prep, build and install sections contain the commands required to perform each of these three steps. Note that we’re not using absolute pathnames here. This is a requirement, since different distributions will use different directories for the source and binary RPMs, and for the build directory. Instead, we’re using the shell variables $RPM_SOURCE_DIR and $RPM_BUILD_DIR, which are automatically set by RPM.

The files section contains the files that need to be stored in the binary RPM. Some of these files may be preceded by a special identifier, such as %doc. This means that the file is a documentation file which needs to be relocated to the documentation directory, usually /usr/share/doc/<packagename>.

T��

��"��1 D+#N29:R#R9 ��'

��(��"�1 D+#�B2 !F#R9 ��'��(

T$��

��1 D+#N29:R#R9 ��'

��

T��

��1 D+#N29:R#R9 ��'

��

T"��

T��1 D+#N29:R#R9 ��'� FQR+F

��$��

��9� ��9� �� %��"��



Student Notebook

Figure 5-14. Visual Caption LX032.0

Notes:

In order to finally run the build process, we need to put all source files (hello-1.0.tar.gz) in /usr/src/redhat/SOURCES1 and the SPEC file in /usr/src/redhat/SPECS. We can then run the rpm -b command, which will execute the build process. The letter after the “b” determines when the build process will stop.

1 Other distributions might use different directories here

��

�� A��A��A��A ?2$!3

�� 3!�� A��A��A��A �3!

$� ��,�O��P�O��P ��

��B��B�� B��B��B�� B� ��B��B��B� �� $�/��B��B��B� �� $�/

�� ,,�� ,,�� #��#��,##��




Uempty

Figure 5-15. After RPM Build Process LX032.0

Notes:

When the build process is finished, the source RPM is located in /usr/src/redhat/SRPMS, and the binary RPM is located in /usr/src/redhat/RPMS/<arch>. The binary RPM can then be queried, installed and deinstalled as any other RPM.

$��

��$�/�� A��A��A��A $�/

5� ��$�/�� A��A��A��A$�/ AO��P

!� �� $�/�� $�/�>��C�� D+��?*7��'��?*7��P��@�� @�-��$��/8��@��'��8��@�9N+�:�� @��N��R��@�O��''��

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

>�� D+��?*7��'��?*7��>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

>��.�6��J

>��



Student Notebook

Figure 5-16. GnoRPM and kpackage LX032.0

Notes:

GnoRPM is the graphical user interface to RPM management from the GNOME project. It can do the same as the command line interface, but it is probably easier to learn.

An alternative to GnoRPM is kpackage, which is part of the KDE Desktop Environment.

2 ��

D�� $�/




Uempty

Figure 5-17. up2date LX032.0

Notes:

up2date is a program that was developed together with RPM. It can be run out of crontab and, if configured correctly, connects automatically to the site of the distribution builder to download the latest RPMs.

These RPMs can then be installed automatically or after querying the system administrator.

��:��

$� ��

!��%��$��H��$�/H�

��

" ��#��



Student Notebook


Notes:


1.

2.

��

Which basic modes of operation does rpm have?______________________________________________

Which command can I use to verify that the permissions of /etc/sendmail.cf are still correct?

______________________________________________

1)

2)




Uempty


Notes:

"��

$�/��#��%��

� �$�/�� $�/�� $�/

��$�/�� %�� 3!��

�� 3!��

�� $�/��

D �$�/�� %��%�� $�/



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:



© Copyright IBM Corp. 2001, 2002 Unit 6. X Window System 6-1

Student Notebook


Notes:

��

��

��F��

!� ��F��=;

�� F

��

2��F��#�� %




Uempty

Figure 6-2. X Window System LX032.0

Notes:

The X Window System, X for short, is the graphical user interface of Linux. It is implemented as a separate program that runs in user space and it uses a client/server architecture.

A�;� ��#�"��

D��2��" ��2-"F

" ��#��/"�

!�� F�!� ��" �>

" �� 4��

2�� ,��#��



Student Notebook

Figure 6-3. In the beginning... there was the batch system LX032.0

Notes:

In the beginning of UNIX, the only way a system could get any work done was by batch processing. This meant that you handed your job to the system operator (typically on punch cards or on tape), and the operator would load and execute your job when the system was finished with other jobs.

�� #��

��,(

��,7

2-"F��

��,<

��,:

��,J




Uempty

Figure 6-4. Later... the interactive typewriter system LX032.0

Notes:

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

�� #��

��,(

��,7

2-"F��

��,<

��,:

��,J

��

��

��

�� 8

�� (



Student Notebook

Figure 6-5. Later yet... a graphic terminal on a network LX032.0

Notes:

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

�� #��

4��,(

4��,7

2-"F��

��,<

��,:

��,J

4��#��

==:

:

B

C

DE

F

G

H

=>

==

��A�� %

4��,




Uempty

Figure 6-6. Client/Server Architecture LX032.0

Notes:

The X Windows System uses a client/server architecture, which makes it very flexible. The central piece of software is the X server, which runs on the X station. This server traps all keyboard and mouse events, and sends them to the appropriate application. If an application wants to put something on the screen, it sends that data to the server, which then performs the necessary hardware calls to the graphical adapter.

Any application can connect to the X server, but there should always be one special application active: the window manager. This window manager basically puts a border around each application window, and allows you, for instance, to drag windows around the screen. There are numerous window managers available, each with their own style.

Other applications also connect to the X server, and have their data displayed through it. Common examples are:

• xterm, which emulates a terminal screen, allowing you to enter Linux commands • xeyes, which displays a pair of eyes on your screen, looking at the mouse pointer • xbanner, which displays a background image • xcalc, a mathematical calculator

A�3��%�� ."��$��

F� ��#��

�� !�� ,��( !�� ,��

��F� ��

��,(

��,&!�� ,��&



Student Notebook

• xedit, a GUI-based editor

and many, many more.

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




Uempty

Figure 6-7. Examples of X Stations LX032.0

Notes:

There are several X stations possible:

• Real X stations are hardware devices which consist of a monitor, a keyboard, a mouse and a ROM chip containing the X server program. These devices cannot do any local processing and thus need to be connected to a network at all times.

• UNIX/Linux stations with a graphical display can run an X server as a separate program. In most cases, the X server will grab the entire graphical screen.

• Several X servers exist that run under MS-Windows: Hummingbird eXceed, WRQ Reflection X and many others. These programs typically open an MS-Windows window, and run the X server inside it.

On most UNIX/Linux systems, the X clients and X server run on the same system, communicating with each other via the TCP/IP loopback interface or via a UNIX socket1. This makes it possible to use X as a standalone solution.

1 A special file (type s) in a UNIX/Linux filesystem which makes TCP/IP-like communications between two processes possible. Becausethese sockets are limited to the local filesystem, they are generally more secure than TCP/IP connections. Furthermore, their overhead isslightly less, thus increasing performance.

-!��A�"��

��F� �� F� ��#�� $?/��

2-"FA�� 4F� ��#�� F��

/ ,�� F� ��#�� D2"��F��

�>�>�� F��

2-"FA�� 4�� F�!�� F� ��#��

��



Student Notebook

Figure 6-8. X Servers in Linux LX032.0

Notes:

The X Server that is most often used with Linux is XFree86, an open source server which is, just like Linux, developed as a joint effort of various programmers on the Internet. Their web page is http://www.xfree86.org.

You don't have to use XFree86 though. Thanks to the modular design of both Linux and the X Window System, you can basically plug in every X Server that is available on Linux. Currently, there are two commercial X Servers available as well: Metro-X and Xi Graphics. The advantage of commercial X-Servers (which are not really expensive by the way) is that these commercial products in general support the newest adapters that become available earlier and sometimes better. When buying a new computer you might be in the situation that XFree86 does not support your graphical adapter, but Metro-X or Xi Graphics do.

A�"�� !

��F,�� #�� 4��F��=;?� � ��AA��>4��=;>��

?��F,�� #��#�� 4/��,F��AA��>�� %>��F��D��AA��>4��>��




Uempty

Figure 6-9. XFree86 LX032.0

Notes:

About a year ago the XFree86 project released XFree86 version 4. Some distributions are currently already using this version, and other distributions are holding off a little because of some reported problems. That means that there are currently two different versions of XFree86 in production use.

XFree86 version 3 has been used for a number of years and is considered stable. It supports a large number of graphical adapters, and therein lies its biggest problem: Because of the support for all these adapters, a single binary image would be too large. That's why the XFree86 project releases multiple binaries, each with support for a number of related adapters. You need to install the binary that has support for your adapter before you can do anything.

This approach became more and more difficult to support. That's why the XFree86 project decided to use another approach for version 4. In this version, XFree86 consists of a single binary which is able to detect the adapter that is being used, and that can load the modularized support for that adapter in real-time. This makes installation and configuration easier.

A%��GE

F��=;�#�� <>4�� #��

F�=;I/� ��'/� ��+F�=;I1D�(;�' �� (;,��1D��+F�=;I 1D��' ��1D��+F�=;I <�'�� <��+F�=;I�)888�'��%��)888��+>>>� ��

F��=;�#�� :>4��? ��



Student Notebook

Figure 6-10. XFree86 Configuration LX032.0

Notes:

On every system which will run the XFree86 X-Windows server, the configuration file /etc/X11/XF86Config (or /etc/X11/XF86Config-42) file will have to be created. This file contains the hardware characteristics of the system running the server: graphical adapter type and characteristics, monitor characteristics, mouse type and keyboard type and language.

The correct setup of the configuration file is pretty complicated and very tricky, since incorrect monitor settings may damage your monitor. Let's repeat that: Incorrect monitor settings in /etc/X11/XF86Config or /etc/X11/XF86Config-4 may damage your monitor! Don't say you weren't warned!3

It used to be that you had to set up this file all by yourself, but nowadays there are several programs (SuperProbe, xf86config, XF86Setup, Xconfigurator, xvidtune and others) available that can help you out in about 99% of the situations. Only exotic hardware, specifically laptop screens, will pose a problem for these programs. And even then, there is a lot of help and sample XF86Config files available on the Internet. 2 XF86Config-4 is only used if you are in a mixed version 3/4 environment and want to refer to the version 4 configuration file.3 This is no joke. Multiple fellow students have had this happen to them.

A%��GE��

!� ��

L��#�� F��=;��D��/� ��/��0��

�� A��AF((AF�=;!� ��F�=;!� ��,:

!� �� !�GE�� ,��4��A%GE"��9�!�GE�� 4��,��A%��GE�3�� A�� $��"�A � 3��

!� �� !�� F��




Uempty

Figure 6-11. Sample /etc/X11/XF86Config LX032.0

Notes:

The /etc/X11/XF86Config file is split up in a number of sections that each describe a different part of the XFree86 configuration. The file is too complicated to cover here in full, but we will look at some of the more important sections. The full documentation is available on http://www.xfree86.org.

Section "Files" RGBPath "/usr/X11R6/lib/X11/rgb" FontPath "/usr/X11R6/lib/X11/fonts/misc/:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled" ModulePath "/usr/X11R6/lib/modules" EndSection

This section describes the locations of various files that are needed by XFree86.

Section "Keyboard" Protocol"Standard" AutoRepeat500 5 XkbKeymap "none"

"��.��.A==.A%GE��

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

,�� -��'�!�� !�!��. ��! �//��$0'-��)!��,�� #1��2�3��#��3#��!��,�� +�� 4 **/$5�625%17/�%/18��9��:!)��+��+��:!)��4 **/$�;%<=*>��?��@�� </5&��A�)� ��9�� "��/=/5*/=/��+��%17/�%/18��%%/��%17/�%<17�%�%1�%*%1��%/18�%/1��%/17�%/�8,�� 2�3�� 4 **/$5$�.��9��:!)��+��!��:!)��4 **/$�� !��,�� 2��3��3(!��2�3��4 **/$5$�.��+�� 4 **/$5�625%17/�%/18��2��!� 6��2�� "�%&��'�� 2��!��2�� "��7��+��%17/�%/18��9�� /�/��9�� !��%17/�%/18��,��'�� '�� 2��!��2�� "��%&��+��%17/�%/18��9�� /�/��9�� !��%17/�%/18��,��'�� ,��

��

/��

0��

/� ��

D��

�� #�

(7=84(87:��7J;��

(7=84(87:��;:0��



Student Notebook

EndSection Section "Pointer" Protocol "PS/2" Device "/dev/psaux" EndSection

The two sections above describe your input devices: keyboard and mouse.

Section "Monitor" Identifier "TP770X-LCD-1280x1024" VendorName "IBM" ModelName "TP770X (13.7)" HorizSync30-65 # multisync VertRefresh 50.0-70.0 Modeline "1280x1024" 110 1280 1328 1512 1712 1024 1025 1028 1054 EndSection

This section describes your monitor and the monitor capabilities. This section is by far the hardest to set up. The first three lines are easy, since they are just ASCII strings describing the hardware. The next two lines, HorizSync and VertRefresh describe the horizontal synchronization and vertical refresh rate ranges of your monitor. In the example above the monitor can handle horizontal synchronization rates ranging from 30 KHz to 65 KHz, and can handle vertical refresh rates ranging from 50 Hz to 70 Hz.

The last line is the Modeline. This line describes the video timing parameters for a given resolution. The line above describes the video timings for the resolution 1280x1024: The driving frequency should be 110 MHz, the horizontal resolution is 1280 pixels and the numbers 1328, 1512 and 1712 describe the timings used to wrap the light ray back from the right to the left. The horizontal resolution is 1024 pixels, with three additional number describing the timings with which the light ray cycles back to the top of the screen.

There should be a different Modeline for each of the resolutions that your monitor can support. Information about calculating modelines can be found in /usr/doc/HOWTO/XFree86-Video-Timings-HOWTO. If you start changing modelines by hand, it is absolutely vital that you read this document and understand it. Numerous people have damaged their monitor beyond repair by "overclocking" it.

Section "Device" Identifier "TP770X-XGA" VendorName "IBM" BoardName "TP770X" Option "accel" EndSection

This section describes your video card.

Section "Screen" Driver "svga" Device "TP770X-XGA"




Uempty
Monitor "TP770X-LCD-1280x1024" DefaultColorDepth 16 Subsection "Display" Depth 8 Modes "1280x1024" ViewPort 0 0 Virtual 1280 1024 EndSubsection Subsection "Display" Depth 16 Modes "1280x1024" ViewPort 0 0 Virtual 1280 1024 EndSubsection EndSection
This section describes the actual resolutions and color depths that are to be used. The first line "Driver" tells XFree86 which driver (XFree86 Server) to use. It then specifies which device and monitor (see above) to use. It then specifies the default colordepth, which is the number of bits per pixel. The more bits per pixel you allocate, the more different colors you can display simultaneously, but also the more video memory is required.

The display subsections at last describe the different modes that are to be used give a certain color depth. In the case above, both for the 8 and 16 bit colordepth, only the resolution 1280x1024 is used. We could however specify more modes here, as long as each of the modes also has a corresponding modeline in the monitor section. We could then cycle through these modes with Ctrl-Alt-NumericPlus and Ctrl-Alt-NumericMinus.

There is one catch however: the actual resolution being displayed may be less than the amount of memory allocated for this screen. In that case, the concept of virtual screens is introduced. Virtual screens means that your virtual display (where applications display their windows) is larger than the monitor can currently display. In this case, only part of the virtual screen is displayed, but you can scroll simply by moving your mouse beyond the borders of your actual screen. The "Virtual" keyword defines the actual size of the virtual display, and the "ViewPort" keyword defines what part of the virtual screen is displayed initially, and what parts fall beyond the border of your actual screen.

Just a last note: Most people have no need to edit or even understand this file directly. The available tools (Xconfigurator, XF86Setup, xvidtune and xf86config) usually are good enough to set up this file automatically.



Student Notebook

Figure 6-12. Sample /etc/X11/XF86Config-4 LX032.0

Notes:

The visual shows a sample /etc/X11/XF86Config-4 file. You will notice roughly the same sections and structure as the version 3 config file, but the syntax has changed slightly.

"��.��.A==.A%GE�� 3C

�� */� ��*

"�� *"5/�)J7J�(JF��(JFD�Q�(JF�*

1� ��-��*2 % �� *

/��-��*2 % �� *

��& � ��<8,;:

1��$��J8,((8

3 � ��

�� *��#��*

"�� */��1��!��*

��#��*�<#��*

5��-��*2 % �� *

3 � ��

�� * �� *

"�� * �� 8*

��#��*/��1��!��*

/� ��*"5/�)J7J�(JF��(JFD�Q�(JF�*

��=

�� *��*

��=

/��*(87:4@;=*

3 � ��

3 � ��

�� *�$"*

3 � ��

�� * ��#��*

"�� *F��=;�!� ��*

�� 8��* �� 8*�8�8

" ��#��*/��8*�*!�� *

" ��#��*0��8*�*!��0��*

3 � ��

�� *��*

�� *� �4A�@(88*

3 � ��

�� */��*

��*D��*

��*��*

��*��*

��*�4��*

��*��4*

��*�4J*

��*��*

��*4��*

��*#:�*

3 � ��

�� *" ��#��*

"�� *0��8*

��#��*%��*

?�� *F%��* *��*

3 � ��

�� *" ��#��*

"�� */��8*

��#��*��*

?�� *��#��*�*A��#A��*

?�� *��*�*� A7*

?�� *3��<5�� *�*� *

?�� *R�4��/�� *�*:�J*

3 � ��




Uempty

Figure 6-13. Starting X LX032.0

Notes:

XFree86 itself is started with the X command. This starts X on the first free virtual terminal (usually number 7, so it can be selected with <Alt-F7> or <Ctrl-Alt-F7>) However, with only XFree86 running you won't get anywhere: you will just get an empty, grey screen with a mouse pointer. This is useful for debugging your XF86Config file, but in order to do anything useful, you need to start a window manager too.

With the startx command this is exactly what is accomplished. First, XFree86 is started and a few seconds later, your favorite window manager is started.

What your favorite window manager is, is determined by reading the configuration file .xsession in your home directory. If you want to change your window manager, use the tool switchdesk, which will store your preference in the .xsession file, will stop the currently running window manager and start the one you selected.4

Since Linux has a large number of virtual terminals, there is nothing keeping you from starting a second X session on another virtual terminal. This is accomplished by starting an

4 switchdesk is only available on Red Hat Linux. On SuSE, you need to change your WINDOWMANAGER shell variable in$HOME/.bash_profile.

"�� A

��A�� F��=;�� #�� 2�� F��#��A�?=

��F��=;�� #�� !

��F��=;�� #��'�� @+��#��

0�3�'%�� +��D-?/3�'��+�� 0��

�� F�� !�33�?=



Student Notebook

X server on display ":1". When you start X via startx you need to make sure that startx understands that this is an option not for itself, but for X, so the full startup line will become startx -- :1.

Once you have started multiple X sessions, you can toggle between them with <Ctrl-Alt-F7> and <Ctrl-Alt-F8>.




Uempty

Figure 6-14. Stopping X LX032.0

Notes:

X can be stopped in two ways:

• The proper way, by using the appropriate button from your window manager. This will gracefully stop all applications, and exit X.

• The quick and dirty way, by pressing Ctrl-Alt-Backspace. This will first stop the X server, and then all applications will ungracefully die because their connection is lost. Ctrl-Alt-Backspace can be disabled in /etc/X11/XF86Config.

"�� A

2�� F��=; �#�� %��

!��,��,5��% �� F��=;�� !� �� A��AF((AF�=;!� ��



Student Notebook

Figure 6-15. Session Managers LX032.0

Notes:

A Session Manager is a program that manages X sessions. This means that it will start XFree86 and display a graphical login prompt. If a user tries to log in, it will authenticate this user and start the users favorite window manager. When the user logs out, it restarts XFree86 and displays a login prompt for the next user, and so forth.

On a Linux system there are several different session managers available, because nearly each window manager comes with its own session manager. The most common are xdm, kdm and gdm.

On most distributions, the session manager is started from init in a certain runlevel, but we can also start it manually from the command prompt.

"��

/� ��F, �� F��=;?�� H��#�� $��F��=;?�� 4��

�� 4��!��

2�� #��




Uempty

Figure 6-16. X Networked LX032.0

Notes:

All connections between the different X components (server, window manager, applications) are TCP/IP connections. This means that we can run them over a network too. And that opens up some interesting possibilities. There are three levels of networking with X-Windows: • The first level is by just running a single application over the network. This allows you to

run an application on another system, but redirect the display to your local screen. This is very useful if that application is not supported or present on your local system.

• The next level is by running your whole X session over the network. In this case, all applications and your window manager are all running on a remote system. This is useful if you have disk- or dataless clients: clients that do not have any disk space to store data on, or do not have any disk at all. All user data and programs can be stored on a single server, and are run from this single server.

• The last level is by using a session chooser. In this case, before logging in, you get a list of servers that are willing to manage your session. This is very useful if you have multiple servers, and users need to be able to run their sessions from their local system on each of these servers.

A�(��#��

!� �� F�!�� F� ��#��!�A"��

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

��#��" ��#�� !��



Student Notebook

Figure 6-17. X Applications Networked LX032.0

Notes:

The visual shows the first level of networking X-applications. Both the XFree86 server and the window manager (and possibly other applications as well) are running on the local system. Only a single application is running on the remote host (the application server).

A�$�� (��#��

��

'�� +

F� ��

'�� 4�� +�!�A"�-��%

F��=;4��

�� /��




Uempty

Figure 6-18. Applications over TCP/IP LX032.0

Notes:

If you want to run an application from another server, then the only thing you basically need to do is start the application with a special option telling the application what X server to use.

This can be done using two methods:

• First, every X application will accept the -display option.

• Second, every X application will look at the $DISPLAY environment variable if no -display option is given, to determine the X server to contact.

The X server to contact is written as <hostname>:<servernumber>[.<displaynumber>], with <hostname> being the IP address or hostname of the system where the X server is running, <servernumber> the instance of the X server to contact5, and <displaynumber> the screen to use.6

5 One system might be running multiple servers, although this is rare.6 One X server may handle multiple screens simultaneously on so-called dual-headed systems.

$�� /��.�

? ��'��F�� +��1��,��@'�'

��1��R9�D:QG%��@'�'��1��

��

�� !�� !��

!��2�� 1��"��@'�'

��1��"��

!�� #� ��1��=��



Student Notebook

You can imagine that it is not desirable that the whole internet can redirect the graphical output of their commands to your screen. Therefore, doing this is by default disabled but can be enabled.

The first, safest method is by using the xauth mechanism. This works roughly as follows:

• When your X server is started, the startup scripts ensure that a random number, called the "authorization record" is generated. These records are stored in the $HOME/.Xauthority file.

• Any client who wants to connect to the X server needs to present this authorization record. If no or an invalid authorization is presented, then access is disabled.

Since normally all applications are started by the same person who started the X server, they all use the same .Xauthority file and present the right record.

• A client on a remote host obviously cannot access the .Xauthority file directly, so the authorization record needs to be transferred manually to that other host. This is a two-part process.

First, on the host where the X server is running, you need to extract the correct record from the .Xauthority file and store it in a file. This is done with the following command:

xauth extract xauthfile client:0.0

This means that the authorization record to connect to client:0.0 needs to be stored in the file xauthfile.

You then transfer the file to the other system (using FTP, scp, rcp or any other means), and add it to the .Xauthority file there, with the following command:

xauth merge xauthfile

Any application started on this host, with the correct -display option or $DISPLAY environment variable set will now use this authorization record to connect to the X server.

Of course, smarter ways of doing this are also possible. How about, for instance:

xauth extract - client:0.0 | rsh host xauth merge - rsh host xeyes -display client:0.0

The second method is less safe but more convenient. In this case, the user who has already started the X server issues the xhost +<hostname> command. This command allows all connections originating from <hostname> to succeed. This is obviously less secure, since every user on that particular host is now able to make a connection, not just the intended user. And this method is vulnerable to IP address spoofing and DNS poisoning.

Note: If you log in to another system using telnet or ssh, then the telnet or ssh daemon will typically set the $DISPLAY variable for you. ssh will even handle xauth authentication for you, and will make sure that the communication between the X client and server is encrypted.




Uempty

Figure 6-19. X Sessions Networked LX032.0

Notes:

The visual shows the next level of networking X-Windows. In this case, both the applications and the window manager are running on the remote system. Only the XFree86 Server is running locally.

A�"�� (��#��

�� F� �� !�A"�-��%

F��=;4��

�� /��



Student Notebook

Figure 6-20. X Sessions over TCP/IP LX032.0

Notes:

In order to run your X-session over a network, you need to set up your display manager so that it accepts session requests over a network. How this is done depends on your session manager.

For xdm, there are two things you need to do:

• You need to edit the /etc/X11/xdm/Xaccess file so that it allows any host to get a login window. The line that specifies this is usually already there, but is commented out. So you just need to uncomment this line.

• You also need to edit the /etc/X11/xdm/xdm-config file because most distributions have set the XDMCP port to zero (meaning: invalid port) as a safety feature. This is usually done at the last line of this file, so if you comment out this line (with an exclamation mark), you've disabled this safety feature.

A�"�� /��.�

? �� .��!��

3��A��AF((A4�AF�� A��AF((A4�A4�,��

��3��A��A%��A%�A%�� A��A%��A%�AF��

��3��A��AF((A��A��>��

? ��F� �� A�3I��6�� 7




Uempty
For kdm, there are again two things you need to do:
• You need to edit the /etc/kde/kdm/Xaccess file so that it allows any host to get a login window. The line that specifies this is usually already there, but is commented out. So you just need to uncomment this line.

• You need to edit the /etc/kde/kdm/kdmrc file and enable xdmcp direct and indirect requests.

For gdm, the procedure is again different. Here, you only need to edit the file /etc/X11/gdm/gdm.conf to enable xdmcp direct and indirect requests.

When you're done setting up your display manager, you need to restart it. Then you need to start the X server on the client workstation. Since the only program running here is XFree86, we can start it with the X command. We only need to tell it that it has to query the display manager to get a login prompt and a session. So the complete command becomes X -query <hostname>



Student Notebook

Figure 6-21. Chooser Sessions LX032.0

Notes:

You can imagine having multiple display managers in your environment. In that case, it is very useful to be able to choose the display manager you are going to use. This is done using a chooser. Usually, this functionality is built into the session manager so we don't need to configure a separate program. We just call the session manager a little differently.

If the session manager receives a so-called indirect query, it does a broadcast over the network to discover all systems that are willing to manage displays, and displays a list of these hosts. You can choose one of these hosts, and this host will then manage an X-session for you.

To start X and receive a chooser, the command line is X -indirect <hostname>

��"��

��/� ��#��

� �*� ��*�.��/� ��

�� A�3� ��6�� 7




Uempty

Figure 6-22. Font Server LX032.0

Notes:

In general, X applications do not ask the X server (XFree86) to display individual pixels, but ask it to display complex structures like rectangles, circles, lines and so on. Furthermore, they can also ask the X server to display a certain character out of a fontset. This saves a tremendous amount of bandwidth.

For this to work, the X server needs to have available all the fonts an application would possibly use. Obviously this leads to a large management problem if multiple custom fonts are installed and used beyond the basic set.

To cope with this problem you can use a font server. This is a central server which holds all the fonts that are used in your organization. When XFree86 needs to display a font, it downloads it in real-time from the font server. This saves you from needing a large set of font files on each client workstation.

Most distributions come with a font server enabled by default, and the local XFree86 always uses the local font server. This font server is usually accessed through a so-called Unix socket. The specification in /etc/X11/XF86Config will thus look like this:

%� ��"��

�� #��F��#�� %��

��#��%��F��=;�� %�� #��!� ��#��#��

�!��@(882-"F��%��A�A>�� ,� �4A��@(88

!� �� A��AF((A��A��

�� #�� F�=;!� ��F�=;!� ��,:�

��)5��)��5��D��)��@��'')��5��D��)��@��'')F��



Student Notebook

Section "Files" FontPath "unix/:7100" EndSection

In order to use a font server over the network, you specify it using the following syntax in the /etc/X11/XF86Config file:

Section "Files" FontPath "tcp/hostname:7100" EndSection

Depending on your distribution, you also might need to enable the font server to serve network requests. Some distributions disable this by default.




Uempty


Notes:


1.

2.

3.

��

What is the function of XFree86?

______________________________________________

What is the function of a window manager?______________________________________________

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

______________________________________________

______________________________________________

1)

2)

3)



Student Notebook


Notes:

"��

��F��

!� ��F��=;

�� F

��

2��F��#�� %




Uempty
Unit 7. Block Devices, RAID and LVM

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



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


Accountability:



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

Student Notebook


Notes:

��

��

-�� %��#��

��#��%��#��

��#�� "�3�� ! "��%�

�� %�� #��

2��$�/��%�

!� �� 1/

!� �� $�"�




Uempty

Figure 7-2. Block Devices LX032.0

Notes:

A block device in the Linux world is any device which allows "random" access. This means that it is possible to write something to location n, and then go backwards to read something from location m. In other words: a block device is any device that supports the "seek" command. Typical examples are hard disks, hard disk partitions, floppy disks, RAM disks, LVM volumes, RAID volumes and files.

Examples of devices that are not block device are printers, consoles and network adapters. And examples of devices that can be both are tape drives (can be used as block device, but seeks are terribly slow), or CD-RW drives (reading is done as block device, writing as serial device).

A block device can be used for different things, for example to hold a filesystem, as a swap space, or "raw", for instance using tar. But as we will see in this lecture, it can also be used for LVM and/or RAID.

��&��

��*5��%��#��*�� #��*�� *��'*��%�*+

34��%��%�� %�$�/��%��1/�#��$�"��#��

��%��#�� *��*�� $�"�� A��1/



Student Notebook

Figure 7-3. Block Device Naming LX032.0

Notes:

Block devices all have a special file representation in /dev.

��&��(��

��%��#��#�� A��#>��$�0��0��"�,��.�'��Q��;��'''��"�'�$�0��0��?.�'��Q��;��'''��$�0��0��*.�'��Q��;��'''��

��8��(��>>>��%�'�4�=+

��>>>��"�3��%�'�4�=+

��>>>�� ! "��%�'�4�(7=+




Uempty

Figure 7-4. Floppy Disks LX032.0

Notes:

Floppy disks are slow and have a fairly low capacity, but their biggest advantage is that they are a true worldwide standard for removable devices.

If you have bought unformatted floppy disks, then you might need to low-level format them first with the correct size information. This is done with the fdformat command, with a special /dev entry that identifies the density and size of the disk.

Floppy disk drives typically have a mechanical eject. This means that the system cannot detect or prevent that a user is ejecting the disk. That might be a problem if the disk contains a filesystem, since Linux performs write caching on all filesystems, meaning that write requests are not carried out immediately, but are only done when the disk has been idle for some time. This is done to increase performance by optimizing cache usage. However, if a user ejects a disk without first unmounting it (unmounting a disk will cause all data to be written to disk), the data not yet written to disk will be lost. So you always need to unmount a floppy disk and wait for the disk light to go off before ejecting.1

1 Some other architectures, such as the Sun Sparc, have a software eject, where the disk can only be ejected by running the ejectcommand. And this command only works if the disk is not mounted.

%��&��

�� #��#��

��%�� &��&�� "�"��"�'��;;'

�� %��M��



Student Notebook

Figure 7-5. Hard Disks LX032.0

Notes:

Hard disks are the most common form of persistent storage on a typical Linux system. Two types are most common on the Intel (and other) architectures: IDE and SCSI.

IDE and the newer variant, E-IDE allow a maximum of two disks to be attached to one "bus" (ribbon cable). Only one of these disks can have its controller active, and is then said to be "master" of the bus. The controller of the master controls the operation of the slave too.

A typical E-IDE adapter supports two buses, and there is a maximum of two E-IDE adapters per system, yielding a total of eight E-IDE devices per system.

Most CD-ROM, CD-RW and DVD players for the home market are attached as if they were IDE devices too. This is governed by the ATAPI standard.

SCSI is a technology which is technically superior to IDE, but generally more expensive. It has various subtypes which each have their own performance characteristics and physical connector size and types. Depending on the subtype, there is a maximum of 8 or 16 devices on each bus, one of which is the SCSI controller itself. This leads to a maximum of 7 or 15 disks on each bus. However, an adapter typically supports multiple buses, and

)��&��

/�� #��

�� "�3�� ! "

"�3�'" ��#��3�� +/�4�7��%��'��A��#�+�� /�4�7�� /�4�7�� !�,$?/�'��"+��#�� A��#A��>>>��

! "�' ��!�� " ��+�� ,��>>>/�4�@��(J��%�� '�� +-�� D� ��4� ��#�� "�3��!�,$?/��&��#��>>>��#�� A��#A��>>>��&��>>>��4




Uempty
multiple SCSI adapters may be used simultaneously, as long as each adapter has its own IRQ.
The SCSI standard also allows for CD, DVD, tape drives, Zip drives and other block devices to be attached.

The Linux kernel supports a total of 128 SCSI disks by default. These devices are numbered /dev/sda through /dev/sdz, then /dev/sdaa through /dev/sddx.



Student Notebook

Figure 7-6. Hard Disk Partitions LX032.0

Notes:

All IDE and SCSI disks can be partitioned into smaller chunks, which can be used independent of each other.

The partitioning scheme used on Intel machines dates back to the IBM XT Personal Computer, when a 10 MB disk was extremely expensive and state-of the art.2

The partition table is stored in the last 64 bytes of the master boot record, and allows for a total of 4 primary partitions to be defined. This used to be enough, but later on it became apparent that more partitions were needed.

At that point in time, it was decided that one of these primary partitions could have a special identification, which allowed it to be used as an extended partition, which could be split up further into a number of logical partitions. Since the extended partition does not use a fixed-size partition table but rather a linked list, the number of logical partitions is unlimited.

Linux by default supports a maximum number of 63 logical partitions on IDE disks, and a maximum of 11 logical partitions on SCSI disks. The last has to do with SCSI subdevice numbering: According to the SCSI standard, each device can be split up into 16 2 Most of the earliest IBM PCs came without a hard disk and only had one 5.25" floppy disk of 360 KB...

)��&��

"�3�� ! "��%��

/�4��

? �� 4��

� ��4�� '�� 4��4�;<��"�3��((�� ! "+

��

��

�� )J

�� 4�A

�� 4�A��

�� 4��

��(�� )J��

��7�� 4��

��

��J�� 4��

�� A

��;�� 4��

�� A��

��@�� 4��

��%�� /5$��




Uempty
subdevices. One is used for the device itself, four for the primary partitions, which leaves 11 for the logical partitions.


Student Notebook

Figure 7-7. Partitioning Tools LX032.0

Notes:

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

�� /��

�� /��!��? A�� N��!� ��A��&�A�#�A��

��? �� 4�� !� �� 4��

��%1��#��!�? ��*��%*�� ? �� ? A7�� 4��>>>

��D��H�� 4��#��>� �>��!� ��A��&�A�#�A��

��%�� 4��




Uempty

Figure 7-8. RAM Disks LX032.0

Notes:

A RAM disk is a block device which is not stored on persistent media, but rather in the memory of the system. It is not used often, but can sometimes be handy, especially if you need a really fast hard disk, or if your system doesn't have any persistent media on board.

Linux supports a maximum of 16 RAM disks by default, but can be recompiled to support up to 255 of them. They are automatically created when you start them, with a size dependent of the amount of data that you write to it. And since they are stored in memory, their contents vanish when you shut down your system.

RAM disks occupy memory and will keep doing that until you shutdown your system or deallocate the RAM disk by hand with the freeramdisk command. Unfortunately, this command is not included by default in all distributions.

One of the more common uses of a RAM disk is to help boot your system. Suppose for instance that you have a system with SCSI disks, but you have compiled your support for SCSI in the form of modules. In order for the Linux kernel to access the SCSI disks then, it needs to load the SCSI modules first. But these modules are stored on the SCSI disk... To solve this problem, you need to create an "initial root disk", which is a file containing a

�$��&��

��$�/��%��%��#�� &��

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

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

��$�/��%��"��'

-�� G

� �� '� ��+��%��

!� �� *��*��



Student Notebook

compressed ext2 filesystem with the SCSI modules in it. Such a file can be created using mkinitrd. LILO loads this file into memory alongside the kernel, using the SCSI BIOS. When Linux starts, it uncompresses this disk into a RAM disk and is thus able to load the SCSI modules. Only then can it actually mount the true root filesystem from the SCSI disk.




Uempty

Figure 7-9. The "loop" Device LX032.0

Notes:

Files are block devices too. The most obvious example of this is a tar file, which is essentially an image of a tape. In most cases, a file can be specified where a block device is typically used, and vice versa.

There is one exception to this though: A file containing a filesystem cannot be mounted directly. For this to succeed, the use of a special "loop" device is needed. Linux supports a maximum of 16 of these devices by default, but this can be changed with a kernel recompile. Linux will automatically invoke one of these devices if the -o loop option is specified with the mount command, as shown in the visual. This allows you to mount, for instance, floppy disk or ISO images.

/��*��*�&��

��*��*��#��%��#��

�� 4��4��(;��#��A��#A��

34��$��"�,��.��?��



Student Notebook

Figure 7-10. Logical Volume Management (1) LX032.0

Notes:

Logical Volume Management is a technique to overcome some limitations that are imposed on the system with the traditional partitioning scheme:

• It is virtually impossible to resize or move a partitions since other partitions are always in the way.

• The largest partition you can create is one that spans your whole disk, and thus the size of any partition is limited by your disk size.

To overcome these limitations, LVM introduces some extra abstraction layers in this scheme:

1. Every hard disk or hard disk partition is assigned to a Volume Group (VG). Each hard disk or hard disk partition is then called a Physical Volume.

2. Each Physical Volume is split into Physical Extents of identical size. The default size of a PE is 4 MB, but this can be changed when the VG is defined.

��5�� 0=1

�� %�� #��#� ��

1��&��#�� &��%��&�

��1��/� �� #��#� ��

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

� ��1�� %�

�� &�� 1��3�

�� &��1D��1�




Uempty
3. PEs in a VG are then combined into Logical Volumes. Each logical volume is a block device and can be used to hold a filesystem, for instance. Since an LV always consists of 1 or more PEs, its size will always be a multiple of 4 MB.
The PEs that are part of an LV do not have to be on the same physical disk or disk partition, as long as they are all part of the same volume group. That means that a logical volume can be larger than your physical disk size. Furthermore, the PEs that are part of an LV do not have to be sequentially located on disk. This means that it is easy to extend an LV.

If a volume group becomes full, it can be extended by adding another PV (a hard disk or hard disk partition).



Student Notebook

Figure 7-11. Logical Volume Management (2) LX032.0

Notes:

The visual shows a volume group that consists of two physical volumes. In this case, whole disks are used as physical volumes, but we can use disk partitions too. Each PV is split into a number of PEs (nine in this case), which are our building blocks for building LVs.

Four LVs have been created, with two spanning two PVs. One PE is still unallocated and can be used to extend an already existing LV, or can be used to create a new LV.

��5�� 0:1

�3 �3 �3

�3 �3 �3

�3 �3 �3

�3 �3 �3

�3 �3 �3

�3 �3 �3

#��

��#��

'��%�� +

��#��

'��%�� +

��#��




Uempty

Figure 7-12. LVM Implementation Overview LX032.0

Notes:

Implementing LVM comes down to three tasks:

• First, you need to identify which physical volumes you are going to use, and format them accordingly. This is done with the pvcreate command.

• Second, you need to create the volume group which is going to exist of the physical volumes you created in the first step. This is done with the vgcreate command.

• Last, you need to create the logical volumes in the volume group. This is done with the lvcreate command.

After this, you can use your logical volumes, now called /dev/<VGname>/<LVname>as regular block devices.

�5�� #

��%�� A�� '��=�+�� 4�� %�

" ��&��#��'��%�� +��$?

!��#��*#�88*��#��''��$?

!��#��*�#88*�� #��:�&'+��''��''

!� � ��.��.��>>.��>>��%��#��



Student Notebook

Figure 7-13. Physical Volume Commands LX032.0

Notes:

Two commands allow you to manage your physical volumes:

pvcreate This command initializes a physical volume.

pvmove This command allows you to move all PEs on a PV to another PV within the same volume group. This is useful if you want to take that PV out of the volume group.

pvdisplay This command allows you to view information about a PV.

��5��

��6��7" ��&��#��

��J3 �6��7K�6��7�J6�� 7K/�#��3�� 1�� 1�� #��

��6��7�� 1




Uempty

Figure 7-14. Volume Group Commands LX032.0

Notes:

Several commands are available to let you work with volume groups:

vgcreate This command allows you to create a new volume group. As part of the command, you need to specify the PE size that is going to be used in this volume group. Furthermore, you always need to specify the name of at least one physical volume.

vgdisplay This command displays information about a volume group.

vgextend This command adds a physical volume (which has already been initialized with pvcreate) to a volume group.

vgreduce This command removes a physical volume (which has already been emptied with pvmove) from the volume group.

vgchange This command changes attributes of a volume group.

The most important change is to deactivate a volume group with the vgchange -a n <vg> command. This needs to be done before either vgexport or vgremove can be executed.

5��2��

��J3�6��4�7K�6�� 7�6��7�J6��7��K!��#��

��J6��7K�� #��

��!�� 6��7�6��7�J6��7��K��#��#��

��6��7�6��7�J6��7��K$��#��#��#��

�� J�� K�6��7!�� #��

��!��6��734��#��'�%�� #�+

��6��7�6��7�J6��7��K"��#��'�%��#�+

��6��7��#��



Student Notebook

vgexport This command exports a volume group. In other words: it makes it inactive. This needs to be done before you can remove the corresponding disks and put them in another machine.

vgimport This command imports a volume group. In other words: it makes it active. This needs to be done after you have added a disk or set of disks to your system which already contain a volume group.

vgremove This command deletes a volume group.




Uempty

Figure 7-15. Logical Volume Commands LX032.0

Notes:

There are several commands that let you manage logical volumes too:

lvcreate This command creates a logical volume of the specified size, with an optional name, in a certain volume group. You can also specify the physical volumes to be used.

lvdisplay This command displays information about a logical volume.

lvextend This command extends a logical volume. In other words: It appends physical extents at the end.

lvreduce This command reduces a logical volume. In other words: It removes physical extents from the end.

lvremove This command removes a logical volume.

��5��

��3��6�4�7�J3 �6�� 7K�6��7�J6��7��K!��#�� #��

��6��7�J6��7��K�� #��

��!�� 3��JLK6�4�7�6��7�J6��7��K34�� #�� &��O��&�P��SO��&�P��

��3��J3K6�4�7�6��7$��&��#�� &��O��&�P��#��,O��&�P��

��6��7�J6��7��K$��#��#��



Student Notebook

Figure 7-16. Additional LVM Considerations LX032.0

Notes:

There are several considerations when working with LVM:

First, understand that extending/reducing the size of a logical volume does not automatically extend/reduce the filesystem in that logical volume. You need to extend/reduce the filesystem manually after you extend, or before you reduce a logical volume. The same is true for swap spaces.

When your volume group consists of multiple physical disks, then it might be advantageous to use striping on logical volumes. This can improve read/write performance, especially if large files (larger than 4 MB) are concerned.

The Linux LVM implementation has a "snapshot" capability. This allows you to make instant copies of logical volumes. There are several benefits from this. Consider for instance the situation where your logical volume contains a database which needs to be "up" at all times, but does not allow you to make backups while running. In that case, with LVM, you can stop the database, make a snapshot of the logical volume that holds the database, and start the database again. This whole procedure takes less than a minute. After this is done, you can mount the snapshot logical volume and make the backup at your leisure.

$�� 5��

34�� A$�� #�� 4�� A�� #��G

"��%�� A��

��

�� 4��1/�� *� ��*��!� ��%��

�1/�� .��.��

�1/�� .��.�� .

2 ��%��1/�� 4��1/�� '��C+




Uempty
Kernel information about LVM can be obtained from the /proc/lvm tree.
LVM configuration is stored in /etc/lvmconf. Since the LVM commands are able to modify these configuration files themselves, it is almost never necessary to edit these files by hand.

Unlike other LVM implementations (like AIX), the Linux LVM implementation does not (yet?) support mirroring.



Student Notebook

Figure 7-17. RAID LX032.0

Notes:

RAID, which is short for "Redundant Array of Inexpensive Disks" was developed separate from LVM as a technique to increase the performance of hard disks by packing a large number of them together.

This was done because people had observed that typical PC hard disks, especially in the early days of the PC, were slower, less reliable and smaller than the then-used mainframe-quality disks, but were also less expensive.

So what people started doing was pack a large number of them together, with some additional control software (usually implemented on a dedicated hardware chip), and use them as if it were one logical device that was either faster, more reliable or larger than the individual disks, but was still less expensive than buying one mainframe-quality disk that would do the same.

It is important to note that the three features (speed, reliability or size) are, to a certain extent, mutually exclusive. It is possible to create a RAID array that is both faster, more reliable and larger than a single disk, but this requires a lot of hardware. Usually, RAID arrays are only used to boost either speed, reliability or size, but not all simultaneously.

�$&

*$�� " �4� ��#��%�*

��!��%��4� ��#�� ,.��%��

��>>>��4� ��#�

"��2��%�� #��

��>>>� ��#�� 4� ��#�




Uempty

Figure 7-18. RAID Levels (1) LX032.0

Notes:

In the RAID standards, several different "levels" have been defined. All these levels have different ways of storing the data on disk and thus will exhibit different characteristics.

The first method, RAID-Linear is actually not listed in the RAID standard. It is implemented in Linux as a way of simply combining two or more partitions on different disks into one, larger block device. First the first partition is written until it is full, and then the second disk is used.

RAID level zero, or RAID-0 for short, is nearly the same as RAID-Linear. With RAID-0 however, data is striped across the different disks. This means that reading or writing a large file actually puts both disks to work, which theoretically will lead to a doubled throughput (that is, if your controller, bus, memory and CPU can sustain that). If one disk is larger than the other, then the last part of the data will not be striped but just stored on the larger disk.

It would seem that RAID-0 is always preferable over RAID-Linear, but in reality, it is not. Consider for instance the situation where one of your disks crashes. With RAID-Linear, there is a good chance that you can retrieve at least half of your files. With RAID-0, every

�$&��0=1

$�"�,��

(7<:J

;@=)

(8

$�"�,8��

(<J@)

7:;=

(8

$�"�,(��

(7<:J

(7<:J

$�"�,:�� %

(<J@)

7:;=

(8

$�"�,J��

(<@)

7J=

:;(8



Student Notebook

single file (except for the really small ones) was stored at least partly on the disk that had crashed. You should therefore use RAID-0 only for data which can be missed or easily restored.3

RAID-1 uses the second (and third disk) for mirroring: data written to the first disk is written to all other disks as well. This will cost a lot of disk space, but means that you can sustain multiple disk crashes without losing your data.

RAID-4 also offers redundancy, but not by mirroring but by storing parity information4 on a separate disk. Should one disk (or the parity disk) fail, then the data on this disk can be calculated from the data on the other disks. RAID-4 therefore needs at least three disks.

RAID-4 uses striping to store the data blocks on disk for increased performance.

RAID-5 is similar to RAID-4 in that it calculates the parity of two disk blocks and stores this in a third disk block. It also stripes the data onto the disks. The difference between RAID-4 and RAID-5 is that RAID-4 stores all parity information on the same disk. This disk then quickly becomes a bottleneck, unless this disk is significantly faster than the others. With RAID-5, the parity information is striped too, leading to better performance.

Several other RAID levels exist, but these are not implemented in Linux, and not widely used anyway.

3 The author of this course uses a RAID-0 array for storing the /export filesystem of a network install server. If a disk fails, the data on itcan simply be restored from the distribution CDs.4 The parity in this case is calculated by XORing the data on disk 1 with the data on disk 2. If one of the three elements (disk1, disk2,parity) should fail, then that element can be calculated based on the other two.




Uempty

Figure 7-19. RAID Levels (2) LX032.0

Notes:

As seen in the visual, the different RAID levels use different ways of storing the data on disk. This leads to different characteristics. What you should note is that RAID-5 is not "better" than RAID-1. It is just different and might or might not be suited for your circumstances.

�$&��0:1

$�"��#��#�� $�"�,J�� *��*�� $�"�,(

2��$�"��#��

$�"��#��

/� �K��%�

$��

��

$�� <4(D��%

?��%�

�� 7 �.�� .�� <�D� !� ��%��&�� .��

8 7 �� <�D�

( 7 ��

�� (�D� !� �� -,(��%��

: < ��

�� 7�D� !� �� (��%��%�� %

J < ��

��

�� 7�D� !� �� (��%��!�2�� #�



Student Notebook

Figure 7-20. Linux RAID Support LX032.0

Notes:

Linux supports both software RAID and hardware RAID.

Software RAID means that all the RAID logic is built into the Linux kernel. The user can access the partitions directly, or go through the RAID layer and access the RAID volumes, which are called /dev/mdn. To implement this, you need the raidtools package, which is usually supplied as part of your distribution. For Software RAID, the only thing you need is more than one (IDE and/or SCSI) hard disk. In fact, you can even test it by using multiple partitions on one single disk, but that negates any benefit you might want to gain from RAID

Hardware RAID is typically implemented in special adapter cards, which look like SCSI controllers (in fact, they usually are) but contain some special RAID chipsets. Most of these controllers are supported by Linux. In fact, Linux just detects a single large disk instead of multiple, smaller ones. Configuring these adapter cards might require special software, but once the cards are configured, no additional software is needed.

�� !��$&�"��

��$�"�"�� 4�%�� -��%��2��%�� $�"��#��#�� .��.��

��$�"�"�� 4�%�� D� �� '�� #�� 4+$�"��#�� ! "��%




Uempty

Figure 7-21. Linux Software RAID Implementation LX032.0

Notes:

To implement software RAID under Linux, you need to do the following:

First, create the partitions you will want to use as part of your RAID array, if you are not going to use whole disks. Of course, these partitions should all be created on different disks, or else the whole idea of RAID is not applicable (Linux Software RAID does allow you to use multiple partitions on the same disk though, for testing purposes). The partitions created should have type fd (hexadecimal).

Then, create the /etc/raidtab file. This file contains the logical name and characteristics for your RAID volume (/dev/mdn) and then lists the disks that make up that volume.

When this is done, you need to initialize the RAID volume with mkraid, after which you need to start your RAID subsystem with raidstart It is useful to know that the raidstart -a command is usually part of the startup scripts (rc.sysinit) that come with your distribution.

When all is done, you can access the block device /dev/mdn as any block device.

�� !�"��#��$&��

!��$�"�� '�� 4�$�"��+

!��.��.��

��'��'��$��'��(��*

��'��$�

��

" ��&��$�"��#��.��.��>

��$�"��#��.��.��>��3�� A��A��>�A��>��

!� � ��%��#��A��#A�8



Student Notebook

Figure 7-22. Additional RAID Considerations LX032.0

Notes:

There are a few things to note when using RAID:

Always put your RAID partitions on different disks, or you will nullify any advantage that RAID might try to give you.

If possible, use different SCSI and/or IDE controllers for the different disks (or partitions) that make up your RAID volume. This will increase your performance and reliability.

Never use RAID for your /boot partition, and note that if you use RAID for your root (/) partition, you will have to create an initial root disk.

Software RAID-4 and RAID-5 needs a lot of CPU time to perform the parity calculations.

For maximum reliability, RAID-4 and RAID-5 allows you to configure spare disks. These disks (usually only one per array) are not used, until one of the other disks in the array fails. If that happens the RAID software will automatically start using the spare disk instead of the disk that failed. The data on that disk is created automatically from the parity information on the other disks.

$�� $&��

��$�"�� %�

2�� ! "��"�3�� %��$�"��#��

�� $�"��A��

$��'A+�� $�"��.�� '� ��+

!��

��$�"�,:�� $�"�,J� ��!�2��G

��4��%�"�� %�� %��,�� %�� %�

�� $�"�,�� $�"�,8��




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


Notes:


1.

2.

3.

��

RAID volumes can be used as Physical Volumes in an LVM setup.

Mirroring is offered by RAID level:a. Linearb. Zeroc. Oned. Foure. Five

What command is used to create a RAM disk?______________________________________________

1)

2)

3)

T/F




Uempty


Notes:

' ��"��

5��%��#��#��

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

5��%��#�� *��*

��1��/� �� #�� %��&�� &��

$�"�� 4� ��#��#�� "�3�� ! "��%�� #��#�� #��%�



Student Notebook




Uempty
Unit 8. Filesystems

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



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


Accountability:



© Copyright IBM Corp. 2001, 2002 Unit 8. Filesystems 8-1

Student Notebook


Notes:

��

��

��

��

��

��

!��A�� A� ��

!��

�� .��




Uempty

Figure 8-2. What is a File? LX032.0

Notes:

A UNIX file is a consecutive number of bytes with no internal structure. Applications will have to define their own internal structure (for instance records). These files are stored and referenced in a filesystem. One file can have multiple references (file names).

;��%��M

!� ��#�� -�� '�� +

�� !� ��#�� ' ��+

��4��5��%��!��,P��#�� %��,P�" ��



Student Notebook

Figure 8-3. What is a Filesystem? LX032.0

Notes:

The references to a file (the file names) are usually stored in a hierarchical system of directories, subdirectories and so on.

By using a mechanism called the virtual filesystem the internals of each filesystem are hidden from the user.

A filesystem is mounted on a mount point, which is an empty directory in another (already mounted) filesystem. The root filesystem is activated at system startup, and contains the mount points for all other filesystems.

A filesystem can be stored in any block device.

;��%��M

��

��

" �� #��

��

�� $��#��

�� %��#��%��%�� $�"��1/�#��$�/��%




Uempty

Figure 8-4. Filesystems Supported LX032.0

Notes:

Linux supports a wealth of filesystems. Its native filesystem is ext2fs, the second extended filesystem. Currently a number of new filesystems for Linux are being developed and are starting to become available in distributions. These include ext3, ReiserFS, IBM’s JFS and xfs. All have distinct advantages over ext2fs, but are not as well tested yet.

Filesystems from other operating systems are also supported.

%��"��

/�� 4�7��

-��4�<��$�� "5/�T� ��4��

?��2-"F�� 4��4��4��

��,(7��,(;��,<7��1��-�� '��,� ��+

�� '? A7+��,� �� '/�� +��,� ��

�� '��+

��1��!�� F� �4

!�,$?/�'" ?�);;8+

2/ �? �'2-"F,��%�� / ,�? +

-� �'-��%�� +

/5� �'�� +��-!�� '-�#��-��+

A��'��%�� +



Student Notebook

Figure 8-5. A Typical UNIX Filesystem LX032.0

Notes:

Most filesystems used on a Linux system are typical UNIX filesystems regarding the layout of the filesystem. When creating (formatting) the filesystem in the partition, the partition is split up in blocks of 1024 bytes each (default). Each block is given a specific function:

• Superblock

• Inode (short for index node) block

• Indirect block

• Data block

It is not possible to combine functions in a block.

$�/��'(A�%��

�� #�� %��(87:��'��+

5��%�� #�� %" ��'" ��4� ��+��%'��+�� %��%

� � � � � ��




Uempty

Figure 8-6. Superblock LX032.0

Notes:

The first block of the filesystem (block 1) will be the superblock. It is a very important block, since it contains information about the rest of the filesystem. Copies therefore are kept on block 8193, 16385 and so on. Should block 1 become corrupt, then mount will attempt to use the other superblocks.

The superblock contains general information about the filesystem, for instance, the time of last usage, the last used mountpoint, the blocksize, and so on. Furthermore, the superblock (indirectly) points to the list of free inodes and the list of free blocks. Last, the superblock contains an (indirect) pointer to the root directory of the filesystem.

"��

��%��#��'��=()<��(;<=J��>>>+

!� �� A��5��%��&�� %��

� � � � � ��



Student Notebook

Figure 8-7. Inodes (Index Nodes) LX032.0

Notes:

An inode is 256 bytes large. With a blocksize of 1024 bytes, this means that there are four inodes in a block. Each inode contains information about a file: user/group information, permissions, size, ctime (creation time), atime (last accessed time) and mtime (last modified time).

It also contains information about the data blocks where the file resides. This structure is a little complicated but very efficient:

The first twelve data blocks (12 KB) are directly addressed; the block numbers are stored in the inode itself.

The next data blocks are indirectly addressed. The inode contains a pointer to an indirect block, and the indirect block contains the block numbers of the data blocks. Since each pointer is four bytes, we can address 256 data blocks, assuming a blocksize of 1024 bytes.

The next 65536 data blocks are double indirectly addressed: The inode contains a pointer to a double indirect block, the double indirect block contains pointers to indirect blocks, and

��0 ��!�(��1

7J;��':��%��(87:��+

!� �� &��>>>

!� �� %�

!� �� %�� %�� %

" ��%�� %�� %�� %�� %�� %�

� � � � � ��




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



Student Notebook

Figure 8-8. Data Blocks LX032.0

Notes:

The data blocks finally contain the data of the file itself.

A file may be of a special type: a directory. In this case the data block will contain the file names in that directory, and the number of the corresponding inode. This leads to a very interesting concept: a file may have multiple names, even in multiple directories, as long as the directories are on the same filesystem.

&��

!� ��

�� >

�� G�'?��#�� +

" ��<;): ��;:(@ " ��=<)( ��)8:(

��

> ��<;):

>> ��(<

4�& ��=<)(

��=<)(

��

��;:(@

��&��(87:

��8

��8

��

��)8:(

��&��7(

��8

��8

�� %��7

��4�&>

��




Uempty

Figure 8-9. So... LX032.0

Notes:

It is not important to know the exact internal structure of the ext2fs filesystem. What is important to know is that there are two important components of a filesystem: inodes and data blocks. Any file needs an inode and one or more data blocks. If there are no more inodes or data blocks available in the filesystem, the filesystem is full.

If you really want to use your filesystem to the limit, it is important to tune it according to the data you expect.

The blocksize is 1024 bytes by default. However, this size should be increased if you expect a large number of large files.

The bytes-per-inode is 4096 by default. With a blocksize of 1024 this means that for every four data blocks there is one inode available. If you expect a large number of small files, decrease this value, since you will probably want one or two inodes per data block.

In general, it is easier to explain to the users why a filesystem is full if there are no more data blocks left, than it is to explain that a filesystem is full if you ran out of inodes. And

"��

�� %�>

��-�� #��-��%��#��

��

5��%��&��'(87:��78:=��:8);��+5��,��,� ��':8);��+



Student Notebook

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




Uempty

Figure 8-10. Other Filesystem Features LX032.0

Notes:

All filesystems are able to store your files, possibly under multiple names. They also all support the default UNIX permissions (rwxrwxrwx). They do however differ in the additional features that they can offer. Some of the features that can be offered by filesystems are:

• Access Control Lists: These are lists of user and/or group names with the permissions that these users/groups might have on the file. This allows you to set permissions that go further than the standard possibilities. It is for instance possible to define that a certain group is able to execute a program with the SUID bit set, and another group is able to execute it, but without the SUID bit.

Currently, the Linux kernel itself does not have support for ACLs, although certain filesystems may support it. A kernel patch is available to add ACL support to the Linux kernel, but this patch has not been integrated into the mainstream kernel (at the time of this writing).

• Journaling: This is a technique where every intended write action is first listed in a journal (a fixed-size file or partition) and only then performed. If the action has succeeded, this is listed in the journal as well.

��%��%��

�� #��

$�� 0$��1��4�� M��4��4��4

N�� 0��M�� %�� /�%��%��

-!�� 34��

�� #��

�� 4��



Student Notebook

This of course leads to a performance decrease, but yields one important benefit: When the system crashes, you don't have to do an fsck of the whole disk to look for inconsistencies, but just need to look at the journal and retrieve all transactions that were started but not finished. Only the disk areas that were involved in those transactions need to be searched.

An fsck on a crashed journaled filesystem will typically only take a few seconds, while a non-journaled filesystem may easily take several minutes, depending on the size of the filesystem.

• Extended File Attributes: This allows you to specify additional attributes of a file. An example is the immutable flag, which prevents anyone from modifying or deleting the file (even root), as long as this flag is set.

• Labels: These are labels that are attached to the filesystem itself (in the superblock). This allows you to specify a filesystem label instead of a device name in your /etc/fstab file. The advantage of this is that if you add or remove any disks and/or partitions, that your filesystems can still be found, even though they might now be located on a differently named device.

Apart from this, filesystems also differ in various optimization details. For example:

• Filesystems like ReiserFS and JFS do not use a linear list to hold the contents of a directory, but use binary or B+ trees for this. These trees are far faster to search and thus increase performance if you have a large number (1000 or more) files in one directory. This typically happens on news server, for instance.

• Some filesystems use a variable number of inodes, which are added and deleted when needed. This avoids the problem of running out of inodes, while you still have data blocks left.

• Filesystems may also use data blocks more efficiently, by storing multiple, smaller files in one data block.

• Some filesystems can work efficiently with “sparse files”. Sparse files are files which are mostly empty. They are the result of programs who open a new file for writing, and then lseek to a location somewhere in the file to write something there. The area before the written area is empty and need not be saved on disk - until the program actually starts writing there. Sparse files are common in databases.




Uempty

Figure 8-11. Creating a Filesystem LX032.0

Notes:

Once we have decided which block device we are going to use, and the type of filesystem we want, we are going to create it. This is usually done with some variation on the mkfs command, such as mke2fs, mkreiserfs or mkjfs.

Typical options include the blocksize to use, and the bytes-per-inode number. This last number determines the number of inodes to create on the filesystem, and should reflect the average size of the files on your filesystem, rounded down to the nearest 2n kilobytes (1024, 2048, 4096, ... bytes).1

1 If you round up rather than down, then you will run out of inodes before you run out of data blocks. That's harder to sell to your users.

�� %��

!�� #�� :��

��%�� S��

�� ,��%��&��%��&�,��,��,� �� ,��%��%��%�

34��"��$��'�;��;'<7��7



Student Notebook

Figure 8-12. Mounting a Filesystem LX032.0

Notes:

Mounting a filesystem is done with the mount command. The syntax is:

mount [-t <type>] [-o <options>] <device name> <mount point>

For instance: mount -t iso9660 -o ro /dev/cdrom /mnt/cdrom to mount the cd-rom device /dev/cdrom, which contains an iso9660 filesystem on the mount point /mnt/cdrom, read-only.

To show all mounted filesystems, use the mount command without arguments:

[root@sys1 /root]# mount /dev/hda2 on / type ext2 (rw) /dev/hda6 on /mountpoint type ext2 (rw) /dev/cdrom on /mnt/cdrom type iso9660 (ro) none on /proc type proc (rw) [root@sys1 /root]# _

�� %��

2�� #�� '��+?�� ?�� ?�� %

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

��




Uempty

Figure 8-13. Mounting Filesystems at System Startup LX032.0

Notes:

If filesystems need to be mounted automatically at system restart, or if you need to create shortcuts for fast mounting of common filesystems, add them to /etc/fstab. This file contains lines for each filesystem to be mounted. Every line consists of six fields:

• The block device which contains the filesystem.

Recent kernels also allow a "label" to be specified here, instead of the device. This is the label that is stored in the ext2 superblock. The kernel searches all ext2 filesystems for the filesystem holding this label and mount the first filesystem where the label matches. This is very useful if you make changes to your partition tables or the order of your disks (in particular, SCSI disks).

Labels are currently only supported on ext2 filesystems.

• The mountpoint at which the filesystem needs to be mounted.

• The type of the filesystem. Recent kernels also allow the "auto" type, which indicates that the kernel itself should try to figure out the filesystem type. This is useful for removable media, in particular floppy disks.

��A��A��

#��3#"�!%��#'�� 1��!� ��%�1

#��3#"�!��#�� 1��!� ��%�%

#��3#��)��#) #��)��&&/��! ��/�/

#��3#��/��#) #��)��! ��/�/

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

��;��(�� 1�� )��!'��>�

�.�,�B#'�� #'�� 1��!� ��%�1

�.�,�B#��#�� 1��!� ��%�%

#��3#��)��#) #��)��&&/��! ��/�/

#��3#��/��#) #��)��! ��/�/

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

�� %��"��"��



Student Notebook

• The options.

• A dump indicator (see man fstab).

• A sequence indicator for fsck (see man fstab).




Uempty

Figure 8-14. Mount Options LX032.0

Notes:

There are various options you can specify when mounting a filesystem. These options change the way the filesystem behaves while accessing it.

Options can be specified both when mounting a filesystem manually, by using the -o flag, and can be specified in the /etc/fstab file, in the fourth column. In both cases it is important that options should be separated by commas and not by spaces.

Some important options include:

noauto - Do not automatically mount the filesystem at startup. If this is not specified, the filesystems will automatically be mounted at system startup, or when issuing the mount -a command.

user - Allow ordinary users to mount this filesystem. Handy for floppy and CD-ROM drives. Only the user that mounted the filesystem can unmount it.

users - Same as user, but every user can unmount the filesystem.

owner - Same as user, but with the restriction that the user that wants to mount the filesystem has to be the owner of the device.

��

1��

��/�� 2�� # �� #��$�� #��$��,��

��

?�� 3�� 4��

?�� :��A��A��

��



Student Notebook

ro - Mount the filesystem read-only

nodev - Do not allow usage of block and character special devices on the filesystem.

noexec - Do not allow execution of programs on the filesystem.

nosuid - Do not allow suid and sgid bits to take effect. nodev, noexec and nosuid are mainly used for security reasons.

For more options see man fstab and man mount.




Uempty

Figure 8-15. Unmounting Filesystems LX032.0

Notes:

Unmounting a filesystem is done with the umount command (note: not unmount). You either have to supply the device name or the mount point, and umount will figure out the rest.

If filesystems are defined in /etc/fstab, you can unmount them all with one command:

umount -a

Or unmount all filesystems of a given type:

umount -t msdos -a

' �� %��

�� ,P��%��

?� �� 4��#��

2�� #�� ?��

A�)� �#��3#��)

A�)� �#) #��)



Student Notebook

Figure 8-16. Checking a Filesystem LX032.0

Notes:

It is of the utmost importance that the internal structure of a filesystem is at a consistent state at all times. The Linux kernel works really hard at trying to achieve this. On the other hand, for performance reasons the filesystem is not updated synchronously with all user program writes. This is called "write caching" and means that a write action by a user is not necessarily automatically done on disk. In fact, it may take up to 30 seconds for this to be done.

When in the meantime the system crashes, for instance because of a power failure, the filesystem is left in an unstable state and needs to be repaired before it can be used. This is done by running the fsck program, usually from rc.sysinit. fsck detects the type of filesystem and runs the specific check program accordingly.

�� %��

!��%� ��

"�� %�� /� ��/�M�� E��%��

��3��.��.��=

!� ��%�� ? �� ,� ��




Uempty
Although the implementation details may change, the general behavior of all these fsck programs is always the same:
• When the fsck program detects that the filesystem was unmounted cleanly, then no further checks are performed.2

• If the filesystem was not clean, the consistency will be checked. On a non-journaled filesystem this basically means that the whole filesystem needs to be scanned, while a journaled filesystem only needs to scan the filesystem areas which are listed as possibly dirty here.

• If minor errors are detected, then these are usually corrected automatically.

• If major errors are detected, then the system drops you into a shell and you need to fix these errors manually. This is typically done with the fsck -y command.

Filesystem checks can also be started by hand. This can only be done on filesystems that are not mounted at all, or are mounted read-only.

2 Cleanly unmounted means that the filesystem was properly unmounted. This allows the kernel first to bring the filesystem in aconsistent state, where all cached write actions are actually written out. As the last action, the kernel writes the "clean" bit to thesuperblock.



Student Notebook

Figure 8-17. ext2/ext3 Specific Information LX032.0

Notes:

The ext3 filesystem standard adds journaling capability to the ext2 filesystem standard. This is implemented using a special, hidden ".journal" file. The file size of this file is arbitrary, but 10 MB is recommended.

Because of this implementation method, the filesystem is fully compatible with ext2. It is therefore really easy to upgrade to ext3.

When creating an ext3 filesystem, use mke2fs -j. When upgrading an existing ext2 filesystem, run the tune2fs -j command.

Downgrading ext3 to ext2 is easy too, since any (cleanly unmounted) ext3 filesystem can be mounted as ext2.

Some tools that may be useful on an ext2/ext3 filesystem are:

• tune2fs: Tune an ext2 filesystem. This allows you to alter the number of inodes on your filesystem, for instance.

• debugfs: This allows you to debug an ext2 filesystem. It allows you to retrieve all information from superblocks, directories and inodes, for instance.

�!�:.�!�B�"��

�4�<��M�� 4�7�� *>M�� *��&��'�� (8�/5+

�� 4�7�� 4�<��:��3�� #�� 4�7�,P��4�<�� :��3�

2��4�7A�4�<�� :�� 4�7�� 4�7�� 4�7��4��

�� '�� +

�:�� 4�7��4�:�� &�� 4�7��




Uempty
• chattr: Change attributes of files on an ext2 filesystem.
Files on an ext2 filesystem can have a number of additional attributes, which can be useful in some situations. Note that not all attributes are currently implemented by the Linux kernel.

• e2label: Change the filesystem label in the superblock. This label can be used in the first column of your /etc/fstab file.

• resize2fs: Resize an ext2 filesystem. The filesystem needs to be unmounted first, before it can be resized.



Student Notebook

Figure 8-18. ReiserFS Specific Information LX032.0

Notes:

ReiserFS is a filesystem that was designed specifically for Linux by Hans Reiser. Two features stand out, compared to ext2:

ReiserFS uses a 32 MB journal as part of the filesystem. This allows journaling of all filesystem transactions. The fixed size of 32 MB however makes ReiserFS less suitable for small filesystems.

ReiserFS uses balanced trees instead of linear lists for indexing directories. This makes it useful for filesystems that hold a large number (1000+) files in one single directory.

Some useful commands for ReiserFS are:

• debugreiserfs: Debug a ReiserFS filesystem.

• resize_reiserfs: Resize a ReiserFS filesystem.

Extending a ReiserFS filesystem can be done without unmounting it, but if you want to reduce it in size, you need to unmount it first.

��%"�"��

�� 4�� $��

$�� <7�/5�M�� $��

$��

34�� (888S��

2�� $�� 4�O��&��$��

34�� $��




Uempty

Figure 8-19. JFS Specific Information LX032.0

Notes:

JFS is the Journaling Filesystem from IBM's AIX and OS/2, which was ported to Linux and made available under the GPL. Like ReiserFS, it decided not to use linear lists for directories, but uses B+trees. It also supports "sparse" files, which are files which are mostly empty. The empty parts of that file will not occupy a disk block until actual data is written to them.

JFS will also support ACLs in the near future.

Some useful JFS commands are:

• extendfs: Extend a JFS. For this, the filesystem does not need to be unmounted. Reducing a JFS is not possible.

• xpeek: This allows you to debug a JFS.

N%"�"��

T�� "5/��"F�A�? A7

2��5S�� 4� �

��*��*�� #�� ,��

��!��

2�� !�� 4�� T� ��

!� �� T� ��

!��T� ��



Student Notebook

Figure 8-20. Quota Concepts LX032.0

Notes:

Quota are used to limit the amount of data a user can store on a specific filesystem. A user can have different quota on different filesystems. Quota are usually based on the amount of disk blocks a user has in use, although you can also put limits on the number of inodes. In addition to that, you can also create group quota, which limit the number of blocks/inodes a group can use.

A user quota is usually made up of two numbers: the so-called "Soft limit" and the "Hard limit". When a user (or group) exceeds the soft limit, he will receive warnings that he has exceeded the quota limit, but the operation will succeed. When a user tries to exceed the hard limit, the operation will fail.

As soon as the user exceeds the soft limit, the grace period will start. When that period is over, the user will get errors instead of warnings when he tries to write files. So, by setting the soft limit and the grace limit to a reasonable value, users are able to exceed their soft limit for a short period of time, usually just enough to request a quota upgrade...

<��

N�� A��

�� ,��

5�� %�� A��

��.�� 2��4��,P�� 2��4��,P��

D�� 4��

��




Uempty

Figure 8-21. Quota Implementation on Linux LX032.0

Notes:

Quota support in Linux is compiled into the kernel, so you don't need to run extra daemons. What you do need to do is indicate that a certain filesystem uses quota when that filesystem mounts. This is done with two mount options: usrquota and grpquota. After mounting, you need to turn quota on with the quotaon command. In addition to that, you also need to specify the quota themselves. This is done in the files aquota.users and aquota.groups3 in the root of the filesystem.

3 Earlier implementations used the quota.user and quota.groups file. To convert the old format in the new format, use convertquota.

<�� !

N�� %�� -��

"�� ,�� #�� .�� I�� I��

N��%� ��

/�� I��I��!� �� A��A��

N��%� �� I��

��4��A��A��>�A��>�� 3�



Student Notebook

Figure 8-22. Enabling Quota LX032.0

Notes:

So how do we go about enabling quota? The first step is to change the /etc/fstab file to indicate that a certain filesystem uses quota. Obviously we will want to enable quota every time the system boots, that's why we specify it here.

The next step is remounting the partitions. This ensures that all options are re-read from the /etc/fstab file.

Now that quota are enabled on this filesystem, we need to calculate the actual usage, and store this in the aquota.users and aquota.groups file. This is done with the quotacheck command.

Finally, we have to turn the quota on with the quotaon command. Quota checking is now fully functional.

- �� <��

/��A��A��

$�� >��

!�� >�C��

�� .��>�C��

#��3#"�!1�#�� 1��!� ��%�%

��;��"��.��C��.��C��#��3#"�'��#) #��)��&&/��! ��/�/

#��3#"�!<��!��!��!� ��/�/

#��3#��/��#) #��)��! ��/�/

��#��!� ��/�/

��#��3#� ��3� ��(��B��)��B&1/��/�/




Uempty

Figure 8-23. Configuring Quota LX032.0

Notes:

After quota checking is turned on, we can specify the quota per user or group. This is done with the edquota command.

edquota is a somewhat strange command. It reads the quota.users and quota.groups file (which are binary files), extracts the relevant information and writes it to a temporary file. It then starts your favorite editor (identified with the $EDITOR shell variable) and lets you edit this temporary file. After you finished, it will read the contents of the temporary file and merge it back into the quota.users and quota.groups file. For this reason, you should be careful editing the temporary file. If you change the wrong fields, edquota will get confused and will not do what you expected it to do.

The syntax of edquota is really straightforward. Use the -u option to edit user quota, use the -g option to edit group quota, and use the -t option to edit the grace period (which is the same for everyone on the system).

A very useful feature of edquota is the copying of quota information. If you want tux2, tux3 and tux4 all to have the same quota limits as tux1, just run the command edquota -p tux1 -u tux2 tux3 tux4 and you're done.

�� <��

�� I�� U3�"�?$��

2��.��I��3��6�� 7

D��.��I��3��6�� 7

D��I��3�

!��.��I��3��!=�3��!:��!B��!C

C� !�� %�

#��3#"�!8��'��0��%/*//��)� ��;�� B�1////��"!��B�1�///>

��8/*��)� ��;�� B�/��"!��B�/>



Student Notebook

Figure 8-24. Quota Information LX032.0

Notes:

If you need to know how you are doing with the quota, there's two commands available:

The quota command shows the quota of one individual user. It can be executed by anyone on the system, but a regular user can only see his own quota.

The repquota command shows all quota information of all users and groups. It can only be executed by root.

<��

I�� $�� .�� !� ��4�� #�� .��

��I�� $�� .�� !� �� 4��

�%D�E� !

2��0�E� !�� %�;��/%>�

�� )��'��0��E� !��)� ��(�!��E� !��)� ��(�!��

#��3#"�!8��%/*//��1////��1�///��8/*��/��/

�� A��E� !�#��3#"�!8

��0��)� ��)� �

F�� "!��(�!�� "!��(�!��

�� 55��7877/8��/��/��&7�1��/��/��

=��

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

�1��55��%*&��%///��%�//��88��/��/��




Uempty


Notes:


1.

2.

3.

��

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 mounted) MS_DOS floppy?

______________________________________________

What files are important with respect to quotas?

______________________________________________

1)

2)

3)



Student Notebook


Notes:

"��

��C

��C

��

" ��

!�� A�� A� ��

��

N��




Uempty
Unit 9. Kernel Compilation and Configuration

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



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


Accountability:



© Copyright IBM Corp. 2001, 2002 Unit 9. Kernel Compilation and Configuration 9-1

Student Notebook


Notes:

��

��

��%��

" ��%�� !�,$?/��" ��

!��%��

" ��%��

!� ��%�� %��




Uempty

Figure 9-2. Why Kernel Compilation LX032.0

Notes:

After installation of a Linux system the kernel from the distribution is installed, so kernel compilation is usually not necessary. There is actually only one situation in which you will be forced to recompile your kernel: if you have hardware which is not supported in the standard distribution kernel.

However, most people choose to recompile the kernel even when support for all their hardware is already available. The reason for this is that support for devices not present in your computer wastes valuable kernel memory, and increases boot time. People usually prefer a "lean and mean" kernel.

Of course, there may be other compelling reasons for a kernel compilation, such as upgrade to a newer kernel version or when using experimental or development kernels. But for most people, the main reason for compiling a new kernel is fun!

�� %�� .��

!� �� %��

2�� #��

34�� A��#�� %��

�� G

;��+�� M



Student Notebook

Figure 9-3. Compilation Steps LX032.0

Notes:

There are several steps in kernel compilation. First, you have to install the kernel source, usually in /usr/src/linux-version. These sources can be installed from the distribution disks, which contain the source to the kernel supplied by the distribution, or from the Internet (for instance at www.linux.org or www.kernel.org).

The next step is configuring the kernel by answering a lot of questions about whether support for a certain adapter or device should be compiled in or not.

After this, you need to clean the kernel source tree of any old temporary files, and need to recreate dependency information.

Then the kernel compilation process can begin. This involves compiling a new kernel image and compiling and installing the kernel modules.

After compilation, lilo will have to be configured so that it will boot this kernel instead of the standard /vmlinux kernel. After that, reboot your system and it will boot the new kernel.

�� "��

(> " ��%�� !�,$?/��" ��

7> !�� >��

<> $��#��

:> ��#��

J> !��%��

;> !��

@> !� ��5��

=> $��




Uempty

Figure 9-4. Installing Kernel Source LX032.0

Notes:

Kernel sources can be obtained from a variety of sources. They are available on the distribution CD-ROM as kernel-source-version.i386.rpm and can be installed using the Red Hat Package Manager (rpm): rpm -i kernel-source-version-i386.rpm. Installation will automatically happen in /usr/src/linux-version.

You can also download the kernel from the Internet, for instance, at www.linux.org or www.kernel.org. These kernel sources are usually gzipped tarfiles (.tar.gz), and should initially be placed in /usr/src. Then uncompress and untar them using tar -xzvf linux-src.version.tar.gz.

In order to be absolutely sure that no configuration options were preserved from the person who created the rpm or .tar.gz file, run the make mrproper command in the kernel directory (/usr/src/ linux-version). This will ensure that all configuration information is deleted.

�� +�� "��

�� %�� %��

��3�� 3��3��

��" �� 4,��>��>�&��A��A��34!�� !3��4

�� #��

��



Student Notebook

Figure 9-5. Configuring the Kernel LX032.0

Notes:

Before you start the compilation process you will have to determine what support should be compiled in. For this, you will need to know your hardware, and you will need to know what function your system will fulfill. For instance, your system can only act as a firewall if firewall support is compiled into the kernel.

To configure your kernel, run the make config command in the /usr/src/linux-version-directory. You will be presented a lot of questions1. For most of the questions, help is available by entering the question mark. If you are unsure, accept the default.

Recently, two more ways of configuring the kernel configuration parameters were added: make menuconfig and make xconfig. Both will offer you a menu-based structure to set the parameters, instead of having to answer all questions sequentially. That is especially convenient if you made errors while answering.

All configuration options are stored in a single flat file called .config in the directory /usr/src/linux-version. 1 Kernel version 2.4.18 asks about 1200 questions!

�� +��

!� ��%��

��

��#��

"��

�� !��

!� ��

"��#�� #��%�� #��

? ��%�� .��




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


Student Notebook

Figure 9-6. Kernel Modules LX032.0

Notes:

Certain kernel parts may be configured and compiled as modules. This means that they are not part of the kernel image, bzImage, but are available on disk as a separate file.

There are several advantages to this scheme:

• The modules do not consume memory until they are needed

• System boot is faster, because there is less loading to do

However, there is also a disadvantage: the loading of a module costs some time. This may be a burden for often-used hardware.

Modules can only be loaded after the system is fully booted up. Therefore, if you have any hardware which is already needed in the boot process, compile it into the kernel, and not as separate modules.

You can also create an "initial root disk", which is a special file (actually, a filesystem in a file) which contains the necessary modules, typically your SCSI and/or RAID modules. This file is loaded into memory by Lilo. The kernel then loads the modules off this initial root

+��

!�� %��

�� A��A��A�� %�� 1�� A��A��A�� 4A/�%��!�� 3F�$�13$ "?-�� %��

/��#� ��

/��#� ��

2��

?�� " ��$��%�'� ��+��




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



Student Notebook

Figure 9-7. Compiling the Kernel LX032.0

Notes:

After configuration you will want to clean up the installation tree. This means removing all the old temporary files (*.o, *.a) and kernel images.

After that, re-create the dependency files. This will take a few minutes.

Then it is time to compile the kernel itself. Do this with the make bzImage command.2 The compilation process will take somewhere between 5 and 60 minutes, depending on the speed of your processor and the amount of code to compile. It creates the compressed kernel image (called bzImage) in /usr/src/linux-version/arch/i386/boot.

2 Technically, there are three ways of compiling the kernel image, which differ in the amount of compression applied, and where thekernel will be loaded: • make Image does not apply any compression to the kernel image. This means that with the current kernels, the kernel image

becomes far too big to handle. It is not used anymore. • make zImage applies compression to the kernel image and prepends a decompress program to it. When the kernel is loaded in

memory and executed, the decompress program first decompresses the kernel and loads it below the 1 MB memory limit. It then starts the kernel proper. This scheme can be used when only a few hardware drivers are compiled into the kernel.

• make bzImage compresses the kernel in nearly the same way as make zImage does. Only the decompress program loads parts of the kernel above the 1 MB memory limit. This allows for more hardware drivers in the kernel image itself, instead of in modules.

Configuring the kernel so that a zImage can be produced is rather demanding. Most people therefore build a bzImage.

�� +��

�� !�� >��>��

��!��%��

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

��!��/��%��7,;8��




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

Figure 9-8. Installing the Kernel LX032.0

Notes:

To install the kernel, it needs to be copied to /boot. For convenience, rename the kernel image so that it includes the full version number (including the EXTRAVERSION). This will save a lot of trouble later, if you compile more kernels.

It is a good idea also to copy and rename the System.map and .config files. These files are not strictly needed for the correct operation of the kernel, but are useful as a reference later in case of problems.

To install the modules, run the make modules_install command. This will automatically install all modules in /lib/modules/version.

If you need to load modules to access your root filesystem, for instance because your root filesystem is on a RAID, LVM or SCSI volume, or if your root filesystem is formatted as ext3, ReiserFS or JFS, then you need an initial root disk. This initrd is created with the mkinitrd command, and should also be stored in /boot.

�� +��

!��%�� A��.�BGE.��.�4��.��.�4��3��

!�� >�� >�� A�� "��.��."��3�� .��.�� 3��

" ��O� ��

!��" ��$��%�� 3��.��.� ��3��




Uempty

Figure 9-9. Configuring Lilo LX032.0

Notes:

After the kernel compilation has finished, you will need to reconfigure the /etc/lilo.conf file so that it will boot the new kernel. If you are unsure of the quality of the new kernel (for instance, because it is a development kernel), it is possible to make the choice at boot time.

You can leave the kernel image in /usr/src/linux-version/arch/i386/boot, but most people choose to copy the kernel image to /boot. We will assume that you copied it there too, and called it /boot/bzImage. We also assume that you added "-WL" to your EXTRAVERSION in /usr/src/linux-version/Makefile

Your lilo.conf file will look as follows then:

boot=/dev/hda map=/boot/map install=/boot/boot.b prompt timeout=50 image=/boot/vmlinuz label=linux

��

3��.��.�� %��

$� ��

>��"

$�%��

��%�$��

��%�$��$��$

��

��%&'

��%�$��(

��$��%��

��%��

��,

��%�$��$(9��7�&�'�6:

��$��%��

��%��

��,

>��



Student Notebook

root=/dev/hda1 read-only image=/boot/bzImage-2.2.14-5.0-WL label=develop root=/dev/hda1 read-only

This will allow you to boot your original kernel by typing linux at the boot:-prompt, and your development kernel by typing develop.

Now reinstall LILO by issuing the lilo command.




Uempty

Figure 9-10. Configuring GRUB LX032.0

Notes:

Because GRUB is able to read its configuration file at boot time, you only need to alter it now. You don’t need to reinstall GRUB after changing the file.

�� 2�'

3��.��.��.�� %��

>��$��$��$��"

>$�%��

��"��%'

��%�'

��%-��'.'/��$��(

�� :��-��;��*�?/

��-��'.'/

��(��;��*�?��%��?

��;��*�?��

�� :��-��;��*�6:��/

��-��'.'/

��$(9��;��*�6:��%��?

��;��*�6:��



Student Notebook

Figure 9-11. Reboot System LX032.0

Notes:

After the kernel is compiled and LILO is reconfigured to boot the new kernel image, you can try it out. Reboot your system and boot with the new kernel image. Watch the screen carefully for any error messages. If needed, you can scroll up with Shift-PgUp. You can also execute the dmesg command to retrieve the messages. Most messages will also be written to /var/log/messages, so you can always retrieve them later.

If no errors occur, you can log in and start working.

��"��

!��,��,��# �3�� #

�� %��

!��%�%�� ,��2��" �A#��A��A��




Uempty

Figure 9-12. Configuring Kernel at Run Time LX032.0

Notes:

Several kernel parameters can be changed at run time. An example of this is IP forwarding, which can be turned on and off while the system is running. All these changeable parameters have a virtual file representation in /proc/sys.

To list the current setting, simply list the file to the screen with the cat command. To change a setting, simply echo the new setting to the file. And if that is not yet simple enough, the command sysctl has been created which can do this for you. With this command you can also list and change the settings. But one thing is very useful: sysctl allows you to store all setting in a file, usually /etc/sysctl.conf, and to apply all these settings at once by executing sysctl -p.

�� +�� /��

!�� %�� "��

�� #�� A��A��

�� .��.�. ��.��C.��O��#��

�� =�7�.��.�. ��.��C.��O��#��

�� #�� C��O��#�� 3#� ��C��O��#��,=�� A��A��>�� 3�



Student Notebook

Figure 9-13. Loading Modules LX032.0

Notes:

When you have compiled certain parts of the kernel as modules, they will be stored in /lib/modules/kernel-version, and need to be loaded when they are needed.

Loading modules can be done manually with the insmod command. To see which modules are loaded, use the lsmod command. To unload modules, use the rmmod command. In addition to this, there are two more advanced commands available, which actually make use of these three commands. depmod goes through the available modules in /lib/modules and finds out the dependencies between the modules. These dependencies are then stored in /lib/modules/kernel-version/modules.dep, and used when modules are loaded. modprobe then uses the modules.dep file to load a module and all the modules it is dependent on. In addition to that, modprobe and depmod also read the file /etc/conf.modules (or /etc/modules.conf, depending on your distribution), which may contain module configuration options.

A fairly new command is modinfo. This command displays information about the module. What information is displayed depends on the options given:

• -a displays the author

��

/�� #��

�� A��A��A��A��>��

/�� %�� #��

0�� #�� 7>8>6��-�� 0�� #�� 7>7>6�� " �� %��

/�� A��A��A�� 4A�� A��>�4�




Uempty
• -d displays the description • -p displays all possible parameters
Unfortunately, most authors of Linux kernel modules have not yet included this information in the module itself, so don't be surprised if modinfo yields less information than you had hoped for. This is supposed to improve in the future.

Dynamic loading of modules is also possible. For the 2.0 series of kernels, this was done with kerneld, a user-space daemon which took care of it. With the 2.2 series of kernels and higher, this is completely integrated in the kernel itself.



Student Notebook

Figure 9-14. Configuring Modules at Load Time LX032.0

Notes:

When modules are checked for dependencies with depmod and when they are loaded with modprobe, the options from /etc/conf.modules or /etc/modules.conf (depending on your distribution) is being read. There are four things that can be specified here:

• The alias specifies the name of the module that is to be loaded to support a specific device. In the example above, if someone wants to use the /dev/tr0 device, the kernel automatically loads the ibmtr module, which contains the kernel code for that device.

• The options line specifies the specific options to be passed to the module when it is being loaded. This can be very useful if you have two or more identical Token Ring cards for instance, who only have different IRQ and/or I/O settings. The options line is then used to distinguish them from each other.

The Module-HOWTO in /usr/doc/HOWTO/mini gives a short summary of the various options that are available. For specific information about a module you will need to run modinfo or dig into the source. (Most modules have a list of possible options right at the start of the source code.)

�� /��

�� A��A�� >��A��A��>�� '�� +

�� #��

�� /��,�?��?��2��

��3� ��9�� 9��3� ��4��

��3��9��9��3��4��

>��"��

��'��$��

��'��C%&��%'�?''




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



Student Notebook


Notes:


1.

2.

3.

��

Why would you recompile the Kernel?______________________________________________

Where can you obtain the Kernel source?

______________________________________________

What are the steps involved in Kernel compilation?

______________________________________________

______________________________________________

______________________________________________

______________________________________________

______________________________________________

______________________________________________

______________________________________________

______________________________________________

1)

2)

3)




Uempty


Notes:

"��

��%��

" �� %��

!�� %��

" �� %��

!� �� %��



Student Notebook




Uempty
Unit 10. Memory Management

This unit will teach you how Linux manages its memory.



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


Accountability:



© Copyright IBM Corp. 2001, 2002 Unit 10. Memory Management 10-1

Student Notebook


Notes:

Objectives

After completing this unit, students should be able to:

Describe the principles of memory management in Linux

Create paging space partitions

Create paging space files




Uempty

Figure 10-2. Linux Memory Management LX032.0

Notes:

Linux memory management uses a very simple but effective scheme: About one megabyte of your memory is used for the kernel program and kernel data. This area, on Intel systems, also holds the memory area for devices (640 KB - 1 MB). That means that roughly the first megabyte of your system cannot be used for applications.

The rest of your real memory is used for processes. If all processes combined use more memory than is available, pages will be paged out to disk into paging space.

If there is memory to spare in your system, it will be used for caching data from disk.

On Intel-32 (the 386 up to and including the Pentium), Linux can use a total of 4 Gb of real memory. Starting with the Pentium Pro and later models, sometimes written down as i686, Intel added PAE, which stands for Processor Address Extension. This allows memory addresses of 36 bits to be used instead of 32 bit, and thus extends the total amount of real memory on the system to 64 GB. Individual applications however are still limited to 32 bit addresses and thus cannot allocate more than 4 GB.1

1 Technical issues under Linux currently limit this to 3 GB.

Linux Memory Management

Total memory available for processes = real memory + paging space - kernel memory (~1 MB)

First megabyte of real memory is used for kernel program and kernel data -> not for applications

A bzImage kernel might use more than 1 MB

Rest is used for processes

Pages in real memory will be paged out to disk if necessary

Unused real memory will be used for disk caching

The maximum amount of usable memory (on 32-bit architectures) is 4 Gb

Except i686 with "enterprise kernel": 64 GB

Maximum amount on 64-bit architectures is 16 EB



Student Notebook

On 64-bit architectures, the total amount of addressable real memory is 16 Exabyte. That's more than the total amount of memory that has been produced so far on this planet.




Uempty

Figure 10-3. Example: Lightly Loaded System LX032.0

Notes:

On a lightly loaded system all processes will fit in real memory. There will be real memory left, which will be used to cache data on disk so that it can be accessed very fast.

Example: Lightly Loaded System

paging space

real memory

kernel memory used by kernel

used by programs

used for caching

unused



Student Notebook

Figure 10-4. Example: Heavily Loaded System LX032.0

Notes:

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

Example: Heavily Loaded System

paging space

real memory

kernel memory used by kernel

used by programs

used for caching

unused

used by programs




Uempty

Figure 10-5. Creating Paging Space LX032.0

Notes:

There are three steps in creating and activating paging space: First, create an empty partition, LVM logical volume or RAID volume. Then, initialize a paging space in that partition with the mkswap command. Last, activate the paging space by using the swapon command. If the paging space needs to be activated at system startup, add an entry for this paging space to the /etc/fstab file.

The minimum size of the paging space is 40 KB, and the maximum size is 2 GB when using kernel version 2.2 and up. In addition to that, the maximum number of paging spaces is 8. See the manual page of mkswap for details.

It is possible to use paging files too.2 This is less efficient than paging space and therefore should be used only in an emergency. The procedure for that is nearly the same, only you have to create a large file first, instead of a partition. So, the sequence becomes (for a 50 MB swapfile):

2 In fact, any block device can be used as paging device. Even a floppy disk or RAM disk.

Creating Paging Space

We need an empty partition/LV/RAID volumePartition type 82 (Linux swap)

Create paging space in that partitionmkswap -c /dev/hda3

Activate paging spaceswapon /dev/hda3Add to /etc/fstab

Deactivating paging space is done using swapoffIn real time, no reboot necessaryOnly if enough memory is available

Paging can also be done to a file (less efficient)Create a large file and use it as if it were a partition



Student Notebook

# dd if=/dev/zero of=/tmp/pagingfile bs=1024k count=50 # mkswap /tmp/pagingfile # swapon /tmp/pagingfile

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




Uempty

Figure 10-6. Useful Commands LX032.0

Notes:

Some useful commands are:

• top, which displays useful statistics about memory usage, CPU usage and processes. It runs continuously, giving you a very clear picture about what your system is doing. Note, however, that top costs about 1 to 10% CPU time, depending on the options, refresh interval and CPU speed. Most of the statistics top will show you can also be shown individually, using the uptime, free and ps commands, respectively. Despite the CPU penalty, some system administrators choose to run top continuously throughout the day.

• sync, which flushes all cached data to disk. If you want to be absolutely sure that your data is written to disk, use the sync command.

• xosview, xload and xsysinfo display roughly the same information as top, but graphically.

Useful Commands

top displays memory, CPU and process statistics continuously

uptime displays system uptime + load

free displays memory statistics

ps displays processes

sync flushes the cache to disk

xosview graphically displays a system overview

xload graphically displays system load

xsysinfo graphically displays system information



Student Notebook


Notes:


1.

2.

3.

4.

Checkpoint

How much memory is available for applications in general?

______________________________________________

What happens with the first megabyte of memory?

______________________________________________

What is the difference between a paging partition and a paging file? Which is more efficient?

______________________________________________

What does top do?

______________________________________________

1)

2)

3)

4)




Uempty


Notes:

Summary

Memory management

Paging space partitions

Paging space files

Useful commands



Student Notebook




Uempty
Unit 11. Scheduling

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



• Use crontab files to schedule jobs on a periodic basis • Use the at command to schedule jobs or series of jobs at some time

in the future. • Use the batch command to schedule jobs in a queue, to alleviate

immediate system demand.


Accountability:



© Copyright IBM Corp. 2001, 2002 Unit 11. Scheduling 11-1

Student Notebook


Notes:

Objectives


Use crontab files to schedule jobs on a periodic basis

Use anacron to schedule jobs on a workstation

Use the at command to schedule a job or series of jobs at some time in the future

Use the batch command to schedule jobs in a queue, to alleviate immediate system demand




Uempty

Figure 11-2. Scheduling LX032.0

Notes:

Scheduling is basically about submitting jobs for future execution, once or periodically. A number of programs and daemons work together to give the user maximum flexibility in this regard.

Scheduling

Automate routine tasks

Run commands at a specific moment in the future

The crond daemon performs the scheduling for the crontab files

The anacron command performs the execution of anacron jobs

The atd daemon is responsible for execution of jobs submitted by the at and batch command



Student Notebook

Figure 11-3. Vixie Cron LX032.0

Notes:

Cron was originally invented by Paul Vixie. That's why it is usually called Vixie Cron. It is used for repeating tasks, for instance tasks that need to be run every day, week, month or year.

To configure these tasks, or jobs as they are commonly called, you need to add them to a crontab file, using the syntax described above. When the crond daemon is started or restarted, it reads all crontab files and stores them in memory. crond then wakes up every minute and searches through the list of crontab entries for all entries that are to be executed, and executes them. It then goes to sleep for another minute.

There are a number of places where crontab files are stored:

• User crontab files are stored in /var/spool/cron/username.

• The system crontab file is /etc/crontab.

• All files in /etc/cron.d are also considered crontab files and are read by crond.

Vixie Cron

Invented by Paul Vixie

For repeating tasks

Jobs are configured by adding them to a crontab file

Syntax:[minute] [hour] [day-of-month] [month] [day-of-week] [job]

crond wakes up every minute and goes through all files

If a match is found, job is executed

The crontabs of users are stored in /var/spool/cron/username

The system-wide crontab file is /etc/crontab

The system-wide crontab directory is /etc/cron.d




Uempty

Figure 11-4. User Crontab Example LX032.0

Notes:

The visual above shows an example of a user crontab file. You can see that it has six columns.

Columns 1 through 5 denote the time that the job is going to be executed. In order, the columns denote the minute, hour, day of the month, month and day of the week that the job is to be executed. An asterisk works like a wildcard, meaning that every time matches.

The last column is the command that is to be executed at that specific time.

Take a look at the first entry:

0 8 * * * Once_a_day

This means that the entry matches precisely when the minute is zero and the hour is eight. The other time entries don't matter. This means that the command Once_a_day will be executed at precisely 8 am, every day.

All other entries work exactly the same, except for the last example. On a first glance the last example would only be executed on January 1st, if January 1st is a Monday. So, on average, it would be executed only once in seven years. Obviously, this would be ridiculous

User Crontab Example

0 8 * * * Once_a_day

0,30 9 * * * Twice_a_day

0,30 8-18 * * * Twenty_Two_times_a_day

*/5 * * * * Every_five_minutes

12 13 1 * * Once_a_month

49 23 16 9 * Once_a_year

0 15 * * 1 Every_monday

32 14 1 1 1 ???



Student Notebook

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




Uempty

Figure 11-5. crontab Command LX032.0

Notes:

The crond daemon is responsible for the execution of the jobs stated in the crontab files. For this to work, it needs to run as root in order to be able to switch to the correct userid.

This leads to a problem however: If a user updates his or her personal crontab file, it needs to signal the crond daemon that the file has changed. But since the crond daemon is running as root, a regular user can't signal it.

To solve this problem, the crontab command is added to the system. This command runs SUID root, so it is able to signal the crond daemon that a file was changed.

There are three ways of invoking the crontab command:

• crontab -l lists your current crontab file.

• crontab -r removes your crontab file and then signals crond that a change has occurred.

• crontab -e edits your current crontab file using your favorite editor (as specified by the $EDITOR variable). After the editor finishes, the crond daemon is signaled that a change has occurred.

crontab Command

A regular user can edit his crontab file, but cannot signal crond to re-read that file afterwards

crontab command runs SUID root, so can signal crond

Three usage methods:crontab -l List your crontab filecrontab -r Remove your crontab filecrontab -e Edit your crontab file using $EDITOR

To regulate the use of crond, list the users involved in one of the following files:/etc/cron.allow (strongest)/etc/cron.deny



Student Notebook

Not every user needs to be able to use cron. That's why you are able to regulate its use through two files: /etc/cron.allow and /etc/cron.deny.

If a user wants to use the cron facility, and none of the two files exist, the usage is allowed.

If the file /etc/cron.allow exists, the username has to be in it in order to be able to use cron.

If the file /etc/cron.allow does not exist, but the file /etc/cron.deny exists, the username should not be in it in order to be able to use cron.

If both files exist, then only cron.allow is read and everybody not in it is automatically denied usage of cron. That is why cron.allow is called the strongest.




Uempty

Figure 11-6. System crontab LX032.0

Notes:

The crontab files in /var/spool/cron are used to run tasks on behalf of users. But there will also be a number of tasks that need to be run on behalf of the system administrator. For a variety of reasons which we will not discuss here it is not desirable to put these commands in /var/spool/cron/root1. That's why an additional crontab file and a cron directory were created.

The syntax of the /etc/crontab file and of the files in the /etc/cron.d directory is the same as that of a user crontab file, with only two exceptions:

• The sixth column specifies the user the command has to run as, and the command itself starts in the seventh column.

• The first few lines of the file specify the environment variables that need to be set before the command runs.2

1 Actually, quite a few Unix systems still do this.2 With a user crontab, the environment variables are set using the .bash_profile and .bashrc scripts in the users home directory.

System Crontab

The system crontab file is /etc/crontab

The system crontab directory is /etc/cron.dAll files in this directory will also be read by cron

Syntax a little different:Specifies environment variablesSpecifies userid to run command as

SHELL=/bin/bash

PATH=/sbin:/bin:/usr/sbin:/usr/bin

MAILTO=root

HOME=/

# run-parts

01 * * * * root run-parts /etc/cron.hourly

02 4 * * * root run-parts /etc/cron.daily

22 4 * * 0 root run-parts /etc/cron.weekly

42 4 1 * * root run-parts /etc/cron.monthly



Student Notebook

Figure 11-7. Anacron LX032.0

Notes:

Anacron is a recent addition to Linux. It is created after people started to use Linux as their personal workstation instead of a server.

Using Linux as a workstation, sometimes even on a laptop, means that, in general, Linux is switched off at night and thus all default cleanup jobs never run.

Anacron was created to combat this problem. It consists basically of two things:

• The anacron command. This command is called when the system starts and periodically (every day) by cron. But note: it is not a daemon in the sense that it runs continually.

• The /etc/anacrontab file. This file specifies the jobs that need to be executed periodically, and the period in which they need to be executed.

Every time anacron is started, it checks the /etc/anacrontab file to see which jobs need to be executed, and it checks the /var/spool/anacron directory to see what was the last time these jobs were executed. If a job has not been executed recently enough, it executes the job and updates the information in /var/spool/anacron.

Anacron

Most crontab jobs typically run at night, when the system is not in heavy use

But... most workstations are switched off at night!

The solution: AnacronRuns commands periodically

At night if the system is onAt startup to catch up on any missed jobs

Jobs specified in /etc/anacrontabAnacron is called

By the system startup scriptsBy cron

Job execution information stored in /var/spool/anacron




Uempty

Figure 11-8. /etc/anacrontab LX032.0

Notes:

The /etc/anacrontab file governs the workings of anacron. It specifies four things for each job:

• The period (in days) after which the job needs to be executed.

• The delay (in minutes) anacron should wait before executing a job. This feature is added to ensure that not all pending jobs are started simultaneously, immediately when the system is started.

• A unique identifier which is used in the /var/spool/anacron directory structure to identify the time a job has run.

• The job itself, usually a shell command.

Additionally, the /etc/anacrontab file also specifies a number of shell variables at the start of the file, just like the /etc/crontab file.

/etc/anacrontab

Syntax:[period] [delay] [identifier] [job]Period is number of days after which a job should runDelay is number of minutes to wait before starting a jobIdentifier is used to uniquely identify a jobJob can be any shell command

Example:

SHELL=/bin/sh

PATH=/usr/sbin:/usr/bin:/sbin:/bin

1 5 cron.daily run-parts /etc/cron.daily

7 10 cron.weekly run-parts /etc/cron.weekly

30 15 cron.monthly run-parts /etc/cron.monthly



Student Notebook

Figure 11-9. at LX032.0

Notes:

The at command can be used to run a command once in the future. The at command will make a file (Bourne shell script) in the /var/spool/var directory. This file will be read and executed by the atd daemon at the specified time.

To enter an at job you must enter the time you want the job to be executed. Some examples of the at command are:

# at 4am run the at job at the next 4am.

# at 6pm run the at job at the next 6pm.

# at 16 ditto

# at 16:00 ditto

# at 5pm + 4 days run the at job at 5am over 4 days.

# at 4 tomorrow run the at job tomorrow at 4am.

at

Run a command once in the future

# at 4am

ps aux

^d

# at -f bshfile 16:00 + 3 days




Uempty

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

# at -f commandfile 19 run the commands in commandfile at 7pm.

# at 19 < commandfile ditto



Student Notebook

Figure 11-10. batch LX032.0

Notes:

When you start a command, then this command will get executed by the system no matter what the workload on the machine is. This also happens with commands started by the crond and atd daemons. These jobs will get run no matter how busy the system is. More commands will also mean that the overall performance of the machine will degrade.

The batch command gives you a means of entering a command which will affect the performance of the system to a lesser extent. With the batch command you give the system the chance to decide when a job should be started.

batch

run a command when the system load is low enough.

Command will be run when average workload is below 0.8

$ batchecho workload is low enough<ctrl-d>




Uempty

Figure 11-11. Controlling at Jobs LX032.0

Notes:

Jobs issued by the at and batch commands can be viewed by the atq or at -l command.

To cancel a job use the at -d or atrm command followed by the job number. Controlling at batch jobs is done using /etc/at.allow and /etc/at.deny.

Controlling at jobs

List all jobs$ at -l $ atq

Cancel a job$ at -d job$ atrm job

Regulate the use of at /etc/at.allow (strongest) /etc/at.deny



Student Notebook


Notes:


1.

2.

3.

Checkpoint

What command can be used to look at your crontab jobs?

______________________________________________

What tool would you use to run a daily cleanup job on your workstation?

a. cronb. anacronc. at

How do you regulate the use of the crond and atd daemon?

______________________________________________

1)

2)

3)




Uempty


Notes:

Summary

Scheduling is used to execute tasks in the futurecron and anacron jobs are executed repetitivelyat and batch jobs are run once

cron jobs are run by the crond daemon

anacron jobs are run by the anacron program, which is called when the system starts up and, periodically, by crond

at jobs are initiated by the atd daemon

batch jobs are executed by the atd daemon



Student Notebook




Uempty
Unit 12. Backup and Restore

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



• Identify reasons for performing backups • Discuss backup implementation issues

- Backup program to be used - Media to be used - Frequency of the backup - Type of backup

• List the different backup methods supported


Accountability:



© Copyright IBM Corp. 2001, 2002 Unit 12. Backup and Restore 12-1

Student Notebook


Notes:

Objectives


Identify reasons for performing backups

Discuss backup implementation issuesBackup program to be usedMedia to be usedFrequency of the backupType of backup

List the different backup methods supported




Uempty

Figure 12-2. Why Back Up? LX032.0

Notes:

The data on a computer is usually far more important and expensive to replace than the machine itself, if it can be replaced or recreated at all. It is therefore important to ensure that this data cannot get lost.

There are a number of reasons which can cause data loss:

• Hardware failure

• Software failure

• Damage due to installation or repair

• Accidental deletion by a user or by the system administrator

• Malicious users, malicious system administrators or malicious outsiders who broke into your system.

To guard against these reasons, backups are necessary, but there may also be other reasons to perform backups.

Why Back Up?

Data is very important Expensive or impossible to recreate

Disaster recovery Hardware failureSoftware failure Damage due to installation or repairAccidental deletionMalicious users or break-ins

Long-term archive

System administrationTransfer of data between systems Reorganizing file systems Defragmentation Checkpoint before and after an upgrade



Student Notebook

Figure 12-3. Devising a Backup Strategy LX032.0

Notes:

Before inserting tapes and/or floppies in the computer, it is a good idea to sit down and think through the whole backup strategy. A good backup strategy basically has three qualities:

• The backup procedure is simple to perform, even for untrained personnel, and has minimum impact on system availability.

• The backup procedure allows for access to data, even in the worst-case scenario.

• The restore procedure can be performed by just about anyone who has knowledge about Linux in general.

In order to obtain a backup strategy which fulfills these three qualities, there is a number of decisions to be made. These decisions will be covered in the next visuals.

Devising a Backup Strategy

Devise backup schemefull, system, dataincremental

Select backup tool

Select backup media

Consider off-site storage

Document backup procedure




Uempty

Figure 12-4. Backup Scheme LX032.0

Notes:

It is not always necessary to back up everything that is stored on the hard disk of a computer. That's why there are a number of different backup types possible.

The first backup type is the full backup. As the name implies, this backup contains everything stored on disk, with the possible exception of /tmp. When this backup is restored, the system can continue working where it left of. The disadvantage is that a system backup takes a long time to perform.

A system backup only backs up the operating system itself, and any application programs that were installed. This is useful when doing system upgrades.

A data backup only backs up the user data.

An incremental backup only backs up files that have changed since the last (incremental, full or data) backup. Before restoring an incremental backup, you will always need to restore the other backup too.

Backup Schemes

Full backup Preserves the whole system

System backup Preserves system directories and filesMust include backup/restore toolsUsually on bootable media (floppy, CD-Writable)

Data backupPreserves user data

Incremental backup Only backup files that changedVery fast, but takes more time to restore Must be used carefullyNeeds more media



Student Notebook

Figure 12-5. Sample Backup Scheme LX032.0

Notes:

This visual shows a sample backup scheme. A number of different backups are made:

• Every month, a full backup of the whole system is made on a fresh tape. This tape is then stored, for instance in a tape vault, and will remain there forever. Duplicates of this tape might be stored off-site. The reason for storing tapes forever is twofold:

- All countries have laws that specify that certain data should be kept available for a number of years (up to 50 years). By keeping the tapes available, you are fulfilling this legal obligation.

- Certain events or activities only occur once a year or less. It is very likely that people will delete files as part of a cleanup operation and discover after a year or so that they still need that one special script/file/macro that was used last year too. If you still have it on tape, you certainly made their day.

• After system maintenance, a system backup is made. If these are kept for at least a month or so, you can always trace back which file has changed at which moment in time,

Sample Backup Scheme

Full Backup

Data Backup

Incremental Backup

Incremental Backup

Incremental Backup

Incremental Backup

Incremental Backup

System Backup

Every month on a new tape;

tape is saved forever

After system maintenance

Every weekend

Every monday evening

Every tuesday evening

Every wednesday evening

Every thursday evening

Every friday evening




Uempty
and therefore figure out why the system's behavior has changed. Plus, it allows you to do a downgrade rather easily.
• Every weekend, a data backup is made. This backs up all the user data.

• Every weekday evening, an incremental backup is made. This backs up the user files that have changed since the last data or incremental backup.

Obviously, you are free to implement your own scheme.



Student Notebook

Figure 12-6. Backup Devices LX032.0

Notes:

Various devices and media can be used to perform backups.

Tape drives are excellent devices for performing backups. They are comparatively fast, cheap and have a large capacity. There is one disadvantage though: reading from and writing to tape means that the tape itself has to glide along the read/write head at high speed. The friction caused by this movement wears the tape out pretty quickly, and it is therefore important to use new tapes regularly.

CD-Recordables and CD-ReadWrites are a fairly new way of backing up. They are cheap and have a large capacity. The disadvantage is that they are pretty slow, and that it is currently hard to predict how long the data on the CD will actually be readable. A few years is not a problem, but there have not been tests with storing data for more than a dozen years.

Hard Disks are very useful to do backups on. They are fast but relatively expensive. And unless you have a removable hard disk, they cannot be taken away from the computer, which doesn't help you if your computer burns down or is stolen.

Backup Devices

Tape driveLarge capacityUse new tapes regularly!

CD-Recordable or CD-RWCheap but relatively slow

(Removable) Hard diskFast but expensive

Diskette driveAlways available but cumbersome for large backups

Zip, Jaz driveLarge capacity but not really standard

NetworkUseful in large installations; usually requires commercial software (for instance ADSM)




Uempty
A diskette drive is also a good alternative if you don't have a lot to back up. It is slow and you might need a lot of media, but a diskette can be read just about anywhere, since it is the only removable media which is available by default in any computer.
A Zip drive or Jaz drive may also be a good alternative to floppy disks. They are relatively fast and have a large capacity. The biggest disadvantage is that these are not standard media types. If your computer burns down, or your Zip drive breaks down, you will have a hard time reading your precious backups.

Backing up over the network is a good idea in large installations. In such environments however, the backup strategy usually becomes complex enough to warrant the usage of commercial backup solutions such as ADSM.



Student Notebook

Figure 12-7. Default Backup Tools LX032.0

Notes:

Linux by default only has three backup commands available, although various distributions sometimes do offer additional commands.

tar and cpio roughly do the same thing: they back up individual files into a tar or cpio file which can for instance be written to a block device such as a tape. The choice between tar and cpio is a matter of preference.

dump is a tool which can back up complete filesystems. It can handle special files (such as in /dev) and symbolic links, and it can make incremental backups up to 9 levels.

Default Backup Tools

tar Backs up individual filesWidely available Excellent for transferring data between platforms

cpio Backs up individual filesWidely available Difficulties with many symbolic links

dumpBacks up whole filesystemsCan handle incremental backups (9 levels)




Uempty

Figure 12-8. tar Command LX032.0

Notes:

The tar (tape archiver) utility has been used with UNIX systems for many years. You could say that it is an old command. Unfortunately, it is not user friendly and can be quite difficult at times, especially when you are unfamiliar with the syntax to make tar do useful things. With tar you can combine many files into one large file, which makes it easier to move the collection to another disk or make a backup to tape. The general syntax is:

tar <options> [files]

The available options can be lengthy. Files can be specified with or without wildcards. An example to create a tar archive is:

tar cvf archive11.tar /home/johan

Which combines all the files in /home/johan into a tar archive named archive11.tar.

tar Command

Traditional UNIX tape archive command

Backup with tar:tar cvf home.tar /home

Restore with tar:tar xvf home.tar

List contents of a tar backup:tar tvf home.tar

To add compression: use z optiontar zcvf home.tar.gz /home

To include leading "/": use P optiontar cPvf etc.tar /etc

To make a multivolume backup: use M optiontar cvfM /dev/fd0 1440 /home



Student Notebook

Options:

c create an archive file

v verbose it, displays messages

f use the filename archive11.tar as the output file

z compress the tar image

P don't strip the leading "/" from the filename. Note: You need to supply this option both when creating and reading from the tar file.

M make a multivolume archive. The number specifies the amount of 1k blocks that fit on each archive.




Uempty

Figure 12-9. cpio Command LX032.0

Notes:

cpio stands for CoPy Input Output

This command is similar to tar. However it can use archive files in a number of different formats, including the tar format. Normally cpio reads the names of the files to copy into the archive from standard input (stdin) and produces the archive as standard output (stdout). When extracting files from an archive, cpio reads the archive as standard input.

As with tar, some options can be given in both a short, single-letter form or a more descriptive word form. On the other hand, the syntax of the two forms differs when the option must be followed by additional information.

In the short form, you must use a space between the option and the additional information. With the word form you must separate the two options with an equal sign and NO space. It should be used with care, as it will not preserve, unless instructed to do so, the ownership and permissions of files.

cpio Command

Common UNIX backup command

Backup with cpio:cpio -ov <files> > <device> find /home cpio -ov > /dev/fd0

Restore with cpio:cpio -iv[-dum] [files] < <device> cpio -ivdum "/home/j*" < /dev/fd0

List contents of a cpio backup:cpio -itv < <device> cpio -itv < /dev/fd0



Student Notebook

In fact, cpio can even lose the directory structure on the restore side. When using cpio to copy files into a directory, you must give the name of the target directory as an argument to cpio.

cpio is a raw I/O copier. It is very useful for moving information between systems.




Uempty

Figure 12-10. dump Command LX032.0

Notes:

dump is a backup tool which can backup whole filesystems. It correctly handles symbolic links and special device files, and it can handle incremental backups up to 9 levels. Information about these incremental backups is stored in the file /etc/dumpdates.

Restoring a backup made by dump is done with the restore command.

dump Command

To backup a complete filesystem

Can handle symbolic links and special device files

Can handle incremental backups up to 9 levelsInformation is stored in /etc/dumpdates

To make a full backup of the /home filesystemdump -0 -a -u -f /dev/fd0 /home

To make an incremental backup of the /home filesystem:dump -5 -a -u -f /dev/fd0 /home

To restore a dumped filesystem:cd /homerestore -r -f /dev/fd0



Student Notebook

Figure 12-11. Other Backup Commands LX032.0

Notes:

There are a number of other programs available for Linux that can help you to back up and restore files. Some of these are open source projects or are otherwise free to use, and others are commercial products. Their features range from a simple menu-interface to tar and cpio to advanced, network based backup solutions which can support major enterprises in their data storage needs.

Other Backup Tools

taper: menu driven tool for backing up to tape

BRU2000: http://www.bru.com

Lone-Tar: http://www.cactus.com

PerfectBACKUP+: http://www.merlinsoftech.com

Backup/9000: http://www.facer.com.au

AMANDA: http://sourceforge.net/projects/amanda/

IBM/Tivoli Storage Manager (TSM): http://www.tivoli.com/products/linux




Uempty

Figure 12-12. Document Backup Procedure LX032.0

Notes:

Why would you document your backup procedure? Well, for one simple reason: you will probably not be there when the need for a restore arises. According to Murphy, you will probably be on a well-deserved vacation in some far corner of the earth when disaster strikes. That's why you've got documentation. So others can perform your job, if necessary.

When writing the documentation, always allow for the worst-case scenario. Even allow for the loss of documentation itself - so make hardcopy backup copies of the backup documentation and store them with the backups themselves. Keep hardcopy lists of files that are on the backup media, and keep hardcopy printouts of the scripts and commands that were used to create the backups. Remember: if your computer burns down, you've got no means to read softcopy materials on how to restore data until you actually restored it...

Furthermore, keep the installation images, boot media and everything you need to install a pristine system with the restore tools on it. Store these next to your backups. It is a great idea to use dump to back up your system, but if you don't have the means of installing a system with the restore command on it, your backups are of no use.

Document Backup Procedure

Ensure anyone (not just you) can perform a restoreYou may be far away when disaster strikes

Always allow for the worst-case scenario

Useful to have a hardcopy list of all files on media held along with the media

Keep hardcopies of all scripts that were used

Keep install images and boot media of operating system along with backups

Label media with the command used to create it, also the blocksize



Student Notebook

And last, it is always a good idea to write the commands which were used to create the backup on the backup media itself. Even if the documentation is lost, a good system administrator can usually figure out how to restore a backup when he sees the command used to make it.




Uempty

Figure 12-13. Additional Backup Considerations LX032.0

Notes:

These are just some additional backup considerations which may seem obvious now, but which are forgotten a lot of time.

Do take a look at http://www.bru.com/mistakes.html. It lists the 11 most made backup mistakes, and how to avoid them.

Additional Backup Considerations

Use new media regularly

Keep monthly full backups indefinitely

Verify old backups regularly

Test recovery procedure before you have to

Consider off-site storage of backups

Check filesystems before backing up

Don't backup open files unless your backup tool can handle it (esp. databases!)

Don't throw away old backup hardware before converting your backups

11 common backup mistakes (and how to avoid them): http://www.bru.com/mistakes.html



Student Notebook


Notes:


1.

2.

3.

4.

5.

Checkpoint

What is the difference between A and B?A: find /home/francis -print cpio -ov >/dev/rmt0 B: find . -print cpio -ov >/dev/rmt0

______________________________________________

Which one of the following commands supports multilevel incremental backups?

a. tarb. dumpc. cpio

An incremental backup will always back up the operating system files.

It is not necessary to use the dash (-) with the option in the tar command.

When did you last back up your files?

______________________________________________

1)

2)

3)

4)

5)

T/F

T/F

II




Uempty


Notes:

Unit Summary

In order to perform successful backups, consider the FrequencyMedia to be usedBackup schedule Backup procedureRestore procedureType of backup

Backups can be initiated on a single file or on an entire file system

There are many backup tools which can be used



Student Notebook




Uempty
Unit 13. User Administration

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



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


Accountability:

• Checkpoint questions • Lab exercises


© Copyright IBM Corp. 2001, 2002 Unit 13. User Administration 13-1

Student Notebook


Notes:

��

" �� %��

��

��

/� ��

!��




Uempty

Figure 13-2. Security Concepts LX032.0

Notes:

The security of a Linux system is based on a user being assigned a unique name, user ID (UID) and password. When a user logs in, the UID is used to validate all requests for file access.

When a file is created, the UID associated with the process that created the file is assigned to the file. Only the owner or root can change the access permissions.

Users that require access to a set of files are placed in groups. A user can belong to multiple groups. Each group has a unique name and Group ID (GID). Every user will always be member of at least one group. This is called the primary group. In addition to that, users may also be members of other groups. These are called secondary groups.

"��

2�� D��

2 �.��

2 �.��"�

2��

2 �.��

2 �.��"�

��

�� "�



Student Notebook

Figure 13-3. User Hierarchy LX032.0

Notes:

The most important user (from a system administrative point of view) is the root user. The file permissions do not apply to root so he can read, change and delete any file he wants to. In fact, root can do just about anything, except for obvious things like writing to read-only mounted filesystems (CD-ROM), unmount busy filesystems and so on. Furthermore, most system administration tasks can only be executed by the root user.

Besides the root user, Linux has a number of other users too. These users should not be used to login but are there for the convenience of some applications and daemons. These users should not be used to carry out any administration task; use the root user for this.

The last type of user account is the normal user account. The purpose of these accounts is to give ordinary users the opportunity to login to a Linux system and carry out tasks.

'��)��

�� 2�� !� �� 4��#��

�� >>>2�� !� ��'� �� +��

?��




Uempty

Figure 13-4. Groups LX032.0

Notes:

The creation of groups to organize and differentiate the users of a system or network is part of system administration. The guidelines for forming groups should be part of the security policy. Defining groups for large systems can be quite complex and once a system is operational, it is very hard to change the group structure. Investing time and effort in devising group definitions before your system arrives is recommended.

There are two groups on the system:

User groups User groups should be made for people who need to share files on the system, such as people who work in the same department, or people who work on the same project.

System-defined groups The system-defined groups are used to control certain subsystems.

There are two different kinds of groups available to users. The first group is the primary group. The primary group is used by the system when you create a file (and directory). Every file created is assigned a group and this is the primary group of the user creating the

2��

�� #� ��

3#�� #��

��A��

D��

�� >��



Student Notebook

file. The group set is the set of groups determining the permissions you have on a given file or directory. The group set is used by the system when you want to work with a file or directory.




Uempty

Figure 13-5. Command Line User Tools LX032.0

Notes:

Linuxconf is a graphical tool to manage your users. There are also a number of command line tools to do the same.

These tools are:

adduser or useradd A tool to add users to your system. After creating the user account, linuxconf will prompt you for a password for that user. The adduser and useradd command will only create the user account. You have to set the password manually afterwards.

userdel Remove users from your system. The -r option also removes the contents of the user's home directory, and the directory itself.

usermod Change settings of a user. This command can also be used to lock and unlock a user account. This is done by putting an exclamation point in front of the password in /etc/shadow.

�� '��/��

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

�� A��!)�

A��)�5��#"�)�#��!)�

��A��5��!)�

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

��%� �� %� �� A��)��5��!)�A��)��5F��!)�



Student Notebook

Figure 13-6. /etc/skel LX032.0

Notes:

When a user logs in, the shell will try to read some configuration files from its home directory. These files can be made manually by the root user or by the user itself but they can also be copied automatically to the home directory of the user.

The /etc/skel directory is the directory that contains a number of skeleton files. These files are copied to the home directory of a user when this user account is first created.

.��.��

��%�� #��

�� A��A�%��

L�� #��#��




Uempty

Figure 13-7. Command Line Group Tools LX032.0

Notes:

You could also use the command tools to manage your groups.

�� 2��/��

��A�(��!��(��!)�

��A�(��(��!)�

!�� A�(��)��5��O!)��(��!)�



Student Notebook

Figure 13-8. Passwords LX032.0

Notes:

Users can change their passwords by using the passwd command. Root can also use this command to reset passwords of other users.

As a default passwords are stored in the /etc/passwd file. When you use shadow files, the password will be stored in the /etc/shadow file.

A useful tool is mkpasswd. This generates a random password and, optionally, assigns this password to a user.

��#��

!�� H��A��!��

!��%�� %/� ��

�� A��A��

�� A�)0�!��P��!)�Q




Uempty

Figure 13-9. /etc/passwd LX032.0

Notes:

Most user information is stored in /etc/passwd. It contains a line for each user, and values on the line are separated by colons.

From left to right, each line consists of:

• The login name of the user.

• An "x", meaning that the encrypted password is stored in /etc/shadow.

• The User ID (UID) of the user.

• The Primary Group ID (GID) of the user.

• The full name of the user. Some system administrators also choose to include location, room number, telephone numbers and so forth in this field.

• The home directory of the user.

• The preferred shell of the user.

This file is world readable, meaning that everyone can read (but not write) to this file.

.��.��#�

P�� R"�� !)��#�� QA��! �#� �#�!��

�� /�/�� #�� #'�#'!�"

'��%�%�'��#'��

�!�)��1�1��!�)��#�'��

!�)��<�8�!�)�#3!�#!�)�

��8�*��#3!�#��#��

��/��#�'��#'�#��

�" ��&�/��" ��#�'��#�'�#�" ��

"!� ��*�/�"!� �#�'��#�'�#"!�

)!��7�%1�)!��#3!�#��#)!��

��%<��#3!�#��#��

��%/�%8��#3!�#��#��

��! ��%%�/��! ��#��

(!)��%1�%//�(!)��#��#(!)��

(��"��%<�</�(��"��#��#��'#(��"��5�! !�

� ��%8��/��4 �F��#"�)�#� ��

�'��:�'��#�

��%//�1<<�$�� 3��#� �#$%%#��#'�#�!��

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

�1��/1��/1�4�� "�� (��;1>�#"�)�# �1�#'�#'!�"



Student Notebook

Figure 13-10. /etc/shadow LX032.0

Notes:

The passwords of the users are stored in /etc/shadow. This file contains, from left to right:

• The username

• The MD5 encrypted password of the user. MD5 encryption is a one-way encryption, meaning that once encrypted, a password can never be decrypted. To test whether an entered password is correct, the entered password is encrypted too and compared to the encrypted password in /etc/shadow. MD5 encryption is rather new. Older UNIXes, and other Linux distributions might still be using the old crypt algorithm. The real advantage of MD5 is that the allowed password length is increased from 8 to 256 characters.

A "*" means that this user does not have a password. That user account can therefore not be used to login.

• The day the password was last changed (number of days since Jan 1st, 1970).

• Number of days before the password may be changed again.

• Number of days after which the password has to be changed again.

.��.��#

P�� R"�� #�� QA��! �#� �#�"!��

�� D%D��&�!�D/3, �%:S��F!T��=��/�%/*7*�/��*�5%�5%�%<8�<7888

'��U�%/*7*�/��*�5%�5%�

�!�)��U�%/*7*�/��*�5%�5%�

!�)�U�%/*7*�/��*�5%�5%�

��U�%/*7*�/��*�5%�5%�

��U�%/*7*�/��*�5%�5%�

�" ��U�%/*7*�/��*�5%�5%�

"!� �U�%/*7*�/��*�5%�5%�

)!��U�%/*7*�/��*�5%�5%�

��U�%/*7*�/��*�5%�5%�

��U�%/*7*�/��*�5%�5%�

��! ��U�%/*7*�/��*�5%�5%�

(!)��U�%/*7*�/��*�5%�5%�

(��"��U�%/*7*�/��*�5%�5%�

� ��U�%/*7*�/��*�5%�5%�

�'��U�%/*7*�/��*�5%�5%�

��VV�%/*7*�/��*�5%�5%�

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

�1�D%D�(� &$��D# 2-S4)�W@E"�<*1$*F*�/�%/*�%�5%��5%�5%�5%�%<�88/7*&




Uempty
• Number of days the user will be warned of a password expiry.
• Number of days after expiry, after which the account is disabled.

• The day the account was disabled.

• A reserved field.

The /etc/shadow password file should be read/writable by root only. Other users should not be able to read this file at all.



Student Notebook

Figure 13-11. /etc/group LX032.0

Notes:

The /etc/group file contains group information. From left to right:

• The group name

• The group password. Group password are ancient UNIX concepts which are no longer being used. For backwards compatibility this field is kept alive though.

• The Group ID (GID)

• The list of users that have this group as their secondary group.

.��.��

P�� R�� )�#�� QA��! �#� �#(��

�� /��

'��%�� '��!�)�

�!�)��1�� '��!�)�

��<�� '��!�)

!�)��8�� !�)��!�)�

===

�'��

��%//�

��%��

��%/%�

)��%/1�

��1</�

��1<%�

��1<1�

��! ��1%�

��1<<�

�%��/%�

�1��/1�




Uempty

Figure 13-12. /etc/issue and /etc/issue.net LX032.0

Notes:

The /etc/issue and /etc/issue.net files contain the login message shown at login time. The /etc/issue file is shown by the mingetty process, and /etc/issue.net is shown by the telnet server when a client logs in over the network.

The /etc/issue and /etc/issue.net files may contain escape sequences: a backslash followed by a single character. These escape sequences are then replaced with dynamic information such as the date, the architecture and the kernel version when the file is displayed. For a list of these escape codes, see man mingetty

.��.�� .��.��

!� ��

P�� R"�� !)��#�� QA��! �#� �#��

��?! ��!��*=<�;9!�"!��!>

-��X��!�X)

P�� R"�� !)��#�� QA



Student Notebook

Figure 13-13. Message of the Day LX032.0

Notes:

The message of the day is stored in /etc/motd. Under normal conditions, users will see the contents of this file on their screen when they login.

Users who login graphically will not see the motd. The .hushlogin file is used to disable the motd facility. When you create this file in your home directory (it may be an empty file), you don't see the motd at login times anymore.

��&��

A��A��

�� >

"��{)��-.�� 4��.��.�� >�




Uempty


Notes:


1.

2.

��

What file does the bash shell not use?a. /etc/profileb. $HOME/.loginc. $HOME/.bash_logoutd. /etc/bashrc

Where are the passwords of users stored?______________________________________________

1)

2)



Student Notebook


Notes:

"��

2��

��

2�� A��A��

�� A��A��

D�� A��A��

��




Uempty
Unit 14. User-Level Security

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



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


Accountability:



© Copyright IBM Corp. 2001, 2002 Unit 14. User-Level Security 14-1

Student Notebook


Notes:

��

��

��

�� 2"�� D"�� %��5��

"��

�� /




Uempty

Figure 14-2. User-Level Security Overview LX032.0

Notes:

With user-level security we mean the security issues that surround the users that log in to your systems. Securing this properly requires two steps:

The first step is authentication. Authentication means: verifying that you indeed are who you say that you are. In theory, there are several methods of achieving this:

• By showing that you know something, such as a password or PIN code.

• By showing that you have something, like a smart card, ATM card, key or token.

• By showing that you are something, for instance by using biometric data such as finger prints, retina scans and so forth.

The second step is authorization. Authorization means that we have established that you are who you say that you are, but need to determine what you're allowed to do on the system. This is implemented in Linux using file permissions.

'��3��"��#

$�� ?�1��

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

$��4�� ?�� #��" �� 4��



Student Notebook

Figure 14-3. Pluggable Authentication Module (PAM) LX032.0

Notes:

The Pluggable Authentication Modules (PAM) is a set of modules that allow you to be very flexible about your authentication mechanisms.

It is implemented as a suite of shared libraries that are used by the different programs that need authentication services. It was initially developed by Sun Microsystems but later adapted for Linux.

��$�� 0�$�1

�� 4

"��

3 ��

" ��#�� /�� 4




Uempty

Figure 14-4. Authentication before PAM LX032.0

Notes:

For a system administrator, the situation before PAM was far from ideal. Every application that ran on a system required its own security and authentication mechanism. Some of them were based on /etc/passwd, /etc/group and /etc/shadow, like login and ftp (although ftp also knew the "anonymous" login possibility), and others used their own authentication mechanisms. A program which was supposed to be very secure might actually employ a layered approach, maybe incorporating biometric authentication techniques like retina scans or voice recognition.

All these different authentication mechanisms are a nightmare for system administrators, because if the administrator wants to add a user, he has to do that in multiple places. Plus, the system administrator wasn't free to choose his own method. Suppose for instance, that a university decides to supply all students with a chipcard which is used for the restaurant, the library and the computer facilities as the authentication device. With a scheme like this, it is close to impossible to implement that.

$�� $�

��

��

A��A��

��

��

��

#��

��

�� #��

��



Student Notebook

Figure 14-5. Authentication with PAM LX032.0

Notes:

With PAM, every application that needs some kind of authentication, needs to be rewritten to use the PAM authentication mechanisms. But then, the only thing that program has to do, is ask PAM: "Is this user authorized to use me?". And PAM will tell the program yes or no.

To authenticate that user, the system administrator can set up different authentication mechanisms, and specify which program should use which kind of authentication mechanism.

There is a couple of authentication mechanisms currently available:

• Userid/password checking

• Anonymous login (for example, for anonymous ftp)

• Deny, for services that may not be used

• Secure tty, meaning that logging in is only allowed from a secure terminal

$�� #��$�

��

��

2��A��

#��

��

�� ?��

��/��/��

� �A��A�>�




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

Figure 14-6. PAM configuration files example LX032.0

Notes:

The visual above shows two actual configuration files. Every file you will encounter within PAM is split up in four sections, which apply to the four phases of the login process:

1. Verify the authentication of the user, usually by checking the password.

2. Manage the account. For instance force a user to change its password if the password used is expired.

3. Change the password itself. This phase can also be called from the passwd program.

4. Manage the session where the user logged in.

The first file is the configuration file which is used for the login process. From top to bottom, the lines mean roughly:

• Require that, if root tries to authenticate itself, the tty he logs in from is listed in /etc/securetty.

• For the rest of the authentication process, go to the filesystem-auth.

�$�� !��

P�� R��%�� QA��! �#� �#�!)=�#��(�

AY .+5%=/

! "��E�� #��'#�� #�!)O�� =��

! "��E�� #��'#�� #�!)O� !�0=��3��B�� )5! "

! "��E�� #��'#�� #�!)O��(�=��

!�� E�� #��'#�� #�!)O� !�0=��3��B�� )5! "

�!��E�� #��'#�� #�!)O� !�0=��3��B�� )5! "

��E�� #��'#�� #�!)O� !�0=��3��B�� )5! "

�� !� #��'#�� #�!)O��=��

P�� R��%�� QA��! �#� �#�!)=�#�� )5! "�

AY .+5%=/

A�4"��! �5(��! ��=

A�F��"!(��'�� "�� )��! "��(��=

! "��E��#��'#�� #�!)O�3=��

! "�� #��'#�� #�!)O��=��0�! "��0

! "��E��#��'#�� #�!)O��=��

!�� E��#��'#�� #�!)O��=��

�!��E��#��'#�� #�!)O��!�0��'=�� B<� ��B

�!�� #��'#�� #�!)O��=��0��O! " �0�)��"!��

�!��E��#��'#�� #�!)O��=��

��E��#��'#�� #�!)O��)� �=��

��E��#��'#�� #�!)O��=��




Uempty
• When the filesystem-auth passes the authentication phase, also require that a user cannot log in as long as the file /etc/nologin exists. In this case, print the contents of the file to the screen.
• For the account management, go to the filesystem-auth.

• For the password management, go to the filesystem-auth.

• For the session management, go to the filesystem-auth, but also execute the pam_console module. This module makes a console user owner of certain console devices such as /dev/fd0 and /dev/cdrom.

As you can see, this file defers a lot of work to the system-auth file. A lot of services do that, and that makes system-auth the central place where you can make important changes.

Here's the breakdown of the system-auth file:

• In the authentication phase, first load a number of environment variables from the file /etc/security/pam_env.conf.

• Require that the user performs standard UNIX authentication, that is, supplies a valid password.

• If the above steps fail, deny access.

• After logging in, perform normal UNIX account checks, including for an expired password.

• If the user wants to change his password, test it before to verify that it is not easy to crack.

• If the user changes the password, store it the usual UNIX way, in the username/password database.

• If the password did not pass the steps above, deny the password change.

• When the session is started, apply various limits to the user, such as a maximum number of processes.

• Apply the usual UNIX session management to the session, such as logging things in the wtmp and utmp files.

More information on PAM can be found in /usr/share/doc/pam-version This includes a description of every function of every PAM module.



Student Notebook

Figure 14-7. Common PAM Modules LX032.0

Notes:

Various modules exist as part of the PAM library, and can be used by applications. And obviously you can write your own modules, for instance if you actually decide to use biometric authentication mechanisms.

Some PAM modules require configuration files. Typically, these files are stored in /etc/security.

�� $��

�I� �4>��$��2-"F�� '��+

�I��%��>��!��%��

�I��>��3 ��

�I �� >�� A��A �� 4��

�I��>��A��

�I��>�� A��A��

�I��>��A��

�I��%>��" �� /��

�I�� >��

�#��/��#�� A��A��




Uempty

Figure 14-8. Principles of Authorization LX032.0

Notes:

Authorization is generally based on file permissions. These permissions tell you what files to read and write, what directories to go to, and what programs to execute. File permissions apply to all users, except root.

It is impossible for users to upgrade their own security level (in other words, become root), unless the program that is being executed has a special SUID bit set. We will talk about this later. Some programs that have this bit set, and thus allow you to perform an action which would otherwise not be allowed are:

• passwd: When you change your password, the file /etc/shadow needs to be updated. For this, you need root permissions.

• mount: To be able to mount a floppy or CD requires access to the /dev/fd0 and /dev/cdrom devices. This is usually reserved for root.

• su: This stands for "switch user". It allows you to run a shell as another user. It is most often used to start a shell as root.

�� $��4��

��&�� 4�� 34�� #��

? �� 4�� 2"�� '�� +

34�� 2"��#��A��A�� !��$� �� $� ��



Student Notebook

• sudo: This was invented when people started noticing that sometimes users need to execute scripts or complicated commands as root, without allowing them to actually become root. Traditional methods would either mean giving these users the root password, or set the SUID bit on that particular command. The first is not desirable for obvious reasons, but the second can be too permissive too: The user would be able to run the command with any arguments that he would choose.

sudo only allows specific users to run specific commands with specific options as specific users, and nothing more.

Make sure that you always use absolute paths to programs when creating a sudoers file, since otherwise users might change their $PATH variable and use sudo to start arbitrary scripts in their own $HOME/bin directory.




Uempty

Figure 14-9. File Permissions LX032.0

Notes:

There are a number of permission bits associated with files and directories. These permissions are:

r (read) User can read the contents of the file or directory.

File: less file Directory: ls

w (write) User can modify the contents of a file or create and delete files in a directory.

File: vi file (and make some adjustments) Directory: rm file

x (execute) User can execute the file or enter a directory.

File: file Directory: cd directory

%��

��> ��

� 2��

2��

� 2��

2��

4 2�� 4��

2��

2"� �� #��"��

D"� �� #��"��

�� "��

��%��

? ��



Student Notebook

SUID (Switch UID) If the file gets executed, it will run with an effective UID of the owner of the file. This permission is not supported on shell scripts. This permission has no meaning on directories.

SGID (Switch GID) On an executable file it means that when the file runs, the process runs with an effective GID of the group owner of the file. On a directory it means that any file/directory made within the directory will have the same group ownership as the directory rather than the primary group of the user. SUID and SGID programs are hackers' favorites. When a hacker has entered your system he will usually leave some SUID /SUID programs ("trojan horses") around. With these programs he is then able to gain root access anytime he is logged on as a regular user, even without knowing the root password. It is therefore important that the system administrator knows which SUID and SGID programs are installed on the system. They can be listed with the following command:

find / -perm +6000 -ls

Sticky Bit On an executable file (thus, a program) this bit used to mean that the program should not be removed from memory after it was executed. The next time the program were to be executed, the program would start significantly quicker. With modern memory management this usage is no longer implemented. On a directory it means that even if the directory has global write permissions, users cannot delete a file in that directory unless they either own the file or the directory.




Uempty

Figure 14-10. Changing Permissions LX032.0

Notes:

File permissions are changed with the chmod command. There are special flags which can be used to change to the SUID, SGID and sticky bits.

chmod {[ugoa]{+-=}[rwx]|[ug]{+-=}s|[0]{+-=}t} file

The octal method can also be used:

chmod <octal> file

The owner of a file can be changed using the chown command. Only root can execute this command.

chown user[.group] file ...

The owner or root can change the group ownership of a file with the chgrp command. The owner can only change the group to another group in his group set.

chgrp group file ...

��

��

A��")��*��=� ��5��5�A��")��*��=� ��5��5�A��")��;*��=� ��5��5�

!�� A��"��Z�"��!��A��"(�� !��!��A��"��Z�"=� !��!��



Student Notebook

Figure 14-11. umask LX032.0

Notes:

The umask specifies what permission bits will be set on a new file when it is created. The umask is an octal number that specifies the which of the permission bits will not be set. On a file, the execute permissions can never be set automatically.

The root user has a different umask than normal users. For root, the default umask is 022 and for normal users this will be 002.

For example, a umask of 022 specifies that the permissions on a new file will be 644 and on a new directory will be 755. A umask of 000 would give 666 permissions on a file and 777 on a directory.

To view the current umask value, just run the umask command.

The default umask for all users is specified in the /etc/profile file. For specific users, it could be set in the $HOME/.bashrc file.

��

��

��,��%�� A��A��

" ��#��%�� U�?/3A>��I��

��#��%�� 877��887




Uempty

Figure 14-12. Example: Creating a Team Directory LX032.0

Notes:

The visual shows an example of the steps that you need to undertake to create a team directory: A directory which allows multiple people in the same group to share files.

-!��?�� /��&��

!��>��

��>��E��>��E��

!�� >��>��>��'��

/�� A�� .��



Student Notebook

Figure 14-13. Root Access LX032.0

Notes:

If the root password is known by too many people, no one can be held accountable for changes in the system. The root password should be limited to the lowest number of users possible. The fewer people who know the root password the better. However, do not make the mistake of keeping the root password as your personal secret. Should you be on vacation and the systems crash, key personnel should be able to gain root access to the systems. A good method to achieve this is to put the root password in a sealed envelope and store it in a safe somewhere.

The system administrator should ensure that distinct root passwords are assigned to different machines. You may allow normal users to have the same passwords on different machines, but never do this for root.

Attempts to become root through su can be investigated. Successful and unsuccessful attempts may be logged by the audit system.

Red Hat Linux has remote login (through telnet) for root disabled by default: root is only able to login on consoles that are listed in /etc/securetty.

��$��

&� ��

��H��

��

��

$��




Uempty

Figure 14-14. su LX032.0

Notes:

The su command runs in a subshell with the effective user ID and root privileges (if no username is specified). You will be asked for root's password before you gain root permissions. To end the session, type exit or <ctrl-d> and this will return you to the original shell session and privileges.

For example, su ferry will give you the privileges of Ferry, but you will still be in the environment of the user issuing su. su - ferry will set up the environment as if you had logged in as ferry.

�

��

D��"�!)�� D�� !��A��"�!)��

2�� 3�� #��



Student Notebook

Figure 14-15. sudo LX032.0

Notes:

The sudo command, as mentioned, allows users to execute specific commands with the authentication of another user, on specific hosts. Which combination is possible is configured in the /etc/sudoers file.

The basic syntax of this file is easy:

user host = [(newuser)] command

Which means that user is allowed to execute command as newuser on host. If no newuser is specified, it is assumed that the command is executed as root.

What makes this complicated, but also terribly flexible, is that for all four elements, macro definitions can be added. These macros are typically written in capital letters, and there is a special ALL macro defined as well. See the visual for an example of this.

The /etc/sudoers file supports a large number of options as well, which govern for instance whether a user is allowed to add any options to the command or not. For examples of this, see the sudoers manual page.

��

��4��

A��A��4��

3��

/�� 4��

� ��4��%��-��0��/ ��

34��2��#Q��BDF QOB ��%��.��.��?��#Q��6FN�F 8F ��%�000.�000��.�000��!��#Q��D 9PO!+R��%��$��.��$��C

��6FN�F 8F ��%�-��/��$��BDF QOB ��%�-��/�D 9PO!+R�




Uempty
Because of security and locking issues, only edit this file with the visudo command, not with a regular editor.


Student Notebook

Figure 14-16. Security Logs LX032.0

Notes:

/var/log/lastlog Records the last time a user logged in. This file can be examined with the lastlog command.

/var/log/messages This is the general log file. Most applications and daemons will write log information to this file. The messages file is an ASCII file which can be viewed with tail -f or more.

/var/log/secure Keeps track of the failed login attempts. Use more /var/log/secure to view the contents of this file.

/var/log/wtmp All successful logins are saved in this file. This file can also be examined with the who command. Another tool for viewing this file is the last command.

"��

A#��A��A�� ,��

A#��A��A�� ,��

A#��A��A�� ,��

A#��A��A�� ,��

A#��A�� A�� ,��




Uempty
/var/run/umtp Logs the users currently logged in the system. The default output of the who command is the contents of this file.


Student Notebook

Figure 14-17. Useful Commands LX032.0

Notes:

The graphic shows you the commands you can use to examine the contents of some of the security logs mentioned on the previous foil.

The tail -f command loops forever trying to read more characters at the end of the file, on the assumption that the file is growing.

'��

A�� C

A��"� �� 4�� A#��A��A�� A#��A��A��

A��

A��!� ��

A��!� ��( ��

A� !��5� ��(8�� 4�� >�2�� >




Uempty


Notes:


1.

2.

��

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

______________________________________________

Which of the following statements are true?a. A user belongs to only one groupb. The chmod g+s command sets the sticky bitc. The root user has UID=0 and GID=0d. The root user is responsible for the permissions on all filese. The umask for users is 002

1)

2)



Student Notebook


Notes:

"��

3#�� 4��

�� #�� >

�� 4�� %�� 2"�� D"�� %��

2�� %�� !""�� .��




Uempty
Unit 15. Logging

This unit will teach you how to use logging.



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


Accountability:



© Copyright IBM Corp. 2001, 2002 Unit 15. Logging 15-1

Student Notebook


Notes:

��

��

��

!� ��

2��

2��




Uempty

Figure 15-2. Logging Concepts LX032.0

Notes:

Various daemons generate information which might be of interest. Since these daemons don't run as foreground processes, they cannot print that information to the screen. Because of that, and because you might want to keep this information for later reference, this logging information is usually stored on disk.

In the early days of UNIX, every program wrote this information to its own logging file. This worked quite well for the programmer of the daemon, but was the system administrators nightmare:

• Every log file had its own syntax • Every daemon had its own way of selecting which items to log • It was nearly impossible to do other things with the log items, like sending it to another

host or displaying things on the console.

For this reason most daemons (but not all!) nowadays make use of a facility called the syslog daemon. The concept is very simple:

��

1��

�� 2��A"��2 �4��%��

�� A��A��>��

��

��

��

%��

��A��A��>��

��

�� %

��

��

%��



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.




Uempty

Figure 15-3. Facilities, Priorities LX032.0

Notes:

The facility defines the source of the message. The following facilities are defined:

• auth (authentication) • auth-priv (authentication - privileged; items logged here may contain sensitive

information such as unencrypted passwords) • cron (scheduling) • daemon (any daemon) • kern (kernel messages) • lpr (printing subsystem) • mail (mail subsystem) • mark (only for internal use) • news (news subsystem) • security (same as auth; should no longer be used) • syslog (the syslog daemon itself) • user (user messages) • uucp (unix to unix copy) • local0 through local7 (for custom applications)

%��9��

3��

�� %�� >>>

�� >>>

�� >��



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.




Uempty

Figure 15-4. /etc/syslog.conf LX032.0

Notes:

The file above is an example /etc/syslog.conf file. Each line of the file contains two fields: the selector and the action field.

The selector field determines for which messages this action is valid. This is indicated by specifying "<facility>.<priority>", which means that the action is valid for all log messages from <facility> with priority <priority> or higher (if you specify <facility>.=<priority>, only the specified priority matches). Multiple selectors may be specified on one line, as long as they are separated by a semicolon, and not contain any spaces. In addition to that, the wildcard '*' can be used, which will match all facilities or priorities.

The action field determines what to do with the log items that match. There are several possibilities:

• Append it to a file, in which case the action is the filename. You need to specify the full pathname of the file, starting with a '/'. It is possible to specify special files as well, like /dev/console.

.��.��

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

! "��3=U��#3!�#��(#��

)!��=U��#3!�#��(#)!��(

0��=U[U=B�� #��3#��

0��=U[U=B��

U=�)��(��U

U=�)��(��R��!�)�=!�)�=��)



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.




Uempty

Figure 15-5. logger Command LX032.0

Notes:

Logging is usually built-in into the daemon. But we may also want to do some logging ourselves, especially if we are writing complex scripts. That's what the logger command is for.

The logger command is really simple. The only thing you need to do is specify the facility, priority and the message itself, and it will be sent to the syslogd daemon. See the example above.

Note that the logger command is not a privileged command; every user can make use of this command to log any message to the syslogd daemon. It is important to be able to recognize messages coming from the logger command since users might try to fool you into panicking.

��

��

� ��4��,�O��P>O��P�O��P

A��((��5��!�)�=��4"��!� ��

A� !��5%�#3!�#��(#)��!(��

��'�%7�%&�<8�<1�� )��((��!�)�=��4"��!� ��

D��((��5��0��=�!��-��!��V� ��!��(��:��V

D

+��!(��)��(�R"�� ! ��'�%7�%&�81�<7�1///�===

"�� ((��-��!��V� ��!��(��:��V



Student Notebook

Figure 15-6. logrotate Command LX032.0

Notes:

When a log file grows, there comes a point in time where you might want to clean it out. If you don't do that, you will end up with a full /var filesystem before you know it - and you are not able to tell from the logfile what is wrong with your system...

To clean out the logfiles Linux uses the logrotate command. This command, which is normally run from cron, cleans out all the specified logfiles. Based on the information in the /etc/logrotate.conf file, it can do any of the following things with the log file:

• It can copy the contents of the log file to an archive log file. This file is usually named the same as the log file, with a number appended.

• It can compress the archive log file so that it uses less space on your filesystem.

• It can mail the logfile to someone.

• It can clean the current log.

• It can delete old archive logs, ensuring that only a limited amount of archive logs are being saved.

��

��*��*��!�� #��!� ��#��!� ��#��!�� #��

2��

!�� &�

!� ��A��A��>��




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

Figure 15-7. Sample /etc/logrotate.conf LX032.0

Notes:

The /etc/logrotate.conf file starts with a section that describes global options: options that apply to all files that need to be rotated. In the sample above, the following global options are defined:

• Rotate all files weekly. • Only keep four archive logs around. • Send all errors to root. • Create a new, empty logfile after rotation. • The compress function is commented out, so no compression is being done.

The next line, "include /etc/logrotate.d", tells the logrotate command to read all files in the /etc/logrotate.d directory and to add the contents of those files to this file. This way programs (and thus, logfiles that need to be rotated) can be added to the system without the need for the install program (rpm) to change existing files.

The next couple of lines each define a logfile that needs to be rotated. If no options are given, the default options are used. For a complete list of possible options, consult the manual page for logrotate.

"��.��.��

��0��

�� ! ��8

��

��! �

A��)��

��#� �#��(�� ! �=�

#3!�#��(#� )��\

��)� "��

��! ��/&&8�� )�

�� ! ��%

]

#3!�#��(#)��!(��\

��@��//0

�� ! �

��#��#'�#0��!��5?F ��(�

��

]

#3!�#��(#��\

��)!��!�)�R��!�)�=!�)�=��)

�� ! �

��#��#'�#0��!��5?F ��(�

��

]




Uempty

Figure 15-8. Analyzing Logfiles LX032.0

Notes:

Logfiles are not collected for fun. They contain valuable information about the overall health of your system, and things that went wrong. It is therefore a good idea to analyze your logfiles regularly.

There are several strategies for analyzing a logfile:

• You can read through the whole logfile. With short logfiles this generally is not a problem, but it quickly becomes tedious when your logfiles are longer than a few hundred lines. Nevertheless, in case of strange problems it might be necessary anyway, so that you can correlate different logfile entries.

• You can search through the logfile (using grep or vi’s search capability) for interesting items. This is typically done when you are looking for something specific, such as all the actions of a particular user in a particular timeframe. Searching for specific items like this is called a positive search.

• You can perform a negative search through the logfile. A negative search typically uses a list of non-interesting items. Using for instance the grep -v command the logfile is

$ ��4� ��

� ��&�� M��#��

��$�� '��#��+�� ' ��#��+2��

��,#��%��

�� ,�� %��,��%� ��



Student Notebook

analyzed and all non-interesting items are filtered out. This, in theory, leaves you with only the interesting items to look at.

Obviously, this doesn’t work correct immediately. The list of non-interesting items therefore changes a lot over time.

• You can use automated tools for logfile analysis. These tools analyze the logfile line by line, and are capable of doing both positive and negative searches. Some tools are even capable of correlating different log lines with each other.

Several automated tools exist for logfile analysis:

• The easiest tool for logfile analysis is grep. It can be used for on-the-fly analysis, or can be put into a logrotate postrotate script for positive and negative searches (with the -v option), of which the results are then emailed to the administrator. grep allows you to list the expression to search for on the command line, but the expression to search for can also be stored in a file, which is then referenced using the -f option.

• logcheck is a simple script which checks your logfiles from a cron job. It uses grep and grep -v extensively in a smart combination. Another advantage of logcheck over plain grep is that logcheck keeps track of what it has analyzed already, so it will not present results twice.

• swatch is a heavy-duty logfile analysis tool which is really popular in the UNIX network administrators world. It is highly configurable and is capable of performing real-time logfile analysis: you’ll hear of any problems only a few seconds after the log lines are added to the logfile, instead of having to wait for a scheduled logfile analysis.

• logwatch is a series of perl scripts that are able to check different logfiles and services. Logwatch itself knows the default behavior of just about every service that might be running on your Linux system, and filters the interesting log items automatically. Therein lies its weakness too: it is really hard to configure logwatch for a specific situation or service. The logwatch configuration directory, /etc/log.d, is a myriad of scripts, configuration files and symbolic links which make it real hard to figure out where to make a change to get a certain thing to be reported or not.

Depending on your distributions, one or more of these tools might already be installed by default, or need to be installed separately.

A last note: most automated tools submit their results by e-mail, and don’t submit a report if there’s nothing to report. That means that not receiving a report may have two causes:

• There is nothing to report

• Your e-mail subsystem is broken

Beware of this last pitfall, especially if you use these tools to monitor a large number of systems who do not all send in a report every day.




Uempty


Notes:


1.

2.

3.

��

What is the purpose of the syslogd daemon?

______________________________________________

What does the logger command do?

______________________________________________

What does logrotate do?

______________________________________________

1)

2)

3)



Student Notebook


Notes:

"��

'-��+�� 4��

��

��

��




Uempty
Unit 16. Printers

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



• Describe the purpose and benefits of a queuing system • Identify the major components that are responsible for processing a

print request • Add a print queue • Submit jobs for printing • View the status of the printer queues • Manage printer queues


Accountability:



© Copyright IBM Corp. 2001, 2002 Unit 16. Printers 16-1

Student Notebook


Notes:

��

��

�� .��

��

"�� M�� .��

�� .��

��M��

1�� .��

/� �� .��




Uempty

Figure 16-2. Users, Printer Queues, Printers LX032.0

Notes:

All printer queue mechanisms work roughly the same way: A user creates a print job, and places this print job in a print queue. The print queue is usually a directory somewhere in /var/spool. A special program called the "queue daemon" periodically checks the print queues and prints the jobs in order of arrival.

This basic queueing feature is built into every queueing mechanism available, but the mechanisms differ in the "extras":

• Whether or not multiple (identical) printers can serve one queue.

• Whether or not jobs can easily be moved from one queue to another.

• Whether or not jobs can easily be prioritized.

• To what extent user authentication and authorization is implemented.

• To what extent accounting and/or quota's are implemented.

'��9�� <��9��

N��

*��%*N��

*��*



Student Notebook

Figure 16-3. Printing Overview LX032.0

Notes:

There are several steps that a print job has to pass through before the ink actually hits the paper.

First, the user has to submit the job to the printer subsystem. There are several ways that this can be done, depending on the subsystem involved. The most common way is by using a command such as lpr to submit a file to the printer. But the user might also make a network connection to submit a job, or use a program that can make use of an API (Application Programming Interface) to submit the job.

Once the job is submitted, it reaches the printer spool daemon. This program is responsible for performing all subsequent tasks. The spool daemon checks to see if the printer is available, and if the printer is not available (yet), temporarily stores the file in a spool directory, together with accounting information such as the owner of the job and the printer requested.

When the job is ready to be processed further, it is sent through one or more print filters. These filters convert the job (which is generally in ASCII or Postscript) into a format which is suitable for the printer, if the printer does not support the print format directly. Another

�� #

�� " ��

��

!� ��

��

��

�� 5��%� �

��

2��

��

��

��

��

��

!� #�� M��

�� E

�� >

� �� #��M��

��




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

Figure 16-4. Common Printing Subsystems LX032.0

Notes:

The BSD (Berkeley Software Distribution) style printing subsystem is the traditional printing subsystem of Linux, and was common in all distributions up to about two years ago. It is very easy to configure, easy to understand but lacking a lot of features.

The AT&T style printing subsystem was not often used under Linux, but other UNIX systems (such as AIX) use it. The reason we mention it here nevertheless is that LPRng and CUPS will support the AT&T user interface commands to submit jobs.

LPRng (LPR Next Generation) was written as the successor of BSD printing. To a large extent it uses the same configuration files and commands, but has a few additional features. LPRng is used as the default printing subsystem in Red Hat.

CUPS is a completely new, modular implementation of a printing subsystem. It is one of the first printing subsystems that support the new IPP (Internet Printing Protocol) standard, which is in the process of being accepted by the IETF as a proposed standard. IPP is layered on top of HTTP and offers a far richer functionality than the older method of network printing (LPD). CUPS is currently being introduced into Linux distributions. Red

�� "��

5 �� 5 �� '��A��+$�!�((@)�� 4

��Q�� Q�� -�� 4E�� "F

�$� �� 5 �2�� 4��

!2� �'!�� 2 �4�� +!�� 5�� "��'" �� +2�� 4�� 34��




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


Student Notebook

Figure 16-5. BSD Printing Subsystem LX032.0

Notes:

The BSD printing subsystem is the oldest printer subsystem that you might find on a Linux distribution. It uses a single configuration file, called /etc/printcap, which contains all the information about all printers in your environment. This printcap configuration file needs to be repeated on every UNIX system (including workstations) in your environment, leading to a management nightmare in large installations.

A user submits a job with the lpr command. He or she is able to choose the printer with the -P option, or by setting the $PRINTER variable beforehand. The job is then send to the lpd daemon, which spools the job, runs it through a user-defined filter and then sends it to the printer itself, which may be attached to a parallel port or may be a network-attached LPD printer.

As said, the print filter is user defined: you have to configure the print filter yourself. Numerous hours have been wasted on creating print filters manually but recent distributions have included filters (typically based on ghostscript) which can automatically detect the type of file being printed (typically limited to ASCII and Postscript) and convert it into a format suitable for the printer. One of the problems that a print filter author faces is

"&�� "��

2�� 4��#�� M�� I��M��$��#��M�� A��.��

��#��{��(/-�� .��

��

�� A��A��

��&�� A��A��>�.��#��A��A��>��

��4��

5��%� �� %




Uempty
that the printer subsystem has no means of communicating the type of print job to the filter. So it’s up to the print filter to determine the type of print job and apply the correct conversions to it.
Print jobs that have been submitted to a BSD printing subsystem can be followed with the lpq command, and can be cancelled with the lprm command. Furthermore, the system administrator can run the lpc command, which allows him/her to prevent jobs being submitted to the queue, prevent jobs being sent to the printer, and to promote jobs to the top of the queue.

In traditional BSD printing, several modern features are not supported. This includes:

• Migrating jobs from one queue to another

• Queues with multiple printers attached for load balancing

• Queue authorization based on username

• Color conversions

Traditional BSD printing supports network printing too. On the print client, the only thing you have to do is identify the print server and printer queue name in the /etc/printcap file. On the server, it requires you to alter the /etc/hosts.equiv or /etc/hosts.lpd file to include the names of all clients that are allowed to print.



Student Notebook

Figure 16-6. LPR Next Generation (LPRng) LX032.0

Notes:

Some distributions have started to use LPRng, the LPR Next Generation print spooling mechanism. This LPRng was written by Patrick A Powell in order to overcome the limitations and security problems of the BSD Printer Spool Package.

LPRng is completely downwards compatible with BSD lpr/lpd. This means that in essence, the /etc/printcap file format has not changed, that the same directories and files are still being used, and that the same commands still work. However, some additional features have been added. Among these are:

• Multiple printers per queue. This means that if you have a number of (preferably identical) printers, you can all assign them to the same queue, and user jobs will be load balanced over all these printers.

• It is possible to move jobs from one queue to another, for instance if a printer is down.

• Several additional backends, for instance for SMB printers (printers attached to MS-Windows servers), NCP printers (printers attached to Novell servers) and JETDIRECT printers (network printers that attach directly to the network).

��(�!��2� �� 0�� 1

�� 5 �� .��%

�� /�� .��/�#��M�� .��

" �� >��>�.��#��

!� �� A��A��>�� A��A��>��A��A��

�� /5��-!�� T3��"$3!��%� ��




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

The last new file is /etc/lpd.conf, which holds a large number of configuration options for LPRng.



Student Notebook

Figure 16-7. Common UNIX Printing System (CUPS) LX032.0

Notes:

CUPS is the Common UNIX Printing System. It is a printing system written completely from scratch, and is designed to make use of the latest features of printers, such as network attached printers, color laser printers and so forth. It can run on any UNIX system, not just Linux.

CUPS supports various frontends. Of course, it is still possible to submit a print job using a command (both lpr and lp are included by default), but it is also possible to submit a print job via the network (both via LPD and IPP) and by using a C API. The latter makes it possible to integrate printer support into an existing application. kprint is an application that makes use of the C API.

CUPS also supports various backends. These includes backends for local ports (parallel, serial and USB) and various network protocols, such as LPD, IPP, SMB, NCP and JETDIRECT.

Also included is the notion of printer classes: pools of identical printers which handle jobs between them to achieve load balancing.

�� '(A�� "��0�'�"1

!�� 2-"F��

��#�� !�� -��%�'�� "��+!�� '��%�� +

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

��

�� #�� #� ��

��AA��>��>��




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


Student Notebook

Figure 16-8. Configuring Linux Printing LX032.0

Notes:

The first thing you need to do when configuring a printing subsystem is to take a look at what printing subsystems are offered by your distribution, and install the corresponding RPMs, if they have not yet been installed.

Some distributions may offer multiple printing subsystems. Red Hat and Debian are examples of this. In that case, the distribution might support the alternatives command which, through a series of ingeniously placed symbolic links, allows you to choose between different installed printer subsystems with a single command. On a Red Hat system, the command that lets you choose between LPRng and CUPS is alternatives --config print. For more information, see man alternatives.

The next step is to configure your printers. The configuration files involved depend on the printer subsystem. It is best to use a system administration program to perform this configuration, since these programs generally also allow you to set up your print filters, and these can be really hard to set up by hand. When done, make sure the printer subsystem is restarted and test everything.

�� !��

!�� '5 ��$ ��!2� +" ��$�/�2��

!� �� !� �� 5��

$�� #��

��

��




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


Student Notebook

Figure 16-9. Creating Printer Queues LX032.0

Notes:

Creating new printer queues used to be very tedious. To give you an idea, here's the shortlist of steps you'd have to go through:

1. Create the spool directory.

2. Add some special files to the spool directory (.seq, errs, status and lock).

3. Install an input filter. Input filters are used to convert the print job to a format the printer can understand. A simple text job probably doesn't need much conversion, except maybe for fixing stair-stepping, 1but most print jobs in the Unix world are actually PostScript documents, which may need to be converted to another format to print correctly on non-PostScript printers. This is usually done by ghostscript. In that case, the print filter is nothing more than a simple wrapper script around ghostscript

4. Add the correct entry to /etc/printcap. 1 Stair stepping is caused by printing Unix text files (in which a line is terminated with only the LF character) to a printer which expectsMS-DOS formatted text (in which a line is actually terminated with CF/LF). Your text will then look like this: This is line one. This is line two. This is line three.

�� "&��

5 �� A��A��

>��

��@K

@��%��@K

@��>'@K

@��@K

@�%��'@K

@�"%��"��@

��7<'�@K

@��%��'@K

@��>'@K

@��@K

@��%��@�%��7<'�@K

@�"%��'�"��@

N��

��

/�4��&��'89� ��+

��

N��

�� #��

" ��'�� #��M�� +

$��

�� A��A��




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



Student Notebook

Figure 16-10. BSD User Commands LX032.0

Notes:

To submit a job to the printer, the lpr command is being used. This will place a copy of the file to be printed in the spool directory and will inform the queue daemon about it. The -P option to lpr will allow you to select the printer the job needs to be printed on.

If your job is a PostScript file it will probably already be formatted and contain page numbers and so forth. If your job is a plain text file however, you may want to add headers, page numbers and other information. This can be done with the pr command. The output of pr can then be piped into lpr.

Users can also view the jobs that are currently queued up for a printer with the lpq command, and can remove their own jobs with the lprm command.

The lpc command allows you to manage your printers. It can be used in two ways: interactively and non-interactively. Interactive mode is started when you just enter the lpc command. You will see an lpc> prompt, which allows you to enter lpc commands. Non-interactive mode is started when you enter the lpc commands directly after lpc on the command line.

"&��

�� 4��5 Ê��_�^��!)�_��^��!)�_�`��5 Ê��_

�� .�� M��E�5 Ê��_

$��#� �� M��.��)�5 Ê��_�^Z�')'��_

/� �� .��5 Ê��_�P��))!��Q

�� .�� :4,�BÊ��_




Uempty
Here is the full list of commands that lpc supports:
If no queue name is given, the default queue name lp will be used. Users can override this behavior by setting the PRINTER shell variable to the name of their default queue.

Table 1: lpc commandsCommand Operationhelp [command] Prints a short description of each command

abort <printer>Terminates the spooling daemon on the local host and then disables printing for the specified printers. Use “all” to indicate all printers

clean <printer>Removes temporary files, data files and control files that cannot be printed.

disable <printer>Turns the specified printer queue off; new jobs will not be accepted

down <printer> <message>

Turns the specified printer queue off, disables printing and puts a message in the status file.

enable <printer> Enables spooling; allows new jobs into the spool queuequit

exitExits from lpc

restart <printer>Starts a new printer daemon; use it when the printer daemon, lpd, dies, and has left jobs to be printed.

start <printer> Enables printing and starts the daemon for the listed printers.status <printer> Displays the status of daemons and queues on the local system

stop <printer>Stops a spooling daemon after the current job completes and disables printing

topq <printer> [jobnum] [user]

Places the jobs in the order listed at the top of the printer queue

up <printer> Brings up everything and starts a new daemon.



Student Notebook

Figure 16-11. Configuring LPRng Printing LX032.0

Notes:

Since LPRng is downwards compatible with BSD, the previous visual still applies. However, configuration of LPRng is even harder than BSD, especially because of the more advanced print filters that are included by default in LPRng, so it is even more recommended to use system administration tools for this purpose.

On Red Hat, the preferred tools are printconf-tui and printconf-gui, which offer a text-based and a graphical user interface, respectively. On SuSE, the preferred tool is yast.

The file /etc/lpd.perms is not configured by printconf or yast. This file details what local and remote users are able to do on this print server: submit jobs, cancel jobs and so forth.

��

2�� 3�� 3��'$��+��' � 3+��

!�� A��A�� A��A��>�� !� ��

!� ��A��A��>��

$��

��$ ��5 �� '��>+

��$ ��Q��




Uempty

Figure 16-12. Configuring CUPS LX032.0

Notes:

If you decide CUPS, then you can configure it via a web browser interface. cupsconfig is a simple frontend which activates a suitable browser and lets it connect to http://server:631. Obviously the cupsd daemon has to be running first.

CUPS can be configured extensively via this browser interface. However, in some situations it might be necessary to dig into the configuration files (generally stored in /etc/cups) by hand.

CUPS supports a large number of filters, some of which are overlapping. That means when you configure your printer, you will see multiple filters to choose from. The best approach is to test the different filters with your workload, to see what filter yields the best result.

Once configured, CUPS supports all BSD printing commands. Note that lpc only works in read-only mode: you cannot make changes to the printing subsystem with lpc. In addition to this, CUPS also comes with replacements for the standard AT&T printing commands.

�� '�"

��

!� �� #��AA��#��;<(

��#� �� A��A��

!2� �� #�� %��

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

!2� ��Q��



Student Notebook


Notes:


1.

2.

3.

4.

��

One of the advantages of queues is that each user can have a different default queue set up for them.

Can any user bring the print queue down? Name a few people who can.

______________________________________________

Once the printer is down, no more jobs can be submitted to the queue.

Can users delete all their print jobs in a specific queue? If so, how?

______________________________________________

1)

2)

3)

4)

T/F

T/F




Uempty


Notes:

"��

�� #�� %� �

�� 4��

5 ��$ �!2�

!� ��



Student Notebook




Uempty
Unit 17. Troubleshooting

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



• Perform basic problem determination • Use the rescue mode


Accountability:



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

Student Notebook


Notes:

��

��

��

2��




Uempty

Figure 17-2. Troubleshooting LX032.0

Notes:

Troubleshooting is a short name for identifying and fixing problems. Most people consider it an art form, which takes years to get proficient in. This unit will give you some general techniques and tools that will help you in becoming proficient in it too.

Troubleshooting generally requires you to have a deep understanding of the underlying system and its dependencies, of the troubleshooting tools that are available on your system. And a lot of experience helps a lot too.

Useful things to have include documentation, reference systems and internet access. But there are two things that are most often forgotten:

Having no outside distraction is really important, especially when solving critical problems on production systems. It is really hard to solve a pressing problem if the phone rings every minute. In fact, large system administrator groups typically have emergency scenarios where one team member is tasked with answering the phone and talking to management so that the others are able to direct their full attention to the problem.

/��

"�� 4� ��

$�.�� 0 �� 0 �� 0 ��#� ��34��

2�� $�� " �� -��



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.




Uempty

Figure 17-3. Identifying the Problem LX032.0

Notes:

Identifying the problem usually starts with reading the logfiles, both the generic logfiles (such as /var/log/messages) and the applications specific logfiles, which are usually located in or under /var/log as well. Most services have a debugging switch which greatly increases the output to the logfile, especially if you reconfigure your /etc/syslog.conf file to log debug output too.

If your logfiles don't give you a clue, read the configuration files for the service that you are debugging. Use syntax checkers like checkpc where available.

Don't forget that a problem in a service might be caused by a problem in an underlying service, such as networking, DNS, PAM, full filesystems, wrong permissions or things like the X Font Server (xfs).

It might be useful to compare the actual situation with a working reference system, for instance your own laptop running Linux.

��

$��'�� +�� %��#��

$�� 2�� 4��%��#��

!��%��,��#��#��-��%� ��S��- ��/�� C4��

!��

!��%�� A�� 5��.��D� ��



Student Notebook

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




Uempty

Figure 17-4. strace, ltrace LX032.0

Notes:

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

��9��

��'��+�� '��+��%��

2��

2�� J��K�J��K��J��K�J��K

$�.�� 4�� #��



Student Notebook

Figure 17-5. Fixing the Problem LX032.0

Notes:

Once the error has been found, it needs to be fixed. This is typically a trivial task, but may become more complicated if the system refuses to boot properly because of that error. In that case, there is a number of things you can do:

• Boot from the boot disk that was created during the installation process. This boot disk usually consists of a boot loader (LILO or GRUB), a Linux kernel and (if needed) an Initial Root Disk. This allows you to bypass any problem that might exist in your master boot record or in your /boot partition, but will not help you if the problem is in your root filesystem or further along in the boot process.

A boot disk is typically created with the mkbootdisk shell script, and is system specific to a certain degree:

- The boot loader configuration contains the device name of your root partition, typically something like /dev/hda5. If your root partition has moved, you need to specify a new one at the LILO or GRUB boot prompt with linux root=/dev/hda6

%�!� ��

��4� ��#��

!� ��

�� 5��5�� A��%�� 5��




Uempty
- The kernel on the boot disk is optimized for your processor. This means that you cannot use a boot disk created on a Pentium-II machine to boot a regular Pentium machine.
- The initial root disk on the boot disk only contains the modules that are needed on your system.

• Boot into single user mode. This requires the boot process, up to and including the /etc/rc.sysinit file to be in full working order, but might help you if you have a problem starting certain services.

• Boot into a rescue mode. In this case, the full boot process is done from CD-ROM or the network. This allows you to fix virtually any problem on disk.



Student Notebook

Figure 17-6. Rescue Mode LX032.0

Notes:

The rescue mode is a special boot process from a "live" filesystem on CD-ROM or over the network. "Live" in this respect means that the filesystem is either accessed from CD-ROM/network directly, or the CD-ROM/network contains an image of a live filesystem that is loaded into a RAM disk. In both cases, the live filesystem contains enough utilities to fix almost any problem on disk.

Most distributions include the rescue mode as an option in the installation process and/or include special CDs which allow you to boot into a rescue mode.1 But other companies may make rescue CD-ROMs too. A popular giveaway at trade shows for instance is a bootable business card (a CD-ROM cut to credit card size) which include a Linux rescue mode.2 This is useful since the rescue mode is completely independent of the distribution used. It is perfectly possible to use the SuSE rescue mode to repair a Red Hat system, for instance.

1 Red Hat 7.2 Professional for instance comes with a System Administration CD, which includes a very complete rescue mode.2 Linuxcare for instance does this.

��

5��*��#�*�� !�,$?/�� %!� �� 4��2�� -�� E��

�� /�� A��#�� $� �� A��4�� $� ��%A��$� �� $��E�� A�� #��

��% ��A��%A��%A��




Uempty
Note that because rescue modes have to operate in limited environments, they usually can not include large programs. Some distributions, including Red Hat, therefore leave out vi and only include the tiny text editor pico.
No matter which rescue mode you use, some steps will have to be done after the boot process has finished:

• Create /dev device entries with mknod. Most rescue modes do not include the hundreds of device entries that a normal /dev filesystem would contain (with the resulting space loss) but include an intelligent mknod command which will make these device entries for you, with the proper major and minor numbers.

• Run fdisk to view and/or fix the partition table.

• Run fsck to check each filesystem for errors.

• Run mount to mount each filesystem, usually starting at a location like /mnt/sysimage.

Once these steps have been performed, you are ready to fix the problem. This will require you to go into the filesystems and edit files and so forth. Going into the filesystems can be done with the regular cp command, but this might cause problems when you try to run commands like lilo or rpm, because these programs use absolute pathnames which cannot be resolved.

If you encounter this, it's best to use the chroot command. This performs the chroot() system call, which makes the specified directory the root of your filesystem, and then starts a shell. All commands executed and pathnames referenced in this shell are now relative to the directory that you chrooted into, instead of relative to the root of your rescue disk. This means that commands like lilo and rpm will work without any special options.

You can exit the chrooted environment by exiting the shell with exit.

When you finished fixing the problem, you need to umount each filesystem in the proper order. In addition to this, it is wise to perform a sync every now and then, to make sure that changes are indeed written to disk.3

When all filesystems are unmounted, you can reboot your system. Don't forget to take out your boot media!

Some rescue modes try to perform the mknod/fdisk/fsck/mount sequence automatically.

3 The umount command will perform a sync automatically, but we're not taking chances here, are we?



Student Notebook


Notes:


1.

2.

3.

��

Internet access is required for troubleshooting.

If your X server does not start, then the problem might also be:a. The networkb. The font serverc. A full filesystemd. All of the above

Briefly describe the order of tasks to perform in the rescue mode. ______________________________________________

1)

2)

3)

T/F




Uempty


Notes:

' ��"��

�� 4� ��

�� .�� #��#��

��%��E�� #��

��%�� #��

�� #��

"�� H�� %�� 4��



Student Notebook




Uempty
Unit 18. Policies and Procedures

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



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


Accountability:



© Copyright IBM Corp. 2001, 2002 Unit 18. Policies and Procedures 18-1

Student Notebook


Notes:

Objectives


Discuss the need for policies and procedures

Discuss user and administrator policies

Discuss system management procedures




Uempty

Figure 18-2. About Your Systems LX032.0

Notes:

As a system administrator, you are faced with an almost impossible task. Your systems are paid for by the management of your company, and are intended for the users to do their regular work on. Management and the users expect you to make sure that these systems are 100% secure, extremely easy to use and cost virtually nothing.

About Your Systems

The systems you manage are not your own

Paid for by management

Intended for use by the users

You are expected to implement and manage the system so that it is

100% secureextremely easy to useand costs nothing...



Student Notebook

Figure 18-3. The Dilemma LX032.0

Notes:

The three requirements from the previous visual, security, ease of use and low cost are perpendicular to each other. It is usually fairly easy to attain one of the requirements, it is not impossible to attain two requirements, but it is virtually impossible to attain all three requirements.

Having a really secure and yet really easy to use system is usually really expensive. But on the other hand, cheap and easy to use systems are typically not very secure. This is the dilemma that system administrators face day to day. And since it's not the system administrator but the users who need to use the system, and the management that needs to pay for them, we can let these two groups of people handle the tough decisions. That's why we need policies: To clarify the relationship between management, system administrators and users.

The Dilemma

Ease of use

Secure Economical




Uempty

Figure 18-4. Policies LX032.0

Notes:

Policies are typically dry documents that spell out what is required of the users and administrators with respect to the computer systems. They are full of legal language and are not really interesting reading material. But yet, they are really important since they are sort of a "contract" between management, administrators and users, and determine the relation, obligations and expectations towards each other.

In most jurisdictions, common law has not yet caught up with the rapid advances of the ICT industry. This leaves a legal void which needs to be filled with a user policy. As an example, if I work in a bakery and decide to add some extra ingredients to the dough which eventually makes people ill, I can be prosecuted for a number of things, starting with disregarding hygiene codes that govern food-processing industries. On the other hand, if I work as a system administrator and upload a trojan horse program to a system which performs a full filesystem delete if my user account is ever wiped out, there is no law which applies. At least, in a large number of countries. In these cases, policies that are signed by the users and administrators (or better yet, that are part of your employment contract) sort of "augment" the law in the sense that they will be used in the court of law as a legally binding contract which was violated.

Policies

Policies help youDetermine the balance between security, ease-of-use and costSet the expectancy level of usersSet the expectancy level of system administratorsSet the expectancy level of managementDetermine what is acceptable use and what is not

In most jurisdictions, regular law has not yet caught up with advances in ICT technology

In that case, policies "augment" the law

Typical policies:User policyAdministrator policySecurity policy



Student Notebook

Figure 18-5. User Policy LX032.0

Notes:

A user policy typically describes how users can get access to the systems, what they can expect from the systems, and what is expected of them. These policies typically come in the form of handy booklets which also double as simple manuals for using the system.

Some things that need to be listed in a user policy are:

• The applications that are supported by the system, and the level of support that can be expected.

• The privacy policy with regards to personal and group files, e-mail and such.

• The service times: At what hours can the user expect that applications/servers are running and that the help desk is operational.

• Quota on disk space, CPU time and bandwidth.

• The password policy: How often do passwords need to be changed. What are the criteria for "good" passwords. Are users allowed to divulge passwords to others?

• Is usage of the systems for private purposes allowed and if so, when and how much?

User Policy

Describes how users can get access to the systemHostnames, login proceduresHow to contact the help desk

Describes what the users can expect from the systemApplications that are available/supportedPrivacy policyService timesQuota policy

Describes what is expected of the usersPassword policyUsage policy

Users need to be aware of user policy and express consent before access to systems is granted




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


Student Notebook

Figure 18-6. Administrator Policy LX032.0

Notes:

Administrators are users with special privileges and obligations. This typically requires a different policy. It can specify things like when to use the root account and when not, and special procedures for handling the root password.

But one really important thing to consider is the fact that the administrator can, and sometime has to violate the users privacy policy. It might be necessary for an administrator to look in the mail file or home directory of a user, to solve a problem there. The administrator policy can specify the measures that have to be taken to protect the privacy of users in cases like this, such as

• Actions that violate the users rights will always be performed under supervision of a colleague, who verifies that the level of violation was limited to that needed to solve the problem. If no colleague is available for supervision, then all actions need to be logged using script and reviewed by a colleague later.

• If possible, the users are warned beforehand. If that is not possible, users are informed afterwards.

Administrator Policy

Describe what is expected of administratorsEducation levelConfidentialityAvailability

Describe usage of administrator privilegesOnly su to root if really needed; use sudo otherwiseroot password maintenance

Describe what to do when an administrator has to violate other policies (e.g. privacy)

Administrators need to be aware of administrator policy and express consent before administrator access to systems is granted




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 18-7. Security Policy LX032.0

Notes:

The security policy describes the level of security that needs to be applied to various systems and applications, and describes the technical measures that need to be taken to reach that level of security. It is typically a tradeoff between the cost of security versus the cost of the data on the systems.

Security Policy

Describes the level of security that needs to be applied to various systems and applications

Describes the technical measures taken to reach that level of security

AuthenticationAuthorizationLoggingDetectionResponse

Tradeoff: cost of security vs. cost of data




Uempty

Figure 18-8. Procedure Handbook LX032.0

Notes:

Another document that you might want to create is a procedure handbook. This document describes common system administration tasks, and help you prevent errors.

Common tasks that are described in a procedure handbook are:

• Adding/removing a workstation/server to/from the network

• Adding/removing a user account

• Adding/removing printers

• Creation and storage of backups

• Regular and emergency shutdown and restart of important systems

• Upgrades of operating systems and critical software

A procedure handbook is typically a living, online document which is updated when procedures change.

Procedure Handbook

A procedure handbook describes common system administration tasks

Advantages:Reduces errorsPrevents forgetting stepsHelps train new administrators

Common procedures:Adding/removing a workstation/serverAdding/removing user accountsAdding/removing printersBackupsRegular/emergency power down of important systemsUpgrading the operating system or critical software

Typically a living, on-line document



Student Notebook

Figure 18-9. Management of System Management LX032.0

Notes:

The system management process needs to be managed too. Things to consider in this respect are:

• Testing procedures. How do you test your systems/applications for proper performance. If new hardware/software is delivered, what procedures apply to this? Do you need separate testing, staging and production servers?

• Change management. This applies to recording all changes that are made to the configuration of systems, and allows you (if done right) to roll back changes easily if they do not have the required result.

• Service Level management. This includes regular audits to see if the service levels that were agreed on with the users are being achieved, and reporting this to the user and/or management.

• Management of licenses. Most commercial software vendors issue licenses that allow you to use their software only on a limited number of systems, or with only a limited

Management of System Management

The system management process needs to be managed too

Things to consider:Testing proceduresChange managementService Level managementManagement of licensesManagement of maintenance contractsManagement of contractersDisaster planningHiring/Firing/Training system administratorsPurchasing guidelines




Uempty
number of simultaneous users. License management allows you to track all this, and to obtain additional licenses when needed.
• Management of maintenance contracts. This includes keeping track of all maintenance contracts, both for hardware and software, and determining if these contracts are really needed. It might be cheaper to do without a maintenance contract and pay per-incident fees if something happens.

• Management of contractors. Contractors are typically only hired for a single job but are always looking for opportunities to extend or expand the contract. Keeping track of what your contractors are doing is important because you don't want to become too dependent on them.

• Disaster planning. This typically comes down to brainstorming what steps to take in case of a disaster, like a fire which destroys the computer floor, or worse.

What is important to remember is that certain truths in daily life might not be true in case of a disaster. What if you are not able to enter your building, because of a fire next door? Does everybody know how to contact everybody else, even when outside the office? What if one or more administrators get an accident and end up in hospital or worse? Is crucial information, such as root passwords, available from somewhere else? What if the computer floor, including the backup tapes near the machines, are destroyed completely? Can you recreate your whole infrastructure and everything from your off-site backups?

• Hiring/firing/training system administrators. When hiring, do you give them all privileges right away or do you wait a certain amount of time? When firing, what procedures do you perform to make sure that he/she did not leave any trojan horses in the system? What do you do with the data that was stored in the administrators home directory?

• Purchasing guidelines. What brand of equipment do you buy? Are you going to buy rack-mounted equipment or not? When purchasing equipment, do you do a recalculation for weight of racks, power consumption and air conditioning? Are you always shopping around for the best bargain or are you going to stick to one vendor? The latter certainly makes warranty and maintenance contracts easier.



Student Notebook


Notes:


1.

2.

3.

Checkpoint

Under no circumstances is a system administrator allowed to violate privacy policies.

Where would you write down which steps to take if a new user account needs to be added to the system?

a. User policyb. Procedure handbookc. Security policyd. Administrator policy

What are the three dilemma factors to consider in system management?______________________________________________

1)

2)

3)

T/F




Uempty


Notes:

Unit Summary

Policies that govern the use and administration of your systems are essential for a healthy organization

Common law has not yet caught up with advances in ICT; in this case, policies "augment" the law

Policies that you might want are user policies, administrator policies and security policies

Procedures help you perform common tasks without making mistakes or forgetting steps



Student Notebook




AP
Appendix A. Checkpoint Solutions
Unit 1

1. True

2. b

3. Keep humidity levels sufficiently high (at least 40%) to prevent buildup of static electricity

Ground all equipment

Use prevention measures like touching the grounded case and/or using wrist straps and antistatic mats when maintaining equipment

Unit 2

1. False

2. d

3. On the boot diskette or on an NFS server.

Unit 3

1. BIOS, Boot Loader, Linux, init.

2. By setting runlevel 5 as the default runlevel in /etc/inittab.

Unit 4

1. Red Hat: setup, authconfig, kbdconfig, mouseconfig, ntsysv, sndconfig, timeconfig, Xconfigurator

SuSE: YaST, YaST2

Caldera: LISA

2. Download webmin-version.tar.gz from http://www.webmin.com

Untar it in the directory /usr/src

Go to the /usr/src/webmin-version directory

Run ./setup.sh and answer all questions

Start your web browser and connect to port 10000

Unit 5

1. Install, freshen and upgrade, uninstall, query and verify.

2. rpm -V -f /etc/sendmail.cf

Unit 6

1. It is the X-Windows server and controls the hardware (graphical adapter, monitor, mouse, keyboard).


© Copyright IBM Corp. 2001, 2002 Appendix A. Checkpoint Solutions A-1

Student Notebook

It allows other applications to use the hardware.

2. It displays the borders around the windows and presents a graphical way of starting and stopping applications and managing their windows.

3. By starting the application on the remote host with the correct -display option or $DISPLAY variable set.

You need to allow this first though. This is done using either xauth or xhost.

Unit 7

1. True

2. c

3. There is no command per se. A RAM disk is created automatically as soon as you start using it.

Unit 8

1. Size 0: 1 inode and 0 data blocks

Size 1: 1 inode and 1 data block

Size 2000: 1 inode and 2 data blocks

Size 12289: 1 inode and 12 data blocks directly from the inode, an indirect block, and an extra data block. Total 14 data blocks.

2. mounting it and using the cp command

using the mtools (mcopy in this case)

3. /etc/fstab to specify which filesystems use quota

quota.users and quota.groups in the root of the filesystem

Unit 9

1. Because there is either too much or not enough hardware support on the system.

Because you want to be involved in kernel development.

Because it is fun.

2. On the internet or from your distribution CDs.

3. Install kernel source

make mrproper

vi Makefile (change EXTRAVERSION)

make config, make menuconfig or make xconfig

make clean


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


AP
make dep
make bzImage

make modules

make modules_install

cp arch/i386/bzImage /boot/bzImage-version

cp System.map /boot/System.map-version

cp .config /boot/Config-version

mkinitrd -f /boot/initrd-version.img version

vi /etc/lilo.conf; lilo or vi /boot/grub/grub.conf

Unit 10

1. Real memory + paging space - ~ 1MB

2. It is reserved for the kernel

3. A paging partition is directly written in the partition table and to disk, while a paging file has to go through the filesystem

4. top continuously displays some vital system information on the screen

Unit 11

1. crontab -l

2. b

3. /etc/cron.deny and /etc/cron.allow

/etc/at.deny and /etc/at.allow

Unit 12

1. A will back up the files using the full pathnames, whereas

B will back up the file names using the relative pathnames

B can also restore its file into any directory.

2. b

3. False

4. True

5. Yesterday evening and you checked it this morning.


© Copyright IBM Corp. 2001, 2002 Appendix A. Checkpoint Solutions A-3

Student Notebook

Unit 13

1. b

2. In /etc/shadow.

Unit 14

1. Display a welcome message to users logging in remotely

2. c, e

Unit 15

1. It receives all logging requests and forwards it to the right destination, depending on priority and facility

2. It sends logs messages to the syslogd daemon

3. It rotates the log files

Unit 16

1. True

2. No - only system administrators or root

3. False

4. Yes, they can - by only specifying a queue name and not individual job numbers

Unit 17

1. False

2. d

3. mknod, fdisk, fsck, mount, chroot, fix the problem, exit, sync, umount, reboot

Unit 18

1. False

2. b

3. Security, ease-of-use and cost.


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

V1.2.2

ackpg