01 Linux System Administration I - Implementation - Notebook

V2.0.0.1

cover

��
Front cover
Linux SystemAdministration I: Implementation (Course Code QLX03)

Student NotebookERC 3.1

IBM Certified Course Material

Student Notebook

Trademarks

IBM® is a registered trademark of International Business Machines Corporation.

The following are trademarks of International Business Machines Corporation in the United States, or other countries, or both:

Windows and Windows NT are trademarks of Microsoft Corporation in the United States, other countries, or both.

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

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

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

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

AIX® DB2® Domino™Hummingbird® Lotus® OS/2®PS/2® XT™

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.

© Copyright International Business Machines Corporation 2001, 2004. 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.

June 2004 Edition

Student NotebookV2.0

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

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

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

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

Unit 1. Physical Planning and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2Issues in Physical Planning and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3Computer Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4Rack Mounted versus 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-1Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2Network Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3Network Install Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4Red Hat “Kickstart” Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6SuSE AutoYaST Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12

Unit 3. Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2Linux Startup Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3Basic Input Output System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4Master Boot Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5LILO - Linux Loader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7/etc/lilo.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8GRand Unified Bootloader (GRUB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-10GRUB - Grand Unified Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12/boot/grub/grub.conf or /boot/grub/menu.lst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13Starting the Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15Initial RAM Disk (initrd) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-19/etc/inittab (Red Hat/Fedora/SuSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20Starting Services (System V init Style) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22

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

© Copyright IBM Corp. 2001, 2004 Contents iii

Student Notebook

Configuring Services per Runlevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-24Starting and Stopping Services Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-25Booting Linux in Single-User Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-26Shutting Down a Linux System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-27Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-28Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-29

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

Unit 5. Packaging Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-2RPM Package Manager (RPM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-3RPM Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-4RPM Installing, Freshening and Upgrading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-6RPM Uninstalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-8RPM Querying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-9rpmdb (Red Hat/Fedora only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-11RPM Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-13RPM Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-15Creating RPMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-16Example Scenario: Hello, World! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-18hello.spec Preamble Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-19hello.spec Prep, Build, Install and Files Section . . . . . . . . . . . . . . . . . . . . . . . . . . .5-20RPM Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-22After RPM Build Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-24Integrated Package Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-25Keeping Up To Date (Fedora) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-26Keeping Up To Date (Red Hat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-27Keeping Up To Date (SuSE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-28Debian Package Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-29Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-31Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-32

Unit 6. X Window System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-2X Window System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-3X - Client/Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-4Examples of X Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-6


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


TOC
X Servers in Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7XFree86/Xorg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9XFree86/Xorg Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11Starting X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13Stopping X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15Session Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16X Networked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17X Applications Networked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18Applications Over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19X Sessions Networked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-21X Sessions Over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22Chooser Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24Font Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28
Unit 7. Kernel Compilation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2Why Kernel Compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3Compilation Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4Installing Kernel Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5Patching the Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-6Configuring the Kernel Compile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8Kernel Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10Compiling the Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12Installing the Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14Reboot System and Start New Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16Loading Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17Configuring the Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-19Sidestep: Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20Configuring the Kernel at Boot Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-22Configuring Modules at Load Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-25Configuring the Running Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-28Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-29

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


© Copyright IBM Corp. 2001, 2004 Contents v

Student Notebook

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

Unit 10. Filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2What is a File? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3What is a Filesystem? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4The Virtual Filesystem Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-5Filesystems Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-6A Typical UNIX Filesystem: ext2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-7Superblock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-8Inodes (Index Nodes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-9Data Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-11So... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-12Other Filesystem Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-14Creating a Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-16Mounting a Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-17


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


TOC
Mounting Filesystems at System Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-18Mount Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-20Unmounting Filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-22Checking a Filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-23ext2/ext3 Specific Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-25ReiserFS-Specific Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-27JFS-Specific Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-28Comparing Filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-29SHMFS-Specific Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-30Quota Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-31Quota Implementation on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-32Enabling Quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-33Configuring Quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-34Quota Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-36Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-37Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-38
Unit 11. Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2Linux Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3Example: Lightly Loaded System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4Example: Heavily Loaded System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5Creating Paging Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6Useful Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-8Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11

Unit 12. Linux on IBM eServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2How Customers are Using Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3Workload Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4Linux High-Performance Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5Distributed Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6Application Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7Infrastructure Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-8And How About Linux on the Desktop? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9Introducing the IBM eServer Brand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-10IBM eServer xSeries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-12VMware ESX/GSX Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-14IBM eServer iSeries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-15IBM eServer pSeries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-16IBM eServer zSeries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-17IBM eServer BladeCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-19IBM eServer Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-21Which is “the Best” for Running Linux? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-22Workloads Revisited . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-23Workload Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-24Linux HPC Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-25


© Copyright IBM Corp. 2001, 2004 Contents vii

Student Notebook

Distributed Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-27Application Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-28Infrastructure Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-29...And On the Desktop? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-30Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-31Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-32

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

Unit 14. Backup and Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-2Backup Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-3Incremental versus Differential Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-4Sample Backup Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-5Sample Monthly Backup Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-7Backup Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-8Default Backup Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-10tar Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-11GNU tar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-13cpio Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-14dump Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-15LVM Snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-16dd Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-18Other Backup Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-20Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-21Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14-22

Unit 15. User Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-2Security Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-3User Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-4Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-5User Private Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-7Shadow Password Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-8Command Line User Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-10


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


TOC
/etc/skel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-11Command Line Group Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-12Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-13/etc/passwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-14/etc/shadow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-15/etc/group and /etc/gshadow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-17/etc/issue and /etc/issue.net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-18Message of the Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-19Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-20Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-21
Unit 16. User-Level Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-2User-Level Security Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-3Pluggable Authentication Module (PAM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-4Authentication Before PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-5Authentication with PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6PAM Configuration File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-8Common PAM Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-11Principles of Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-12File Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-14Changing Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-16umask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-17Example: Creating a Team Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-18Root Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-19su . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-20sudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-21Security Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-23Useful Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-24Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-25Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-26

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

Unit 18. Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-1Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-2Users, Printer Queues, Printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-3Printing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-4


© Copyright IBM Corp. 2001, 2004 Contents ix

Student Notebook

Common Printing Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-6BSD Printing Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-7LPR Next Generation (LPRng) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-9Common UNIX Printing System (CUPS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-11CUPS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-13Printer Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-14CUPS Configuration with lpadmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-15CUPS Configuration with a Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-16CUPS Configuration with kprinter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-17Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-18Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18-19

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

Unit 20. Policies and Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-1Unit Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-2About Your Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-3The Dilemma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-4Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-5User Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-6Administrator Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-8Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-10Procedure Handbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-11Management of System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-12Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-14Unit Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20-15

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

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

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X-1


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


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:

Windows and Windows NT are trademarks of Microsoft Corporation in the United States, other countries, or both.

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

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

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

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

AIX® DB2® Domino™Hummingbird® Lotus® OS/2®PS/2® XT™


© Copyright IBM Corp. 2001, 2004 Trademarks xi

Student Notebook


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


pref
Course Description
Linux System Administration I: Implementation

Duration: 5 days

Purpose

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

Audience

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

Prerequisites

• IBM Linux course LX02 (Linux Power User)

• Practical experience in running Linux as a user

Objectives

After completing this course, you should be able to:

• Physically plan and manage the system and its environment

• Install Linux from a network install server

• Manage system startup and shutdown

• Select and use system administration tools when appropriate

• Use packaging tools to create, install and deinstall packages

• Configure and manage the X Window System

• Manage character devices, PCMCIA and USB

• Manage hard disks, partitions, RAID and LVM

• Create and manage filesystems

• Recompile the Linux kernel

• Perform memory management

• Use scheduling tools

• Create and restore backups


© Copyright IBM Corp. 2001, 2004 Course Description xiii

Student Notebook

• Perform user administration

• Apply user-level security

• Manage logging

• Configure and manage printers

• Troubleshoot Linux problems

• Discuss policies and procedures

Contents

• Physical system management and planning

• Advanced Linux installation

• System startup and shutdown

• System Administration tools

• Packaging tools

• X Window System

• Character Devices, PCMCIA and USB

• Managing hard disks, partitions, LVM and RAID

• Filesystems

• Kernel compilation

• Memory management

• Scheduling

• Backup and restore

• User administration

• User-level security

• Logging

• Printers

• Troubleshooting

• Policies and procedures


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


pref
Agenda
Day 1

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

Day 2

Unit 5 - Packaging Tools Exercise 5 - Packaging Tools Unit 6 - X Window System Exercise 6 - X Window SystemUnit 7 - Kernel Compilation and ConfigurationExercise 7 - Kernel Compilation and Configuration

Day 3

Unit 8 - Character Devices, PCMCIA and USBUnit 9 - Block Devices, RAID and LVM Exercise 9 - Block Devices, RAID and LVM Unit 10 - Filesystems Exercise 10 - Filesystems Unit 11 - Memory Management Exercise 11 - Memory Management Unit 12 - Linux on IBM eServer

Day 4

Unit 13 - Scheduling Exercise 13 - Scheduling Unit 14 - Backup and Restore Exercise 14 - Backup and Restore Unit 15 - User Administration Exercise 15 - User Administration Unit 16 - User-Level Security Exercise 16 - User-Level Security


© Copyright IBM Corp. 2001, 2004 Agenda xv

Student Notebook

Day 5

Unit 17 - Logging Exercise 17 - Logging Unit 18 - Printers Exercise 18 - Printers Unit 19 - Troubleshooting Exercise 19 - Troubleshooting Unit 20- Policies and Procedures


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


pref
Certification Information
Several professional certifications currently exist for Linux. This course, combined with other Linux courses, will prepare you for all of them. For more information, see appendix B.

This course, in combination with other courses, has been certified by ProCert (http://www.procert.com) as appropriate course material for preparing for LPI certification tests. The statement below reflects this.

Linux Professional Institute Statement

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


© Copyright IBM Corp. 2001, 2004 Certification Information xvii

Student Notebook


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


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, 2004 Unit 1. Physical Planning and Maintenance 1-1

Student Notebook

Figure 1-1. Unit Objectives LX033.1

Notes:

Unit Objectives


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

List best practices for physical maintenance


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


Uempty

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

Notes:

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

Issues in Physical Planning and Maintenance

Weight

Footprint

Accessibility

Power

Temperature

Humidity

Static electricity

Cleaning

FFOO

CO

CO

50

40

30

20

10

0

1020

30

40

50

120

100

80

0

20

20

40

60

60

40



Student Notebook

Figure 1-3. Computer Room LX033.1

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

Computer Room

In most cases, servers will be placed in separate computer rooms

AdvantagesRaised floor makes it easier to keep tidySeparate air conditioning settings allows optimum environmentAccess control systems disallow unauthorized access to console

DisadvantagesLess accessible if console access is needed




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 versus Lots of Boxes on Shelves LX033.1

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, and so forth.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.

Rack Mounted versus Lots of Boxes on Shelves

Industry standard (19") racks can store a variety of IT-related hardware

Servers, server blade enclosuresNetwork equipmentMonitors, keyboards, KVM switchUPS

Advantages:Significantly reduced footprintEasy to limit physical access to systemEasy to keep tidyLooks good

Disadvantages:Rack-mounted equipment usually more expensivePhysical access usually less convenientA full rack might need floor reinforcement




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

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

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

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

But there are several disadvantages as well:

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

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

Some rack-mounted servers today incorporate drawer-like mechanisms on the side so that you can slide the whole server forward to perform physical maintenance. If that is the case, make sure the cabling in the back has sufficient slack, and that you’ve got a floor plate attached to the front of the rack. Without that floor plate attached, there’s a risk of the whole rack tipping over if you pull out multiple servers.

• 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-500 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 LX033.1

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.

Power Considerations

Beware of power consumption of devices

Total amount of "watts" should not exceed Volt*Amps of electrical circuit

US: Typically 120V*20A = 2400 WEurope: Typically 240V*16A = 3840 W

Consider using Surge Arrestors to suppress spikes from lightning, and so forth

Consider using an Uninterruptible Power Supply (UPS) for critical components like servers and network backbone

Usually battery-operatedKeeps power up for 10-30 minutes




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

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.

Air Conditioning

Might need air conditioning for maintainingStable temperatureConstant humidity

Ideal temperature: 17-20C (64-68F)Unstable temperature may lead to physical damage because of expansion/contraction of componentsHigh temperature might lead to overheating of internal components

Ideal humidity: 40%-60%Low humidity might cause buildup of static electricityHigh humidity might lead to condensation

A/C capacity measured in "BTU/hr" or "tons"One "watt" of power consumption needs 3.412 BTU/hr of coolingOne "ton" equals 12,000 BTU/hr




Uempty
Air conditioning capacity is expressed in “BTU/hr” (British Thermal Units), which is a standard unit for measuring heat generated. One BTU equals 1055 Joules. Thus, to cool one Watt of power converted into heat, you need 3.412 BTU/hr. For reference, a human being produces about 300 BTU/hr when performing regular office work.
Air conditioning capacity is sometimes also expressed in “tons”. This relates to the capacity needed to freeze a ton of water in 24 hours. One ton equals 12,000 BTU/hr. Consequently, a ton of air-conditioning is able to remove 12000 * 1055 Joules / 3600 seconds equals about 3500 Watt of heat - the heat generated by about 10 medium-sized servers.

Coincidentally, in moderate climates, it takes about 3500 Watt to keep a one-ton A/C unit operating. This leads to a simple rule of thumb: you need a watt of air-conditioning for every watt that your computers use.



Student Notebook

Figure 1-7. Fire Detection and Suppression System LX033.1

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.

Fire Detection and Suppression System

Make sure that you can detect a fire earlySmoke, carbon monoxide detector

Also put detectors under raised floors and above lowered ceilings

Consider fire suppression methodsWater? CO2? Inert gas?

Consult local fire department

Consider installing a master switch which terminates all power to your computer room immediately




Uempty

Figure 1-8. Best Practices LX033.1

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.

Best Practices

Be aware of static electricity when replacing componentsGround all components properlyTouch outer case and/or grounded connector before going insideStore unused components in static-free bagsDo not touch electrical circuits if you can avoid itConsider using wrist-straps and anti-static mats

Use only specialized materials/tools/companies for cleaning computer equipment

Check fans regularly for proper operation

Keep a toolbox handy with an assortment of tools



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

Notes:

Write down your answers here:

1.

2.

3.

Checkpoint

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

Notes:

Unit Summary

Most large installations benefit from having a separate computer room with raised floors and rack-mounted equipment

The maximum amount of power that is consumed by all system should not exceed your circuits limits

Air conditioning should be powerful enough to cool all your equipment running at full power, and should be able to keep humidity within limits

A fire detection and suppression system may also be needed; consult your local fire department for advice




Uempty
Unit 2. Advanced Linux Installation

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



• Perform a network installation

• Discuss network install servers

• Discuss Red Hat/Fedora kickstart installs

• Discuss SuSE AutoYaST installs


Accountability:

• Checkpoint questions • Machine exercises


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

Student Notebook


Notes:

Unit Objectives


Perform a network installation

Discuss network install servers

Discuss Red Hat/Fedora kickstart installs

Discuss SuSE AutoYaST installs




Uempty

Figure 2-2. Network Installations LX033.1

Notes:

Most Linux systems are installed from the distribution CD-ROMs (or DVDs). This is a convenient method if you only need to install one or a few systems, but quickly becomes tedious if you need to install 10 or more systems, especially if each system has to be installed with the same settings. More advanced installation methods exist which are convenient for these situations, and in all but a few cases, this comes down to network installations, where the RPMs to be installed are downloaded from the network. Various network protocols exist to retrieve the installation RPMs, and the protocols that are supported depends on your distribution. Support might be included for NFS, FTP, HTTP and SMB. An obvious requirement for a network-based install is that somewhere on the network you need to configure a network install server, which holds all the RPMs for your distributions. Another requirement is that your systems to be installed are equipped with a network adapter, which is supported by your network boot diskette. If your network adapter is not supported by the boot diskette, you might also need an additional diskette which contains the device support in the form of Linux kernel modules.

Network Installations

Installations where packages to install are downloaded from the network

Network protocols supported depends on distributionNFSFTPHTTPSMB

Requires a network install server

Usually requires special network-enabled boot media



Student Notebook

Figure 2-3. Network Install Server LX033.1

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.

Network Install Server

Should be a Linux/UNIX server

Content of all relevant CDs copied to diskUse a naming scheme that allows multiple versions/distributions to be exportedFor example, /export/rh9, /export/fedora1, /export/rhel3es, /export/suse90, ...

Typically NFS, sometimes (anonymous) FTP, HTTP, SMB

For Red Hat, copy at least .discinfo, RedHat/ and images/

For Fedora, copy at least .discinfo, Fedora/ and images/

For SuSE, copy CD 1 completely, from all other CDs copy suse/ and media*




Uempty
If you decide to offer HTTP installs, you can simply create a symbolic link from your document_root directory to the directory where your CDs are copied into, as long as “FollowSymLinks” is set in your web server configuration.
After creating the installation directory, you need to copy the contents of the relevant CDs to that directory. This needs to be done with all preservations of permissions, users and so forth intact, and can best be done with the cp -a command.

For a Red Hat distribution, make sure you copy at least the .discinfo file, and the RedHat/ and images/ directories. For a Fedora distribution, you need .discinfo, Fedora/ and images/, and for a SuSE distribution, make sure you copy the whole CD1 and at least the suse/ directory and the media* files of the subsequent CDs.



Student Notebook

Figure 2-4. Red Hat “Kickstart” Installations LX033.1

Notes:

“Kickstart” is Red Hat and Fedoras 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|Fedora}/base/comps.xml file. These package groups are identified with an ampersand, for instance “@ Printing Support”.

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

Red Hat/Fedora "Kickstart" Installations

Red Hat/Fedora method of automating installations

Involves a "ks.cfg" file with three sections:Install commands: answers to questions of installation process%packages section: List of packages/package groups to be installed%pre, %post section: List of pre or post-install commands to be executed

Create ks.cfg manually or with redhat-config-kickstart, or use /root/anaconda-ks.cfg (created during installation)

ks.cfg can be put on boot floppy or on NFS serverNFS also requires a DHCP server

Kickstart installs started with linux ks=<ks.cfg URL> at syslinux boot:-prompt

Edit syslinux.cfg for automation




Uempty
It is also possible to create a %pre section, which is executed before the installation starts. This is generally used only to implement custom partition schemes.
An example kickstart file will look like this:

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

Kickstart files can be created by hand, but Red Hat has also released a tool which may help you generate kickstart files: redhat-config-kickstart (formerly known as ksconfig). This tool is available on the distribution CDs in the ksconfig RPM. As an added bonus, the



Student Notebook

Red Hat/Fedora installer, Anaconda, generates a kickstart file for you based on the choices made during the installation process itself. This file is called /root/anaconda-ks.cfg.

The kickstart configuration file can be stored on the boot diskette, or can be stored on a network server. Kickstart installs are then started by typing linux ks=<URL> where <URL> is the location where the ks.cfg file is stored. Examples are ks=floppy and ks=http://10.0.0.1/kickstart/ks.cfg. If you do not supply a URL (“linux ks”), then the location of the kickstart file is taken from the DHCP “next-server” and “filename” option fields in the DHCP reply from the DHCP server.

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

default linux ks prompt 0




Uempty

Figure 2-5. SuSE AutoYaST Installations LX033.1

Notes:

SuSE also supports autoinstallations. On the most recent distributions, this is done through AutoYaST. Earlier SuSE distributions used other, more complicated and limiting ways of performing autoinstallations.

AutoYaST installations revolve around an XML based file containing all the installation information. This file can technically be created by hand, but that’s a huge task. It is far easier to use yast autoyast to create this file.

This file can then be saved on a floppy disk or on the network server. You then need to boot the system from regular boot media. In order to start the install, you need to supply two URLs to the boot loader:

• The first URL is the URL where the installation images can be found. This URL generally has the form install=nfs://10.0.0.1/export/suse82

• The second URL is the URL where the AutoYaST file can be found. This URL generally has the form autoyast=nfs://10.0.0.1/profiles/myprofile.xml

SuSE AutoYaST Installations

SuSE method of automating installs

Involves an autoyast configuration file (XML) containing all installation information:

General settings for keyboard etc.Partition settingsPackagesPre- and post-install scripts

Create configuration file with yast autoyast

Store file on floppy or on network server

Start installation with boot parameters:install=nfs://10.0.0.1/export/suse90 autoyast=nfs://10.0.0.1/profiles/myprofile.xml



Student Notebook

In addition to this, you might also need to specify the network adapter and type. This typically looks like: insmod=eepro100 netdevice=eth0.

Just as with Red Hat and Fedora, it is possible to modify the syslinux.cfg file on the boot floppy to start the installation manually.




Uempty


Notes:


1.

2.

3.

Checkpoint

A network install 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 some possible locations where a Red Hat/Fedora Kickstart or SuSE AutoYaST file can be stored?

______________________________________________

______________________________________________

1)

2)

3)

T/F



Student Notebook


Notes:

Unit Summary

Network install servers are convenient means of software distribution, both for doing upgrades and installs

A network install server typically exports multiple versions of multiple distributions via NFS, FTP or HTTP

To perform a network install you typically need a special boot diskette, and sometimes additional module disks as well

Red Hat/Fedora "Kickstart" and SuSE "AutoYaST" install methods allow you to automate installations




Uempty
Unit 3. Startup and Shutdown

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



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


Accountability:

• Checkpoint questions • Exercises


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

Student Notebook


Notes:

Unit Objectives


Describe the Linux startup flow

Configure autostarting services

Boot Linux in single-user mode

Perform a proper shutdown of a Linux system




Uempty

Figure 3-2. Linux Startup Flow LX033.1

Notes:

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

Linux Startup Flow

power on

BIOS

Linux kernel

and initrd

init

system ready

boot loader

Hardware boot

Software boot

Low level initialization of

important hardware (disk, cpu, vga adapter...)

Usually GRUB or LILO

Full initialization of all hardware

Runs boot scripts and starts system services

...Have a lot of fun



Student Notebook

Figure 3-3. Basic Input Output System LX033.1

Notes:

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

• It checks the memory • It loads various options from non-volatile memory, for instance memory timing

parameters, IRQ assignment to devices, and the order of boot devices. These options can be set by the user when pressing Del, F1, F2 or some other key while the memory is being tested.

• It checks for the availability of boot devices, and • Loads the Master Boot Record of the first available boot device. This first sector is

stored in memory and executed.

Another thing the BIOS might do is configure (IRQ, DMA, I/O addresses) or disable peripherals (such as serial ports, parallel ports, network adapters, keyboards, mice and sound cards) that are integrated on the motherboard.

Basic Input Output System

Checks memory and hardware (POST)

Loads options from non-volatile memoryMemory timingsOrder of boot devices

Checks for boot devicesFloppy disksCD-ROMHard disks

Loads Master Boot Record of boot device and executes it




Uempty

Figure 3-4. Master Boot Record LX033.1

Notes:

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

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

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

• A 2-bytes magic number, which is used to check whether this is a valid MBR.

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

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

Master Boot Record (MBR)

Size: 512 bytes (first sector of hd)

addressed by BIOS

Content:446 bytes program code (to boot an operating system)

64 bytes partition table with max. 4 entries

2 bytes "magic number"

Master Boot Record



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. LILO - Linux Loader LX033.1

Notes:

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

-v Gives a verbose output. -v -v Gives a very verbose output. In fact, you can have a total number of eight '-v's,

giving you more and more output, until you literally drown in debug output. -t Only tests the validity of the config file; does not actually write to the MBR. -u, -U With this option, lilo restores an older backup copy of the MBR to the MBR on

disk. This backup was made the first time lilo was run and is called /boot/boot.0300 or /boot/boot.0800.1 It can be used to recover from a mangled MBR for instance, and can be used for a complete deinstall of Linux.2

For more details, refer to the lilo manual page (man lilo) 1 The numbers are the major and minor numbers of the device. 0300 is your first IDE disk, 0800 is your first SCSI disk.2 Note that to clean up the MBR, you can also run the fdisk /mbr command from MS-DOS or Windows. This undocumented featurerestores the MBR to a pristine state.

LILO - Linux Loader

MBR

LILO boot sector

addresses "map" (CHS)

contains the LILO boot sector (1st stage)

Lilo core

"/boot/boot.b"

LILO 2nd stage - can localize vmlinuz, initrd and load them

(CHS)

"/boot/map"

Configuration:

/etc/lilo.conf

addresses LILO core (CHS) /sbin/lilo

generates /boot/map and writes its address into LILO boot sector



Student Notebook

Figure 3-6. /etc/lilo.conf LX033.1

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.

/etc/lilo.conf

Where to store the 1st stage (MBR)

Where the map file is stored

Which 2nd stage boot loader to use

Which message to display

Ask for the OS to load

Timeout for booting in deciseconds (1/10s)

Default OS is a Linux system with kernel

/boot/vmlinuz

The root partition to mount is /dev/hda5 and

it should be mounted read-only

Pass the "mem=128M" option to the kernel

This non-Linux operating system is booted

when the user enters "dos" at the

LILO prompt.

boot=/dev/hda

map=/boot/map

install=/boot/boot.b

message=/boot/lilo.msg

prompt

timeout=50

image=/boot/vmlinuz

label=linux

root=/dev/hda5

append="mem=128M"

read-only

other=/dev/hda1

label=dos

table=/dev/hda




Uempty
default Identifies the image that will be the default (if the user just hits Enter). If no default image is specified, the first image will be the default image.
timeout The timeout to wait for a user response, measured in deciseconds (1/10th of a second).

image The Linux kernel image to use

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

root The root filesystem to be used for this OS.

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

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

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

table The partition table to use for this operating system.

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

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

linear and lba32 are mutually exclusive.

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

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

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



Student Notebook

Figure 3-7. GRand Unified Bootloader (GRUB) LX033.1

Notes:

GRUB (GRand Unified Boot Loader), as LILO, consists of a number of separate stages:

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

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

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

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

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

GRand Unified Bootloader (GRUB)

Program stored in MBR (first stage) and in /boot/grub (1.5th and second stage)

Understands filesystem structureNo need to activate a configuration as with LILO

Configuration file /boot/grub/grub.conf (Red Hat) or /boot/grub/menu.lst (SuSE)

Installed in MBR with grub-install

When system boots:Select predefined OS to boot, orUse command language to boot non-predefined OSCommand language compatible with configuration file

GRUB additional features:MD5 encrypted passwordsHiding/Unhiding partitions




Uempty
If a “splashimage” was included in the GRUB configuration, then the second stage will display the menu in a graphical mode, with the splash image as background.
The GRUB configuration file is typically stored in your /boot filesystem, in a separate GRUB directory, and called grub.conf (Red Hat) or menu.lst (SuSE). On a regularly booted Linux system, this file is thus referenced as /boot/grub/grub.conf or /boot/grub/menu.lst. It contains all predefined operating systems and their options and peculiarities.

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

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

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

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

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

3 The problem lies in Windows 9x itself: When a Windows system boots, it goes through the partition table and assigns a drive letter 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.



Student Notebook

Figure 3-8. GRUB - Grand Unified Bootloader LX033.1

Notes:

The visual shows the GRUB startup sequence graphically.

GRUB - Grand Unified Bootloader

MBR

Stage 1addresses stage1_5 (CHS)

contains stage1

Stage 1_5

filesystem driver, loads

(hd0,3)/grub/stage2

Stage 2

Configuration:

SuSE:

/boot/grub/menu.lst

Fedora/RedHat:

/boot/grub/grub.conf

loads for example (hd0,3)/vmlinuz or Windows via "chainloading"




Uempty

Figure 3-9. /boot/grub/grub.conf or /boot/grub/menu.lst LX033.1

Notes:

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

The file starts with a few general configuration options:

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

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

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

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

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

/boot/grub/grub.conf or /boot/grub/menu.lst

default=0timeout=10title Red Hat Linux 9 (2.4.20-8) root (hd0,2) kernel /vmlinuz-2.4.20-8 ro root=/dev/hda5 initrd /initrd-2.4.20-8.imgtitle SuSE Linux 8.2 kernel (hd0,2)/vmlinuz-2.4.20-4GB-i686 root=/dev/hda6 initrd (hd0,2)/initrd-2.4.20-4GB-i686title Windows 95 unhide (hd0,0) hide (hd0,1) rootnoverify (hd0,0) makeactive chainloader +1title Windows 98 unhide (hd0,1) hide (hd0,0) rootnoverify (hd0,1) makeactive chainloader +1



Student Notebook

root The root partition of the filesystem. All files that are referenced later on are stored on this filesystem. Specifying root is not required, but you will have to identify the root partition every time you mention a file instead, as is done with the SuSE stanza.

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

initrd An initial root disk that needs to be loaded.

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

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

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

makeactive Mark this partition active in the partition table.

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

Note that different distributions can and have made extensions to grub, which allow for instance graphics to be used.




Uempty

Figure 3-10. Starting the Kernel LX033.1

Notes:

When the user selects a Linux operating system in the boot loader, then the boot loader will load the Linux kernel.

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

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

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

Starting the Kernel

Once the kernel is loaded, it is started by the boot loader

On most architectures (including i386) the kernel is compressed with a decompress program included

When the kernel starts, it detects all hardware and switches the CPU to multitasking, multiuser mode



Student Notebook

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

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




Uempty

Figure 3-11. Initial RAM Disk (initrd) LX033.1

Notes:

Not all hardware is supported in the core kernel image. In fact, almost all hardware support in Linux today comes in the form of modules. These modules are pieces of code that are loaded into kernel memory only if required.

This works well, but leads to a minor problem if kernel modules are needed to mount the root filesystem. This can happen, for instance because:

• The root filesystem sits on a hard disk type for which support was not compiled into the kernel image. This applies mostly to SCSI

• LVM or RAID was used, and LVM or RAID support was not compiled into the kernel image.

• The root filesystem uses ext3, JFS or ReiserFS as filesystem type, and support for these filesystems was not compiled into the kernel image.

In these cases, you are going to need an Initial RAM Disk (sometimes also called an Initial Root Disk). This is a file containing a compressed image of an ext2 filesystem, which in turn contains two things:

Initial RAM Disk (initrd)

An Initial RAM Disk (initrd) is needed if the kernel can't access the root filesystem without modules (SCSI, LVM, RAID, ext3, reiser)

The initrd is loaded into memory by the boot loader

The initrd contains a linuxrc script that loads the modules from the RAM disk and mounts the actual root filesystem

Linux Kernel

linuxrc

mount actual root fs

kernel

modules

initrd

no initrd



Student Notebook

• A linuxrc script

• The kernel modules that are needed

The initrd image is loaded into memory by the boot loader, just like the Linux kernel. When the Linux kernel starts, it detects the presence of the initrd. It then proceeds to uncompress and mount this filesystem as temporary root. The kernels last direct action is then to start the linuxrc script.

The linuxrc script loads all the required modules, mounts the true root filesystem and then executes a system call pivot_root. This switches the position of the initrd and the true root filesystem. From that point on, the actual root filesystem is mounted at its correct location, and linuxrc is able to continue the boot process by starting the /sbin/init program.




Uempty

Figure 3-12. init LX033.1

Notes:

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

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

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

init

init is started by the kernel after the root fs is mounted

init reads configuration file /etc/inittab

Decides on default runlevel if no runlevel is given

Runlevels have different meaning:0: halt1: single user mode2: multiuser without NFS3: full multiuser mode4: unused5: multiuser with graphical login6: reboot

init will start all programs for that runlevel

Note: Once the system has started, you can switch runlevels with init <runlevel> or telinit <runlevel>



Student Notebook

Figure 3-13. /etc/inittab (Red Hat/Fedora/SuSE) LX033.1

Notes:

The most important lines of the /etc/inittab file are shown here. Because there are minor differences in Red Hat/Fedoras and SuSEs /etc/inittab file, they are shown side by side.

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

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

• Activating swap spaces

• Setting the hostname

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

• Turning on quota support

• Loading important kernel modules

• Checking all other filesystems and mounting them

/etc/inittab (Red Hat/Fedora/SuSE)

# Default runlevel

id:3:initdefault:

# System initialization.

si::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0







# Trap CTRL-ALT-DELETE

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

# Run gettys in standard runlevels

1:2345:respawn:/sbin/mingetty tty1






# Run xdm in runlevel 5

x:5:respawn:/etc/X11/prefdm -nodaemon

The default runlevel is 3

Always run /etc/rc.d/rc.sysinit (RH)

or /etc/init.d/boot (SuSE)

Run /etc/rc.d/rc (RH) or /etc/init.d/rc

(SuSE) with the runlevel as parameter

Trap the three-finger salute

Allow users to log in on six virtual

consoles (Virtual consoles can be

activated with Alt-F1 through Alt-F6)

Start a graphical login prompt (xdm,

kdm or gdm) in runlevel 5

# Default runlevel

id:3:initdefault:

# System initialization.

si::bootwait:/etc/init.d/boot

l0:0:wait:/etc/init.d/rc 0







# Trap CTRL-ALT-DELETE

ca::ctrlaltdel:/sbin/shutdown -r -t4 now

# Run gettys in standard runlevels

1:2345:respawn:/sbin/mingetty --noclear tty1






Red Hat, Fedora SuSE




Uempty
• Deleting various lockfiles which may have been left over from a crash
• Enabling the clock

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

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

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

The last command, which is only run in runlevel 5, will start the prefdm command, which in turn will start xdm, gdm or kdm. These programs will present a graphical login screen. This is unique to Red Hat/Fedora: SuSE starts this through a regular init script (covered in the next few visuals).

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

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

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

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



Student Notebook

Figure 3-14. Starting Services (System V init Style) LX033.1

Notes:

The rc script is a very important script. Although small, it is responsible for starting almost all services that are active in the runlevel that was specified as parameter.

What this script basically does is the following:

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

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

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

These scripts are in fact not scripts at all, but are symbolic links to generic scripts in /etc/rc.d/init.d or /etc/init.d.6 Every server program that is installed on a Linux system is supposed to have a corresponding control script in this directory, with the same name as 4 This directory is a symlink to /etc/init.d/rc<runlevel>.d in SuSE5 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.6 Depends on the distribution used.

Starting Services (System V init Style)

init

/etc/rc.d/rc3.d/K* stop

/etc/rc.d/rc3.d/S* start

/etc/rc.d/rc 3 (Fed/RH)

/etc/init.d/rc 3 (SuSE)

(Symlinks to the actual

start/stop script)

/etc/inittab

# ls -l /etc/rc.d/rc3.dlrwxrwxrwx 1 root root 17 Mar 16 21:17 K10pulse -> ../init.d/pulselrwxrwxrwx 1 root root 17 Mar 16 21:17 K10xntpd -> ../init.d/xntpdlrwxrwxrwx 1 root root 17 Mar 16 21:17 S10network -> ../init.d/networklrwxrwxrwx 1 root root 17 Mar 16 21:17 S11portmap -> ../init.d/portmap.lrwxrwxrwx 1 root root 17 Mar 16 21:11 S99local -> ../rc.local




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



Student Notebook

Figure 3-15. Configuring Services per Runlevel LX033.1

Notes:

The name and place of the symbolic link to the init.d script thus determines whether a service is started or stopped in a certain runlevel. But managing these scripts by hand is really tedious7. That’s why several tools exist for this.

The most common tool is chkconfig. It allows you to list the current configuration (with the --list option) and to turn individual services on and off.

Each of the service scripts includes information for chkconfig listing the default runlevels for which the service should be on or off, and the default priority. This leads to the following:

• chkconfig <service> off switches the service off for all runlevels • chkconfig <service> on switches the service on for the runlevels listed in the service

script. In most cases, this is runlevels 2 through 5.If you want chkconfig to work on other runlevels than the default 2 through 5, you can specify this with the --levels <levels> option.In addition to chkconfig, you can also use your distributions system management tool (redhat-config-services or yast) to manage these services.7 In some UNIX variants, you are actually required to do this.

Configuring Services per Runlevel

# chkconfig --list acpid 0:off 1:off 2:off 3:off 4:off 5:off 6:off atd 0:off 1:off 2:on 3:on 4:off 5:on 6:off ... # chkconfig acpid on # chkconfig --list acpid 0:off 1:off 2:on 3:on 4:off 5:on 6:off atd 0:off 1:off 2:on 3:on 4:off 5:on 6:off ...

Use chkconfig to create the appropriate K- and S- links for each service.




Uempty

Figure 3-16. Starting and Stopping Services Manually LX033.1

Notes:

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

You can call the script directly using its full pathname8, but that requires typing a lot of slashes and dots. Most distributions therefore have created some sort of shortcut which is faster to type:

• On a Red Hat or Fedora system, you can also use the service command. This does nothing more than calling the script for you, with the parameters you specified.

• On a SuSE system, a symbolic link with the name rc<service> is automatically created. This links to the init.d script.

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

Starting and Stopping Services Manually

Scripts in init.d directory can be used to start/stop services manually

On Red Hat/Fedora, the service command calls this scriptOn SuSE, rc<service> is a symlink to the init.d script

Default options: start, stop, status, restart

Other options may also be available

redhat,fedora# service atd restartStopping atd: [ OK ]Starting atd: [ OK ]

suse# rcatd restartShutting down service at daemon done

Starting service at daemon done



Student Notebook

Figure 3-17. Booting Linux in Single-User Mode LX033.1

Notes:

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

For single-user mode, you will need to specify the single option to the kernel when your system boots. The Linux kernel will then boot as normal, but init will only run /etc/rc.d/rc.sysinit or /etc/init.d/boot and then start a bash shell. It will not start all the normal services, so users can't log in over the network.

On a Red Hat/Fedora system, the single user mode will not even ask for a root password. This is done so that it can be used if you forgot your root password, and need to set a new one.

Obviously, in single user mode the system is not very useful, except for you. So after your system maintenance, you need to switch back to normal mode (runlevel 3 or 5). The safest course of action here is to do a full reboot (shutdown -r now).

Booting Linux in Single-User Mode

Single-User ModeNo networking (so no incoming hackers)No services being startedNo root password being asked (Fedora/Red Hat)

Very useful for system maintenance

To start from LILO: add "single" parameter to boot-prompt

To start from GRUB: add "single" to the "kernel" line of the corresponding menu entry

When finished:exit the shell to start the default runlevel, orshutdown -r now to reboot

LILOFor Linux, type linux, for Windows 95, type winBoot: linux single




Uempty

Figure 3-18. Shutting Down a Linux System LX033.1

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. Other alternatives are the commands reboot, halt and poweroff.

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.

Shutting Down a Linux System

DO NOT switch power off to shut down

Use shutdown command or Ctrl-Alt-DeleteWarns usersStops all running processesUnmounts filesystemsDoes an orderly shutdownReboots if necessary

Example:To reboot: shutdown -r now or rebootTo halt: shutdown -h now, halt or poweroff

Some Display Managers allow a user to perform a shutdown as well



Student Notebook


Notes:


1.

2.

Checkpoint

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

__________________________________________________

2. How would you select a graphical login screen (xdm, kdm or gdm)?

__________________________________________________




Uempty


Notes:

Unit Summary

The Linux startup flow is as follows:When power is switched on, the BIOS is loadedBIOS loads MBR and executes itMBR contains a boot loader (LILO or GRUB), which loads the Linux kernel and starts itThe boot loader may also load an initrd (Initial RAM disk)If an initrd is loaded, the kernel starts linuxrc to load modules and mount the root filesystem - otherwise the kernel can mount the root filesystem directlyThe first process started is initinit starts the rest of the processes

Booting in single user mode is done from the LILO prompt or by editing the GRUB description

Shutting down a Linux system is done with the shutdown command or with Ctrl-Alt-Delete



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, 2004 Unit 4. System Administration Tools 4-1

Student Notebook


Notes:

Unit Objectives


Discuss the main characteristics of system administration tools

List some distribution-specific administration tools

List some general-purpose administration tools




Uempty

Figure 4-2. System Administration Tools LX033.1

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:

System Administration Tools

Integrated tools for system management

Allow you to make configuration changes throughout the system from within one tool

Multiple interfaces possible:Text-basedX-basedWeb-based

To decide on a tool to use, consider:Type of interface requiredDistribution-specific of generic?Only base system configuration or application configuration too?Can the tool be extended easily?

Does the perfect tool exist yet?



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” LX033.1

Notes:

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

• authconfig: Authentication configuration

• lokkit: Firewall configuration

• mouseconfig: Mouse configuration

• netconf: Network configuration

• printconf: Printer configuration

• timeconfig: Timezone configuration

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

Red Hat "setup"

Menu-based front-end for various tools that are part of the text-based installation



Student Notebook

Figure 4-4. Red Hat “redhat-config-*”, Fedora “system-config-*” LX033.1

Notes:

Recently, Red Hat has begun creating graphical tools for system management, and has been phasing the text-based tools out. These tools are all separate programs, who each start with redhat-config-.

Fedora is based on Red Hat, and they have essentially copied these tools too. In Fedora Core 1, the tools were named the same (redhat-config-*) but in Fedora Core 2, the tools have been renamed to system-config-*. But in essence the tools are still the same.

The following tools exist in Red Hat. Obviously, the corresponding Fedora tools are named system-config-*:

redhat-config-bind DNS Server configuration

redhat-config-date Local time, timezone and time server configuration

redhat-config-httpd Web server configuration

redhat-config-keyboard Local keyboard configuration

redhat-config-kickstart Kickstart install configuration

Red Hat "redhat-config-*"Fedora "system-config-*"

redhat-config-time/system-config-time

redhat-config-network/

system-config-network

*-config-soundcard




Uempty
redhat-config-language Local language configuration
redhat-config-mouse Local mouse configuration

redhat-config-network Network settings configuration

redhat-config-nfs NFS Server configuration

redhat-config-packages RPM Package management

redhat-config-printer Printer configuration

redhat-config-proc /proc/sys configuration

redhat-config-rootpassword Change the root password

redhat-config-samba SMB Server configuration

redhat-config-securitylevel iptables firewall configuration

redhat-config-services System V services configuration

redhat-config-soundcard Soundcard detection and configuration

redhat-config-users User and Group management

redhat-config-xfree86 Graphical adapter, monitor detection and configuration

There is no front-end (like setup) to integrate these tools. Instead, they are integrated in the KDE and GNOME “start” button menus.



Student Notebook

Figure 4-5. SuSE “YaST” LX033.1

Notes:

YaST (Yet another Setup Tool) is the preferred system administration tool on a SuSE system. It is created by SuSE to work specifically with SuSE and does not work on any other distribution. It cannot be easily extended but, within its limitations, is quite powerful and works well.

If you start yast from the command line, you will get a text-based menu. This program offers the same functionality as the graphical yast. To start the graphical yast from the command line, type yast2.

SuSE "YaST"

Yet another Setup Tool




Uempty

Figure 4-6. Webmin LX033.1

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.

Webmin

http://www.webmin.com

Open Source initiative to create an independent configuration framework

BSD Open Source License

Uses modules to configure specific itemsModules can be created by anybody, using any license

Support for all major UNIX versions, not just Linux

Web-based interface only

Not installed on all distributions by defaultMay need to install yourself



Student Notebook

Figure 4-7. Webmin Installation LX033.1

Notes:

Webmin installation is really simple. On the Webmin Web site (http://www.webmin.com) you will find a single RPM file which works for all Linux distributions. Download and install it, and you’re done. Webmin is automatically started just like any other service.

Accessing webmin is done by launching a Web browser such as Netscape, Konqueror, Galeon, Mozilla, Lynx, Links, Opera and even Internet Explorer. Connect to the server, port 10000. You need to login with a username and password, and can then use any of the available modules to configure your system.

Webmin Installation

Download webmin-version.rpm from http://www.webmin.com

rpm -ivh webmin-version.rpm

Start web browser and connect to port 10000

Login with root password




Uempty

Figure 4-8. Webmin Screenshot LX033.1

Notes:

This is an example screenshot of Webmin.

Webmin Screenshot



Student Notebook


Notes:


1.

2.

Checkpoint

Name some distribution specific tools.______________________________________________

______________________________________________

______________________________________________

What are the steps to install Webmin?

______________________________________________

______________________________________________

______________________________________________

______________________________________________

______________________________________________

1)

2)




Uempty


Notes:

Unit Summary

System administration tools allow you to make system-wide configuration changes from a single tool

System administration tools typically support multiple interfaces such as text, X and Web

Most Linux distributions have their own system administration tools for base configuration

A general-purpose administration tools is Webmin



Student Notebook




Uempty
Unit 5. Packaging Tools

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



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


Accountability:

• Checkpoint Questions • Exercises


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

Student Notebook


Notes:

Unit Objectives


Describe the basic principles of RPM

Install RPM packages

Describe the RPM build process

Create simple SPEC files

Keep your system up to date




Uempty

Figure 5-2. RPM Package Manager (RPM) LX033.1

Notes:

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

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

• Management of source files

• Management of the build process

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

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

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

1 It used to be called the Red Hat Package Manager, but Red Hat changed its name to emphasis that other distributions use it too. Thenew official name is RPM Package Manager, and yes, that’s a self-referencing acronym (SRA), just like GNU.

RPM Package Manager (RPM)

Used for package managementManagement of source filesBuild processDistribution of binary files

Developed by Red Hat Software Inc, but GPLedOther Linux distributions use it too, for example, Fedora, SuSERequirement of LSB

.rpm files can be created by distributor or others

RPM database (/var/lib/rpm) contains database of installed packages

Can use PGP/GPG for package signing (verification of authenticity)



Student Notebook

Figure 5-3. RPM Philosophy LX033.1

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.

developer

application.tar.gz application.tar.gz SPEC file

patches sample config files

application.i386.rpm application.s390.rpmapplication.sparc.rpm

rpm -bb on sparc

rpm -bb on i386 rpm -bb on s390

distributor

application.src.rpm

RPM Philosophy

Note: RPM v4 uses rpmbuild instead of rpm for building RPMs




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



Student Notebook

Figure 5-4. RPM Installing, Freshening and Upgrading LX033.1

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

RPM Installing, Freshening and Upgrading

Installs, freshens or upgrades an RPMFreshen: only install if an older RPM was installedUpgrade: always install, but uninstall older RPM first

Basic syntax:rpm -i package-filename.rpm (install)rpm -F package-filename.rpm (freshen)rpm -U package-filename.rpm (upgrade)

Useful options:-v be verbose-h print 50 hash marks during installation

# rpm -ihv package-10.2-67.i386.rpmpackage: ##################################################




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

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

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

• --nodeps disables dependency checking.

Files in an RPM are marked as program, documentation or configuration files. When doing an upgrade or freshen, program and documentation files are automatically overwritten.

Configuration files are another matter altogether: Depending on the MD5 checksum of the original, actual and new configuration file, the configuration file may be left in place, may be overwritten, may be saved with an extension .rpmsave, or may be saved with an extension .rpmorig. In fact, rpm can distinguish between six different cases. For more information, see the Maximum RPM book.

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



Student Notebook

Figure 5-5. RPM Uninstalling LX033.1

Notes:

Uninstalling is even more simple than installing an RPM. Just specify the -e option and 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.

RPM Uninstalling

For uninstalling an RPM use the -e option

Options:--nodeps ignore any dependency breaks

# rpm -e kdelibs3error: removing these packages would break dependencies:

kdelibs3 >= 3.1 is needed by kdebase3-3.1.1-63 libDCOP.so.4 is needed by kdelibs3-cups-3.1.1-13...




Uempty

Figure 5-6. RPM Querying LX033.1

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.

RPM Querying

Queries the contents of an installed RPM

Basic syntax:rpm -q package-name

Options:-a query all installed packages-f <file> query package which owns file.-p <package-file> query package-file-i display package information-l display package files-s display state of all files-d display documentation files-c display configuration files



Student Notebook

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

• Do you want to know which package the dig program is in? Try rpm -qf `which dig` or rpm -qif `which dig`

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

• Need a lot of data to test a network connection? Try rpm -qila

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

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




Uempty

Figure 5-7. rpmdb (Red Hat/Fedora only) LX033.1

Notes:

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

Red Hat has solved this with the rpmdb database. What basically happens is that, when the distribution is created, all rpm files are queried for the capabilities they provide. This is stored in the rpmdb database, which is an rpm file itself and can be installed like any other rpm.

When the rpmdb database is present, you are able to invoke rpm with the --aid option. This option will make sure that rpm queries the rpmdb database, and thus will automatically install all packages that are needed to satisfy the dependencies. Do note that the directory where these packages can be found needs to be the current working directory. There is no option to supply the path where the packages are located (yet).

rpmdb (Red Hat/Fedora only)

rpmdb-distribution-version.rpm: Database of all capabilities that all RPMs in the distribution provide

Allows you to use the --aid option

Note: SuSE solves dependency conflicts through YaST

# rpm -iv rpmdb-redhat-7.0-0.20000830.i386.rpm rpmdb-redhat

# rpm -iv xboard-4.0.7-3.i386.rpm error: failed dependencies:chessprogram is needed by xboard-4.0.7-3# rpm -iv --aid xboard-4.0.7-3.i386.rpm chessprogram ###########################################xboard ###########################################



Student Notebook

SuSE does not solve this within the rpm program, but instead has integrated automatic dependency checking in yast.




Uempty

Figure 5-8. RPM Verifying LX033.1

Notes:

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

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

5 MD5 checksum. This is a very hard to fool checksum which checks whether the contents of a file have changed.

S File size. This checks whether the size of the file has changed. L Symbolic link. This verifies whether a certain symlink has changed. t File modification time. This checks whether the file modification timestamp

(mtime) has changed. d Device. This verifies whether the major and minor numbers of a device are still

intact. U User. Is the owner of the file still the same? G Group. Is the group of the file still the same? M Mode. Are permissions, SUID, SGID bits and the file type still the same?

RPM Verifying

Verifies the actual files with the original RPMsize SMD5 checksum 5permissions,type Mowner Ugroup Gmodification time Tsymbolic link Ldevice D

# rpm -V kdelibs3.M...... /opt/kde3/kpac_dhcp_helper.......T /opt/kde3/share/mimelnk/application/x-applix.desktop

a dot (.) means: test passed



Student Notebook

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.

Note that this cannot be used in place of more advance Intrusion Detection Systems such as tripwire: the /var/lib/rpm database is not encrypted or secured in another way, and any hacker worth his salt will not only change a file on disk, but will also modify the corresponding entry in /var/lib/rpm.




Uempty

Figure 5-9. RPM Signatures LX033.1

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 Web site. This public key needs to be added to your “keyring”, your database of public and secret keys in your home directory. This is done with the following command: rpm --import /mnt/cdrom/RPM-GPG-KEY. Note that some distributions (for instance, SuSE), perform this step automatically while installing.

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

RPM Signatures

RPM's can be signed by the distributor

To verify signature:Obtain public key of distributor

CD-ROMInternet

Add public key to keyring using gpg --import (RPM v3) or rpm --import (RPM v4)Verify package with rpm --checksig

Note: You can list the installed keys with "gpg --list-keys"

(RPM v3) or "rpm -qa gpg-pubkey*" (RPM v4)

redhat/fedora# rpm --import /mnt/cdrom/RPM-GPG-KEYsuse# gpg --import /mnt/cdrom/pubring.gpg

# rpm --checksig passwd-0.64.1-1.i386.rpmpasswd-0.64.1-1.i386 md5 gpg OK



Student Notebook

Figure 5-10. Creating RPMs LX033.1

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.

Creating RPMs

RPM creation process is governed by a SPEC file, which contains all information required to create source and binary RPMs on all architecturesPreamble Information about the packagePrep Preparation commands for the build

processSetup Commands to configure the softwareBuild Commands to build the softwareInstall Commands to install the softwareInstall script Scripts to be executed before or after the

package is installed/uninstalledVerify script Additional script to verify installationClean script Additional script to clean up after buildFile list List of all files that make up the binary RPMChangelog List of changes to the SPEC file

Used to create both the source and binary RPMSPEC file normally part of the source RPM




Uempty
• The clean script can be used to clean the build system after a built of the software.
• The file list is the list of files that are to be contained in the binary RPM.

Not all sections are required. For instance, if you want to create an RPM which just contains a number of shell scripts, you can leave the build section empty. Shell scripts do not need to be compiled, after all.

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



Student Notebook

Figure 5-11. Example Scenario: Hello, World! LX033.1

Notes:

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

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

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

Note that the “command” lines in a Makefile are indented with tabs, not with spaces.

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

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

hello-1.1/hello.c:

hello-1.1/Makefile:

Example Scenario: Hello, World!

#include <stdio.h>main(){ printf("Hello, World!\n");}

all: hello

hello: hello.c gcc -o hello hello.c

clean: rm -f hello

install: hello install -d $(DESTDIR)/usr/bin install -s -m 0755 -o root -g root hello $(DESTDIR)/usr/bin/hello

hello-1.1/README:(c) IBM Copyright 2004This program is licensed under the GPL.

This program prints the text "Hello, World!" on your screen. This is an excellent way to start your day - some people even consider it better than getting a random fortune cookie every morning!

To build, simply type makeTo install, simply type make install

# tar -ztvf hello-1.1.tar.gzhello-1.1/hello.chello-1.1/Makefilehello-1.1/README




Uempty

Figure 5-12. hello.spec Preamble Section LX033.1

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.

# # SPEC file for hello world program # Summary: Hello, World program Name: hello Version: 1.1 Release: 1 Copyright: GPL Group: Applications/Useless Source: hello-1.1.tar.gz Distribution: Useless Linux 1.1 Vendor: IBM Learning Services Packager: John Doe <[email protected]> BuildRoot: /var/tmp/hello-1.1

%description This program prints the text "Hello, World!" on your screen. This is an excellent way to start your day - some people even consider it better than getting a random fortune cookie every morning!

hello.spec Preamble Section



Student Notebook

Figure 5-13. hello.spec Prep, Build, Install and Files Section LX033.1

Notes:

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

The prep, setup, build and install sections contain the commands required to perform each of these steps.

• In the prep phase, you will typically execute commands to unpack the source package. If the source package is a simple .tar.gz file you don’t need to specify any commands at all: Just specifying %setup will do.

• In the build phase, the commands required to build the program are executed. In most cases, a package will come with a Makefile, which will perform all necessary commands for you.

• In the install phase, the commands required to install the program in its proper place are executed. Note that we’re installing our package relative to ${BUILDROOT}. This prevents conflicts with existing packages on our system.

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

%prep %setup %build make

%install make install DESTDIR=${RPM_BUILD_ROOT}

%files %doc README /usr/bin/hello

%changelog * Tue Mar 09 2004 - version 1.1 - John Doe <[email protected]> - Made to work under RPM v4 * Tue Jul 20 1999 - version 1.0 - John Doe <[email protected]> - Initial release

hello.spec Prep, Build, Install and Files Section




Uempty
is a documentation file which needs to be relocated to the documentation directory, usually /usr/share/doc/<packagename>.
The changelog section is not required but can be very useful. It contains a list of changes made to the SPEC file.



Student Notebook

Figure 5-14. RPM Build Process LX033.1

Notes:

In order to finally run the build process, we need to put all source files (hello-1.0.tar.gz) in /usr/src/redhat/SOURCES (on a Fedora or Red Hat system) or /usr/src/packages/SOURCES (on a SuSE system) and the SPEC file in /usr/src/{redhat|packages}/SPECS. We can then run the rpmbuild -b command, which will execute the build process. The letter after the “b” determines when the build process will stop:

rpm -bp Will only execute the %prep stage

rpm -bc Will execute %prep and %build

rpm -bi Will execute %prep, %build and %install

rpm -bb Will execute %prep, %build, %install and create a binary RPM

rpm -bs Will create a source RPM

rpm -ba Will create a binary and source RPM

RPM Build Process

RPM needs a special directory structure for building packages: /usr/src/redhat (Fedora,RedHat) or

/usr/src/packages (SuSE)

Put all SPEC files in /usr/src/{redhat|packages}/SPECS

Run rpmbuild -b<stage> <spec file>

# rpmbuild -ba /usr/src/redhat/SPECS/hello.spec... tons of messages ...Wrote /usr/src/redhat/RPMS/i386/hello-1.1-1.i386.rpmWrote /usr/src/redhat/SRPMS/hello.1.1-1.src.rpm




Uempty
Note that RPM version 3 and earlier used rpm instead of rpmbuild as the command to build rpms. The options are the same.


Student Notebook

Figure 5-15. After RPM Build Process LX033.1

Notes:

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

After RPM Build Process

Source RPM located in /usr/src/{redhat|packages}/SRPMS

Binary RPM located in /usr/src/{redhat|packages}/RPMS/<arch>

Can use binary RPM as any RPM:

# rpm -qip hello-1.1-1.i386.rpmName : hello Relocations: (not relocateable)....# rpm -qlp hello-1.1-1.i386.rpm/usr/bin/hello# rpm -ivh hello-1.1-1.i386.rpmhello ################################################### helloHello, World!# rpm -e hello




Uempty

Figure 5-16. Integrated Package Management LX033.1

Notes:

Each distribution comes with its own tools for integrated package management. Shown in the visual are redhat-config-packages (Red Hat) and yast (SuSE). Other tools also exist, notably gnorpm (from the GNOME project) and kpackage (from the KDE project).

redhat-config-packages and yast will automatically look for RPM files in the same place where the files came from during installation. If your RPM files are in another location, then you need to specify this manually. For redhat-config-packages, this is done with the -t option. For yast, this is integrated in one of its menus.

Integrated Package Management

redhat-config-packages yast (install and remove software)



Student Notebook

Figure 5-17. Keeping Up To Date (Fedora) LX033.1

Notes:

It is important to keep your system up to date. You can of course do this manually, by downloading the latest RPMs from your distributors Web site every now and then, and then install them using rpm -F. When managing multiple systems, this quickly will become tedious. Because of this, distributors have created additional programs to do this quickly.

Fedoras method of keeping your system up to date is yum (Yellowdog Updater, Modified). It’s a fairly simple tool that connects to the main fedora Web site, fedora.redhat.com, or any of its mirrors. (Mirrors can be configured in /etc/yum.conf.) The fedora.redhat.com site and all mirrors are supposed to run the yum-arch tool, which extracts all the header information from all RPMs and stores them in a headers/ directory. yum then downloads this header information and determines which packages need to be upgraded or are eligible for an install.

Depending on the command you supply to yum, it will install additional software, upgrade existing packages, remove packages or just give you a list of packages for which upgrades are available. Other commands are available too - see the manual page of yum.

Keeping Up To Date (Fedora)

Use yum to keep up to date or install additional software from fedora.redhat.com or mirrors

Mirrors can be added to /etc/yum.conf

yum will perform dependency checking automatically

Syntax:yum install package1 [package2] ...yum update [package1] [package2] ...yum check-updateyum remove package1 [package2]




Uempty

Figure 5-18. Keeping Up To Date (Red Hat) LX033.1

Notes:

Red Hat’s solution for keeping your systems up to date is called the “Red Hat Network”. For this to work, you need to create an account on http://rhn.redhat.com, and register your systems with up2date --register.

From that point on, you can update your systems in two ways:

• By running the up2date on the system itself. This will check which updates are available and, depending on the options given, download and install them automatically.

• By using the web interface at http://rhn.redhat.com. This allows you to apply updates to multiple systems simultaneously. Managing your systems from this Web site requires you to run the rhnsd (Red Hat Network Service Daemon) on each system.

The Red Hat Network is principally a commercial service, but free demo accounts are available.

Keeping Up To Date (Red Hat)

"Red Hat Network" (RHN)Free and commercial subscriptions availableCreate and manage account and systems on http://rhn.redhat.comRegister individual systems with up2date --registerUse up2date to bring system up to date, or use Web interface at http://rhn.redhat.com (requires rhnsd daemon running on system)



Student Notebook

Figure 5-19. Keeping Up To Date (SuSE) LX033.1

Notes:

SuSE uses a less advanced technique than Red Hat for keeping up to date. On a SuSE system, you will find the you program (Yast Online Update). This program can connect to any SuSE mirror (including internal mirrors you host yourself), and download and install any available patch from there.

With you, there is no way to easily manage tens or hundreds of servers like with RHN.

Keeping Up To Date (SuSE)

you (Yast Online Update): Program that downloads/installs patches from any SuSE mirror




Uempty

Figure 5-20. Debian Package Management LX033.1

Notes:

Debian and Debian-based distributions (such as Corel Linux) do not use RPM as their package format, but use Debian packages instead. These can be recognized by their .deb extension.

Debian packages have a different internal layout and as a consequence require different tools too. The most important tool is dpkg, which can be compared to rpm. It is used to install, deinstall and query packages. Debian also has a number of front-ends, including apt-get and dselect. apt-get is comparable to up2date: It allows the user to automatically download packages and upgrade a system over the internet. dselect is comparable to GnoRPM or kpackage: it offers a menu-driven front-end for dpkg.

The dpkg configuration file is /etc/dpkg/dpkg.cfg, and information on packages installed by dpkg can be found in /var/lib/dpkg/*. The apt-get configuration file can be found in /etc/apt/apt.conf, and the list of servers that it tries to contact is in /etc/apt/sources.list.

Debian package creators use the same philosophy of “pristine sources”, source packages and so forth. Instead of having a single SPEC file though, Debian uses two different descriptor files. debian/control contains the information about the package, such as

Debian Package Management

Debian uses its own package format and management tools

RPM Debian

Filenames hello-1.0-1.src.rpmhello-1.0-1.i386.rpm

hello_1.0-1.tar.gzhello_1.0-1.deb

InstallUpgradeDeinstallQuery

rpm -irpm -U, rpm -Frpm -erpm -q

dpkg -idpkg -idpkg -rdpkg -p

Front-ends redhat-config-packagesyast, up2date, you, yum

apt-getdselect

Package descriptor file hello.spec hello/debian/controlhello/debian/rules

Build a package {rpm|rpmbuild} -b dpkg -b, dpkg-buildpackage

To convert between DEB and RPM packages use Alien



Student Notebook

version, description and so forth, and debian/rules is a Makefile-like file containing the actual build instructions. To build a package, use dpkg -b, which really is a front-end for dpkg-buildpackage. Also useful are the unpack command, for unpacking a Debian archive, and dpkg-reconfigure, for reconfiguring a Debian package.

If you need to install RPMs on a Debian system or vice versa, you can use the Alien package to convert between the two.




Uempty


Notes:


1.

2.

Checkpoint

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)



Student Notebook


Notes:

Unit Summary

RPM is a versatile tool for package management

An RPM file can be a source RPM or binary RPM

A source RPM contains the pristine package source, patches, sample configuration files and a SPEC file

The SPEC file contains details about the build process

A binary RPM contains the compiled code and is specific for an architecture

Several integrated package management tools exist

Each distribution has its own solution for keeping up to date with patches

Debian has its own package format: .deb

You can convert between .rpm and .deb using Alien




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 and/or Xorg • Start and stop X • Describe the function of the window manager • Use X over a network


Accountability:



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

Student Notebook


Notes:

Unit Objectives


Describe the basic architecture of the X Window System

Configure XFree86 and/or Xorg

Start and stop X

Describe the function of the window manager

Use X over a network




Uempty

Figure 6-2. X Window System LX033.1

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.

X Window System

Graphical User Interface of UNIX

Initially developed at MIT

Currently licensed by the X Consortium, Inc.

In Linux implemented as a separate program that runs in user space

Uses client-server architecture



Student Notebook

Figure 6-3. X - Client/Server Architecture LX033.1

Notes:

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

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

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

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

X - Client/Server Architecture

X Server

Window manager Client-App 1 Client-App n

The X Station

Host-1

Host-zClient-App z




Uempty
• xedit, a GUI-based editor
and many, many more.

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



Student Notebook

Figure 6-4. Examples of X Stations LX033.1

Notes:

There are several X stations possible:

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

• UNIX/Linux stations with a graphical display can run an X server as a separate program. In most cases, the X server will grab the entire graphical screen.On most UNIX/Linux systems, the X clients and X server run on the same system, communicating with each other via the TCP/IP loopback interface or via a UNIX socket1. This makes it possible to use X as a standalone solution.

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

• Xnest is an X client that implements an X server. In other words: it is an X server in a window. This is useful for testing.

1 A special file (type s) in a UNIX/Linux filesystem which makes TCP/IP-like communications between two processes possible. 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.

Examples of X Stations

Hardware X StationsX Server program stored in ROM chip

UNIX/LinuxX Server implemented as a separate program that uses the entire graphical screen to display X clientsUNIX/Linux can run the X Clients and X Server program on the same system (Stand-alone solution)

MS-WindowsX Server implemented as a separate program that uses the Windows GUI to display X clients

For example, Hummingbird eXceed and others

XnestX Server implemented as an X Client




Uempty

Figure 6-5. X Servers in Linux LX033.1

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.

Around April 2004 the XFree86 organization surprised the world by changing to a new license for their XFree86 4.4 release. This license was generally held to be incompatible with the GPL and Open Source and as a result, most distributions have decided not to include XFree86 4.4 in their distributions. A new project, X.org, was formed which continued development from XFree86 4.3 (actually, 4.4RC2), using the old license. Most

X Servers in Linux

Default X server in Linux: XFree86Open Sourcehttp://www.xfree86.org

Other X servers are available for LinuxMetro-X: http://www.metrolink.comXi Graphics: http://www.xig.com

Note: Due to a license change in XFree86 version 4.4,

most distributions have decided not to include it anymore

in their future releases. The replacement X server is

Xorg (http://x.org), which is derived from XFree86 4.3.



Student Notebook

distributions that appeared after April 2004 (so far, Fedora Core 2) are using X.org instead of XFree86. For more information, visit http://lwn.net/Articles/79443.




Uempty

Figure 6-6. XFree86/Xorg LX033.1

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.

XFree86/Xorg

XFree86 version 3.x (being phased out): Different binaries available for different brands of graphical adapters

XF86_Mono (Monochrome adapters)XF86_VGA16 (Standard 16-bit VGA adapters)XF86_SVGA (Super VGA adapters)XF86_S3 (Adapters with S3 chip)XF86_P9000 (Adapters with Weitek P9000 chip)...and so forth

XFree86 version 4.x: One binary, that dynamically loads modules to support different graphical adapters

Xorg version 6.7: Based on XFree86 4.3



Student Notebook

Xorg 6.7 is based on XFree86 4.3 (actually, 4.4RC2), with very few changes. Their version numbering scheme is derived from the version number of the X standard itself.




Uempty

Figure 6-7. XFree86/Xorg Configuration LX033.1

Notes:

On every system which will run the XFree86 or Xorg X server, the configuration file /etc/X11/XF86Config or /etc/X11/xorg.conf 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/xorg.conf may damage your monitor! Don't say you weren't warned!2

Most monitors today are Multi-Sync monitors, meaning that they accept a wide range of driving frequencies, and are protected against driving frequencies that would damage it. One exception is an LCD panel, which in a lot of cases only accepts a refresh rate of exactly 60 Hz. With all other refresh rates, the LCD panel simply will not show anything. Because of this, most configuration tools (see below) include a description for a “Generic LCD panel”, for each of the most commonly used resolutions. If you’ve got an LCD panel, use one of these descriptions.2 This is no joke. Multiple fellow students have had this happen to them.

XFree86/Xorg Configuration

Can only be done as root

You have to configure XFree86/Xorg for yourGraphical adapter, MonitorMouseKeyboard

Stored in /etc/X11/XF86Config or /etc/X11/xorg.conf

Configuration aids to create this fileXFree86 -configure Integrated in XFree86Xorg -configure Integrated in Xorgredhat-config-xfree86 Red Hat toolsystem-config-desktop Fedora toolSaX2, YaST SuSE tools



Student Notebook

It used to be that you had to set up this file all by yourself, but nowadays there are several programs available that can help you out in about 99% of the situations.




Uempty

Figure 6-8. Starting X LX033.1

Notes:

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

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

What your favorite window manager is, is determined by reading the configuration files in your home directory. Each distribution has a different setup for determining the favorite window manager, but fortunately it’s not really relevant how each distribution does this: Most Linux systems will employ a display manager (covered in the next visual) which allows you to choose your window manager.

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

Starting X

To start XFree86 and your favorite window manager use startx

Will start XFree86 on a free virtual display (usually number 7)Will start your favorite window managerTo start a second X session, use startx -- :1

$ startx...



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-9. Stopping X LX033.1

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.

Stopping X

Use menu screens from your window managerStops processes then stops X serverUsually saves current desktop layout

If nothing works, use Ctrl-Alt-BackspaceStops X server directly, other processes lose connection and dieCan be disabled in X server configuration file



Student Notebook

Figure 6-10. Session Managers LX033.1

Notes:

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

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

The session manager is started from init in runlevel 5 (Red Hat/Fedora) or with a regular System V service script in /etc/init.d (SuSE).

Session Managers

Manage X-SessionsStart an X serverOffer a graphical loginAuthenticate a userStart the user's window mgrWait until user logs outRestart X serverOffer a graphical login screen for the next userAnd so forth

Different session managers:xdmkdmgdm

Started from init in runlevel 5 (Red Hat/Fedora) or as a regular System V service (SuSE)




Uempty

Figure 6-11. X Networked LX033.1

Notes:

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

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

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

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

X Networked

Connections between different X Clients and the X Server are all TCP/IP connections

Can be run over a TCP/IP network

Three levels:Individual applicationsWhole SessionSession Chooser



Student Notebook

Figure 6-12. X Applications Networked LX033.1

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).

X Applications Networked

Application Host

(hostname host)

X Station

(hostname xstation)TCP/IPNetwork

XFree86xeyes

Window Mgr




Uempty

Figure 6-13. Applications Over TCP/IP LX033.1

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 contact3, and <displaynumber> the screen to use.4

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. 3 One system might be running multiple servers, although this is rare.4 One X server may handle multiple screens simultaneously on so-called dual-headed systems.

Applications Over TCP/IP

On the host (where X clients run):

Displaying applications on a remote host is by default disabled for security reasons

To enable this, two methods possible: xauth and xhost

xauth: Uses cryptographic authentication method

xhost: Allows all connections from a given host

host$ xterm -display xstation:0.0

or:host$ export DISPLAY=xstation:0.0host$ xterm

xstation$ xauth extract xauthfile xstation:0.0host$ xauth merge xauthfile

xstation$ xhost +host



Student Notebook

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

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

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

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

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

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

xauth extract xauthfile client:0.0

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

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

xauth merge xauthfile

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

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

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

The smartest way however is to use ssh, since this protocol has the ability to automatically transfer the xauth record to the host, and set the $DISPLAY variable so that all data is transmitted via a secure session. This means that the only thing you need to do is:

ssh host xeyes

rsh and ssh are both covered in the LX07 “Linux Network Administration I”

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




Uempty

Figure 6-14. X Sessions Networked LX033.1

Notes:

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

X Sessions Networked

Host X StationTCP/IPNetwork

XFree86xeyes

Window Mgr



Student Notebook

Figure 6-15. X Sessions Over TCP/IP LX033.1

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.

X Sessions Over TCP/IP

On most Linux distributions, X sessions are normally disabled for security reasons. To enable:

xdm:Edit Xaccess and xdm-config

kdm:Edit kdmrc and Xaccess

gdm:Edit gdm.conf

On the X Station:X -query <hostname>




Uempty
For kdm, there are again two things you need to do:
• You need to edit /etc/kde/kdm/Xaccess (Red Hat/Fedora) or /opt/kde3/share/config/kdm/Xaccess (SuSE) so that it allows any host to get a login window. The line that specifies this is usually already there, but is commented out. So you just need to uncomment this line.

• You need to edit /etc/kde/kdm/kdmrc (Red Hat/Fedora) or /opt/kde3/share/config/kdm/kdmrc and enable xdmcp direct and indirect requests.

For gdm, the procedure is again different. Here, you only need to edit /etc/X11/gdm/gdm.conf (Red Hat/Fedora) or /etc/opt/gnome/gdm/gdm.conf (SuSE) to enable xdmcp direct and indirect requests.

When you're done setting up your display manager, you need to restart it. This is for instance done by switching to runlevel 3, and then back to 5 (init 3; sleep 10; init 5).

Then, you need to start the X server on the X station. Since the only program running here is XFree86, we can start it with the X command. We only need to tell it that it has to query the display manager to get a login prompt and a session. So the complete command becomes X -query <hostname>



Student Notebook

Figure 6-16. Chooser Sessions LX033.1

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>

Chooser Sessions

If enabled, Display Managers do broadcasts to discover each other

An "indirect" query shows a list of all Display Managers willing to manage your session

To start an indirect session:X -indirect <hostname>




Uempty

Figure 6-17. Font Server LX033.1

Notes:

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

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

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

SuSE, by default, does not use a font server. Red Hat and Fedora configure and use a font server on the local system by default, which is accessible through a UNIX socket only.

Font Server

All fonts needed should be available to the X serverThus, on any client workstation

To save disk space, XFree86 can work with a font serverCentral server, accessed via:

TCP port 7100UNIX socket /tmp/.font-unix/fs7100

Configuration file /etc/X11/fs/config

To use a font server, specify in XF86Config or XF86Config-4:Section "Files" FontPath "tcp/hostname:7100" FontPath "unix/:7100"EndSection

Red Hat/Fedora use a font server on localhost by default



Student Notebook

The specification in /etc/X11/XF86Config on a Red Hat/Fedora system will thus look like this:

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

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

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

Depending on your distribution, you also might need to enable the font server to serve network requests. Some distributions disable this by default in the xfs configuration file /usr/X11R6/lib/X11/fs/config.




Uempty


Notes:


1.

2.

3.

Checkpoint

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:

Unit Summary

Architecture of the X Window System

Configure XFree86

Start and stop X

Window manager

Use X over a network




Uempty
Unit 7. Kernel Compilation and Configuration

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



• Describe why kernel compilation is sometimes desirable • Install kernel sources

- From distribution CD-ROM - From Internet

• Patch the kernel • Compile the kernel • Install the kernel • Configure the kernel and the kernel modules


Accountability:



© Copyright IBM Corp. 2001, 2004 Unit 7. Kernel Compilation and Configuration 7-1

Student Notebook


Notes:

Unit Objectives


Describe why kernel compilation is sometimes desirable

Install kernel sourcesFrom distribution CD-ROMFrom Internet

Patch the kernel

Compile the kernel

Install the kernel

Configure the kernel and the kernel modules




Uempty

Figure 7-2. Why Kernel Compilation LX033.1

Notes:

After installation of a Linux system the kernel from the distribution is installed, so kernel compilation is usually not necessary. There is actually only one situation in which you will be forced to recompile your kernel: if you have hardware which is not supported in the standard distribution kernel.

However, most people choose to recompile the kernel even when support for all their hardware is already available. The reason for this is that support for devices not present in your computer wastes valuable kernel memory, and increases boot time. People usually prefer a “lean and mean” kernel.

Of course, there may be other compelling reasons for a kernel compilation, such as upgrade to a newer kernel version or when using experimental or development kernels. But for most people, the main reason for compiling a new kernel is fun!

Note: Most commercial distributions will only give you support if you run their unmodified software. This means that a system running a home-compiled kernel will generally not receive support, unless you can boot it into the original kernel, and show that the problem exists there too. So always keep the original kernel around!

Standard distribution kernel may not be adequateSpecific hardware not supportedToo much hardware support

Consumes memorySystem startup takes longer

Upgrade to newer version

Experimental/development kernel

Fun!

Why Kernel Compilation



Student Notebook

Figure 7-3. Compilation Steps LX033.1

Notes:

There are several steps in kernel compilation. First, you have to install the kernel source, usually in /usr/src/linux-version. These sources can be installed from the distribution disks, which contain the source to the kernel supplied by the distribution, or from the Internet (for instance at www.linux.org or www.kernel.org).

The next step is configuring the kernel by answering a lot of questions about whether support for a certain adapter or device should be compiled in or not.

After this, you need to clean the kernel source tree of any old temporary files, and need to recreate dependency information.

Then the kernel compilation process can begin. This involves compiling a new kernel image and compiling and installing the kernel modules.

After compilation, your boot loader will have to be configured so that it will boot this kernel instead of the standard kernel. After that, reboot your system and it will boot the new kernel.

Compilation Steps

1. Install kernel sourceFrom distribution CD-ROMFrom Internet

2. Create configuration file .config

3. Remove old temporary files

4. Discover dependency information

5. Compile kernel image and kernel modules

6. Install kernel image and kernel modules

7. Configure Boot Loader

8. Reboot system




Uempty

Figure 7-4. Installing Kernel Source LX033.1

Notes:

Kernel sources can be obtained from a variety of sources. They are available on the distribution CD-ROM as kernel-source-version.i386.rpm. Installation will typically be done in /usr/src/linux-version.

You can also download the kernel from the Internet, for instance, at www.linux.org or www.kernel.org. These kernel sources are gzipped or bzipped tarfiles (.tar.gz or .tar.bz2). You can uncompress and untar them using tar -xzvf linux-version.tar.gz or tar -xjvf linux-version.tar.bz2. These tar files unpack in the current directory, so make sure your working directory is /usr/src (or, for instance, /usr/local/src or your home directory).

In order to be absolutely sure that no configuration options were preserved from the person who created the rpm or .tar.gz file, run the make mrproper command in the kernel directory (/usr/src/linux-version). This will ensure that all configuration information is deleted.

Installing Kernel Source

From distribution: use rpm to install the kernel sources package

From Internet: Download linux-version.tar.gz or linux-version.tar.bz2 and unpack in /usr/src

After installation, clean the tree really well to remove all configurations changes made by the distribution builder

# rpm -ivh kernel-source-version.rpm

# cd /usr/src# tar -zxvf /root/linux-version.tar.gz# tar -jxvf /root/linux-version.tar.bz2

# cd /usr/src/linux-version# make mrproper



Student Notebook

Figure 7-5. Patching the Kernel LX033.1

Notes:

When kernel developers modify the kernel source code, for instance to fix bugs, add support for new hardware or change functionality, they typically do not publish the updated code, but publish their updates in the form of patch files. A patch file only lists the differences between the old and the new code, but does not contain any unmodified code1. This has a number of advantages:

• Other kernel developers can look at the patch file and immediately see what changes were made.

• A single patch file can contain changes that were made to different files. This makes it easier to apply an atomic change that impacts multiple files.

• Since patch files only contain the modified code, multiple developers can simultaneously release changes to a single file, as long as their individual changes don’t overlap. In almost all cases, the resulting patch files can be applied in any order, independent of each other.

1 Not entirely true. A patch file typically contains the few lines of unmodified code that surrounds the modified code. This means that ifthe line numbers don’t match exactly, the patch program can find the correct lines to patch by looking at this unmodified “context” code.

Patching the Kernel

Changes to the kernel are typically distributed as "patches"

A patch lists only the difference between the old and the new version of the code; does not contain unmodified code

Patches are generated with the diff command

Use the patch command to apply a patch to your sourcetree

Use the -R option to remove a previous applied patch

# patch -p0 < linux-dummy-patchpatching file Makefile...

# diff -u oldfile.c newfile.c > /tmp/file.diff# diff -urN olddirtree newdirdtree > /tmp/tree.diff




Uempty
• A patch file is generally much smaller than the updated code, because the unmodified code is not included.
As an example, the compressed Linux kernel code for 2.4.19 is about 26 MB, while the patch to go from 2.4.18 to 2.4.19 is only about 4.5 MB.

Linux kernel developers are required to submit their patches in “unified diff” format. This is generated with the diff -u command. To create a patch of a single file, use the command diff -u oldfile newfile > /tmp/patch. To create a patch of a whole directory tree, use the command diff -urN oldtree newtree > /tmp/patch.

When creating a patch of a whole Linux kernel tree, make sure that the tree is clean of any local configuration files and object files (make mrproper). Alternatively, use the -X dontdiff option to diff, which forces diff to ignore all files listed in the “dontdiff” file. This file is kept up to date by the kernel developers.

To apply a patch, use the command patch -p0 < /tmp/patch. The -p0 option is used to ignore the base directory of the tree. This ensures that you can apply a patch in /usr/src/linux which was originally created from a tree in /root/linux, for instance.

It is also possible to remove or reverse-apply a patch. This is done using the -R option.

When patching files, patch might not always be able to find the piece of code to modify, for instance because it has moved, or modified by another patch. In this case, patch creates “reject files”, with the *.rej extension. These files are again in patch format, so it is usually easy to modify these files (for instance, correct the line numbers) and run them through patch again.



Student Notebook

Figure 7-6. Configuring the Kernel Compile LX033.1

Notes:

Before you start the compilation process you will have to determine what support should be compiled in. For this, you will need to know your hardware, and you will need to know what function your system will fulfill. For instance, your system can only act as a firewall if firewall support is compiled into the kernel.

To configure your kernel, run the make config command in the /usr/src/linux-version directory. You will be presented a lot of questions2. For most of the questions, help is available by entering the question mark. If you are unsure, accept the default.

Recently, two more ways of configuring the kernel configuration parameters were added: make menuconfig and make xconfig. Both will offer you a menu-based structure to set the parameters, instead of having to answer all questions sequentially. That is especially convenient if you made errors while answering.

All configuration options are stored in a single flat file called .config in the directory /usr/src/linux-version.

2 make config for kernel version 2.4.18 asks about 1200 questions, when executed on the IA-32 architecture!

Configuring the Kernel Compile

Configure all kernel compilation options

Configuration stored in .config file

Editing .config is hard...

Use the make utility instead:make config (command line)make menuconfig (ncurses based - much easier)make xconfig (Tcl/Tk based GUI)




Uempty
If you already have a working .config file, for instance because you already compiled a previous version of the Linux kernel, or because your distribution includes the .config file with which the distributor compiled your current kernel, you can import this .config file into your new kernel configuration by running make oldconfig. This will read your old configuration file and will only ask you the questions that are new with this kernel.


Student Notebook

Figure 7-7. Kernel Modules LX033.1

Notes:

Certain kernel parts may be configured and compiled as modules. This means that they are not part of the kernel image, bzImage, but are available on disk as a separate file.

There are several advantages to this scheme:

• The modules do not consume memory until they are needed

• System boot is faster, because there is less loading to do

However, there is also a disadvantage: the loading of a module costs some time. This may be a burden for often-used hardware.

Modules can only be loaded after the system is fully booted up. Therefore, if you have any hardware which is already needed in the boot process, compile it into the kernel, and not as separate modules.

You can also create an “initial root disk”, which is a special file (actually, a filesystem in a file) which contains the necessary modules, typically your SCSI and/or RAID modules. This file is loaded into memory by LILO or GRUB. The kernel then loads the modules off this

Kernel Modules

Certain kernel parts may be configured as modules

Separate files in /lib/modules/<KERNELVERSION>, not in kernel image

Module advantages:Do not consume memory unless actually usedDrivers can be reconfigured during uptimeSystem boot is faster

Module disadvantages:Loading costs a little time

Use modules only for hardware which is not needed directly at system boot, or create an Initial RAM Disk (initrd) containing the needed modules




Uempty
initial root disk, and then mounts the proper root disk. To create an initial root disk, use the mkinitrd (Red Hat) or mk_initrd (SuSE) command.
Note: The initial root disk is loaded into a RAM disk. Because of this, the name “Initial RAM disk” is used as well.

Modules are stored in /lib/modules/version, where the version number is determined in /usr/src/linux/Makefile. If you are working with multiple kernel images from the same kernel version, it is a good idea to use the EXTRAVERSION directive in the Makefile to distinguish between the different images and module sets.



Student Notebook

Figure 7-8. Compiling the Kernel LX033.1

Notes:

After configuration you will want to clean up the installation tree with make clean. This means removing all the old temporary files (*.o, *.a) and kernel images.

After that, re-create the dependency files with make dep. This will take a few minutes.

Then it is time to compile the kernel itself. Do this with the make bzImage command.3 The compilation process will take somewhere between 5 and 60 minutes, depending on the speed of your processor and the amount of code to compile. It creates the compressed kernel image (called bzImage) in /usr/src/linux-version/arch/i386/boot.

3 Technically, there are three ways of compiling the kernel image, which differ in the amount of compression applied, and where 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 becomesfar too big to handle. It is not used anymore on Intel systems, but can still be used on other architectures (PowerPC, S/390, ...)make zImage applies compression to the kernel image and prepends a decompress program to it. When the kernel is loaded in memoryand executed, the decompress program first decompresses the kernel and loads it below the 1 MB memory limit. It then starts the kernelproper. 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 thekernel 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.

Compiling the Kernel

Most important targets:

make cleanCleans up old .o, .a files, and so forth

make depChecks dependencies

make bzImageCompiles kernelMay take 5-60 minutesCreates kernel image (bzImage) in /usr/src/linux-<VERSION>/arch/<CPUTYPE>/boot

make modulesCompiles modulesMay take 2-60 minutes

Can be combined: make clean dep bzImage modules




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 7-9. Installing the Kernel LX033.1

Notes:

To install the kernel, it needs to be copied to /boot. For convenience, rename the kernel image so that it includes the full version number (including the EXTRAVERSION). This will save a lot of trouble later, if you compile more kernels.

It is a good idea also to copy and rename the System.map and .config files:

• The System.map file is a file containing the location of all kernel symbols (global variables, subroutines) within the kernel. This information is vital for kernel developers in case of a kernel panic to determine at what location the kernel panicked.

The System.map file is also occasionally used by the kernel logger (klogd) and by the ps command.

• The .config file is never used by any program on the system, but is useful for later reference.

To install the modules, run the make modules_install command. This will automatically install all modules in /lib/modules/version.

Installing the Kernel

Copy kernel image to /bootcp arch/i386/boot/bzImage /boot/vmlinuz-version

Copy System.map and .config to /boot for later referencecp System.map /boot/System.map-versioncp .config /boot/Config-version

Install modulesmake modules_install

Create Initial RAM Disk if neededRed Hat: mkinitrd -f /boot/initrd-version.img versionSuSE: mk_initrd -k vmlinuz-version -i initrd-version

Configure LILO or GRUB to include new kernel




Uempty
If you need to load modules to access your root filesystem, for instance because your root filesystem is on a RAID, LVM or SCSI volume, or if your root filesystem is formatted as ext3, ReiserFS or JFS, then you need an initial root disk4. This initrd is created with the mkinitrd (Red Hat) or mk_initrd (SuSE) command, and should also be stored in /boot.
The last step is configuring LILO or GRUB so that the new kernel is included in the configuration. When using LILO, don’t forget to run the lilo program afterwards.

4 Sometimes also called an Initial RAM Disk.



Student Notebook

Figure 7-10. Reboot System and Start New Kernel LX033.1

Notes:

After the kernel is compiled and your boot loader is reconfigured to boot the new kernel image, you can try it out. Reboot your system and boot with the new kernel image. Watch the screen carefully for any error messages. If needed, you can scroll up with Shift-PgUp. You can also execute the dmesg command to retrieve the messages. Most messages will also be written to /var/log/messages, so you can always retrieve them later.

If no errors occur, you can log in and start working.

Reboot System and Start New Kernel

Ctrl-Alt-Delete or shutdown -r now

Select new kernel in boot loader

Check kernel boot messages for errorsWith Shift-PgUpWith dmesgIn /var/log/messages

Check functionality of kernelAmount of memory detectedAll devices working properly?Performance?




Uempty

Figure 7-11. Loading Modules LX033.1

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.

Loading Modules

Modules can be loaded manuallyinsmod loads a single modulelsmod lists all loaded modulesrmmod removes a single moduledepmod determines module dependencies

(in: /lib/modules/version/modules.dep)modprobe loads a module and modules it depends onmodinfo displays information about a module

Modules are loaded dynamically when the kernel discovers it needs to, based on information in /etc/modules.conf

More information in /usr/src/linux/Documentation/modules.txt



Student Notebook

A fairly new command is modinfo. This command displays information about the module. What information is displayed depends on the options given:

• -a displays the author • -d displays the description • -p displays all possible parameters

Unfortunately, most authors of Linux kernel modules have not yet included this information in the module itself, so don't be surprised if modinfo yields less information than you had hoped for. This is supposed to improve in the future.

Dynamic loading of modules is also done: when the kernel finds out that it needs a module to activate support for a device, it will load the module automatically. For the 2.0 series of kernels, this was done with kerneld, a user-space daemon which took care of it. With the 2.2 series of kernels and higher, this is completely integrated in the kernel itself. In order to know what module is needed for which device, the /etc/modules.conf file is used. This file will be covered in a few pages.




Uempty

Figure 7-12. Configuring the Kernel LX033.1

Notes:

The .config file only configures the kernel compilation process, and is not used afterwards. But once the kernel has been installed, we might need to do more configuration. This typically pertains to the hardware environment the kernel has to run in, and various software options within the kernel.

This configuration can take place in three different stages:

• When the kernel boots, through kernel boot parameters

• When modules are loaded, through the module loader interface

• Through the /proc/sys mechanism, when the kernel and modules are running

Configuring the Kernel

Certain kernel configuration options can be set after kernel compile

Some possibilities for configuration:When kernel image boots

Amount of Memory usedRoot filesystem to mount

When modules are loadedHardware present, hardware settings

Through /proc/sys mechanismSoftware functions, such as IP forwarding



Student Notebook

Figure 7-13. Sidestep: Device Configuration LX033.1

Notes:

Every device on the system needs to communicate with other devices, particularly with the CPU and the memory. On an Intel platform, this is done by way of an IRQ (Interrupt ReQuest) and an I/O (Input/Output) address:

When a device, such as a network adapter card, wants to communicate with the CPU, it stores the data it wants to communicate at a special memory-mapped I/O address5. It then signals the CPU that data is waiting by sending it an interrupt via the IRQ line. The CPU interrupts whatever it is doing (hence the name interrupt), copies the data from the I/O address to its proper location and then continues its regular work.

The same mechanism is used when the CPU wants to communicate with the adapter card.

High-bandwidth devices such as disk controllers can also benefit from Direct Memory Access: using a special DMA channel they get access to a special, reserved memory area. This memory area is typically far larger than the memory-mapped I/O area and thus requires far fewer interrupts to transfer large amounts of data.

5 A memory-mapped I/O address means that the memory on the adapter card is mapped into the main memory region. If the CPUaccesses this memory area, it is not handled by the main memory, but by the memory on the adapter card.

Sidestep: Device Configuration

Every device needs an IRQ line and an I/O address to communicate

Some devices may benefit from DMA

The Linux kernel is capable of configuring Plug 'n' Play devices (PCI and ISA PnP) automatically

Non-PnP devices need to be configured manually through jumpers, dip-switches or NVRAM settings

If you've got multiple, identical devices, use IRQ and I/O addresses to tell them apart




Uempty
It used to be so that each and every device needed its own IRQ and I/O address. This effectively limited the number of devices in a PC to about five to eight or so. Today, under certain conditions, certain devices may share an IRQ. But still, all these IRQs, I/O addresses and DMA channels need to be configured properly.
In the early days of the PC, when all PCs used ISA buses and devices, you had to configure all devices manually. This was typically done using dip switches, jumpers or special configuration programs. The PCI standard changed all this, by introducing a technique called “Plug ‘n’ Play”, or PnP for short. PnP is a mechanism whereby every device can identify itself to the BIOS or the Operating System with a manufacturer ID, a device ID and a list of its possible configurations. Depending on the BIOS setting “Plug ‘n’ Play OS [y/n]”, the BIOS or the OS will then configure all devices so that they don’t conflict with each other.

PnP has been ported to ISA devices as well. This technique is called ISAPnP. However, since a BIOS generally can’t configure these devices, this had to be left to the Operating System.

Initially, the Linux kernel was not capable of handling PnP devices. This was handled in two ways:

• PCI devices (which are by definition PnP) were configured by the BIOS. This was achieved by setting the BIOS parameter “PnP OS” to No.

• ISAPnP devices were handled by two user-space tools: pnpdump would create a file /etc/isapnp.conf which contained all devices and all their possible settings. By uncommenting the correct IRQ and I/O statement in the file you could create a non-conflicting situation manually. When the system booted, the program isapnp was called automatically, typically from rc.sysinit. isapnp would then configure all ISAPnP devices according to the configuration in /etc/isapnp.conf.

With the 2.4 kernel however, this scheme is obsolete. The 2.4 kernel contains full support for PnP devices, including ISAPnP.



Student Notebook

Figure 7-14. Configuring the Kernel at Boot Time LX033.1

Notes:

The first way of configuring the kernel is when the kernel itself boots. Just like any other program, the kernel accepts arguments to its “command line”. However, since the command line of the kernel can’t be accessed directly, you need to work with your boot loader to achieve this:

• For LILO, kernel arguments can be added to the “append” statement. An /etc/lilo.conf stanza for the kernel then looks like this:

image=/boot/bzImage-2.4.18-Test label=new root=/dev/hda3 read-only append="mem=128M"

In this case, mem=128M will be used as one of the kernel arguments6.

6 In fact, the other two arguments are root=/dev/hda3 and ro, so we could have said append="root=/dev/hda3 ro mem=128M" andthen leave out the separate root=/dev/hda3 and read-only lines.

Configuring the Kernel at Boot Time

Done by adding arguments to the kernel line in the boot manager

LILO: use "append" statementGRUB: add to "kernel" line

Examples:mem=128M Identify amount of memory to kernelroot=/dev/hda3 Identify root FS to mountro Mount root FS readonlyinit=/sbin/init First program to runhdc=ide-scsi Use hdc as emulated SCSI devicevga=ask High-resolution text mode selection

For more information see /usr/src/linux/Documentation/kernel-parameters.txt




Uempty
• For GRUB, you can add kernel arguments directly on the “kernel” line. An /etc/grub/menu.lst stanza for the kernel then looks like this:
title new root (hd0,0) kernel /bzImage-2.4.18-Test ro root=/dev/hda3 mem=128M

There are several parameters that can be useful here. Some of these, and their usage, are:

mem=128M Disables the auto-detection of memory and limits the amount of memory used to the amount indicated. Note that the capital M (for Megabytes) is required: else the kernel tries to use 128 bytes, which immediately leads to a kernel panic.

This parameter can be used, among other things, in the process of sizing a system: trying out the amount of memory that a production system can get by with.

root=/dev/hda3 This identifies the root filesystem to be mounted. This is normally set up correctly and should not be changed. It can be used however if you want to boot your system using a Linux kernel on a floppy disk.

ro This is again a standard value. It ensures that the root filesystem is mounted read-only. That makes it possible for the bootup scripts to perform an fsck on the filesystem. The bootup scripts then do a remount to mount the filesystem read-write.

init=/sbin/init This identifies the program that should be started first, as soon as the kernel finishes booting. Normally, this is /sbin/init, but if that program is corrupt, or /etc/inittab is corrupt, you can also specify, for instance, init=/bin/bash. This gives you a bash prompt immediately, and allows you to do recovery of init and /etc/inittab.

Note however that specifying init=/bin/bash performs no startup scripts whatsoever. This means that only the root filesystem is mounted, read-only. You will have to do a remount to read-write of the root filesystem, and possibly mount other filesystems as well, in order to do something useful.

hdc=ide-scsi This means that the ide-scsi module is used to handle the hdc device. The ide-scsi module is a special module which uses an IDE disk to emulate a SCSI disk. This is not required for regular disk drives and CD/DVD players, but is a requirement for CD-Writers, since the cdrecord program can only handle SCSI CD-Writers.

After the kernel has booted, the CD-RW is now available as /dev/scd0 instead of /dev/hdc.



Student Notebook

vga=ask Ask the user what high-resolution text mode to use. This will presented through a menu of possible resolutions. If you found a resolution that suits you, then you can also configure that resolution as default by using vga=<identifier>.




Uempty

Figure 7-15. Configuring Modules at Load Time LX033.1

Notes:

When modules are checked for dependencies with depmod and when they are loaded with modprobe, the options from /etc/modules.conf are being read. There are four things that can be specified here:

• The alias specifies the name of the module that is to be loaded to support a specific device. In the example above, if someone wants to use the eth0 device, the kernel automatically loads the eepro100 module, which contains the kernel code for that device.

• The options line specifies the specific options to be passed to the module when it is being loaded. This can be very useful if you have two or more identical Ethernet cards as in the example. The options line is then used to distinguish them from each other.

Other uses of the options line exist as well. As an example, you can use them to force Ethernet cards into full-duplex mode, or force Token-Ring cards to a ringspeed of 16 Mbps.

Configuring Modules at Load Time

Specify in /etc/modules.conf

alias identifies the module which implements a device

options are specific for each moduleUse modinfo to obtain specific information

pre-install, install, post-install execute scripts when loading a module

pre-remove, remove, post-remove execute scripts when unloading a module

# cat /etc/modules.confalias eth0 eepro100alias eth1 eepro100options eth0 irq=9options eth1 irq=10



Student Notebook

For specific information about the options that a module supports you will need to run modinfo -p <modulename> or dig into the source. (Most modules have a list of possible options right at the start of the source code.)

• The pre-install, install and post-install lines allow you to specify scripts that are to be started when loading a module.

• the pre-remove, remove and post-remove lines alloy you to specify scripts that are to be started when unloading a module.

Although most distributions do not use it, it is also possible to put an include statement in the modules.conf file, which ensures that other files (typically located in /etc/modules.d) are included. This helps keep your modules.conf file clean.




Uempty

Figure 7-16. Configuring the Running Kernel LX033.1

Notes:

Several kernel parameters can be changed at run time. An example of this is IP forwarding, which can be turned on and off while the system is running. All these changeable parameters have a virtual file representation in /proc/sys.

To list the current setting, simply list the file to the screen with the cat command. To change a setting, simply echo the new setting to the file.

These changes however are not persistent. Because of this, the sysctl utility has been created which can do this for you: it allows you to store all settings in a file, usually /etc/sysctl.conf. As part of the bootup scripts, the sysctl -p command is executed. This reads all settings from /etc/sysctl.conf and applies them.

With the sysctl command you can also list and change settings manually, but this is not often used.

Configuring the Running Kernel

Certain kernel settings can be changed while running

All these settings have an entry somewhere in /proc/sys

Example: Setting up IP-Forwarding

sysctl command gives easy interface to this

# cat /proc/sys/net/ipv4/ip_forward0# echo 1 > /proc/sys/net/ipv4/ip_forward

# sysctl net.ipv4.ip_forwardnet.ipv4.ip_forward = 1# sysctl -w net.ipv4.ip_forward=0net.ipv4.ip_forward = 0

The sysctl -a options prints out all current settings, the -p option reads settings from the /etc/sysctl.conf file (done at startup)



Student Notebook


Notes:


1.

2.

3.

Checkpoint

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:

Unit Summary

Why kernel compilation

Installing kernel sources

Compiling the kernel

Installing the kernel

Configuring the kernel



Student Notebook




Uempty
Unit 8. Character Devices, PCMCIA, and USB

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



• Describe the main characteristic of a character device

• Configure serial, parallel, and PS/2 ports

• Configure a sound card

• Describe the PCMCIA subsystem

• Describe the USB subsystem


Accountability:

• Checkpoint • Machine exercises


© Copyright IBM Corp. 2001, 2004 Unit 8. Character Devices, PCMCIA, and USB 8-1

Student Notebook


Notes:

Unit Objectives


Describe the main characteristic of a character device

Configure serial, parallel and PS/2 ports

Configure a sound card

Describe the PCMCIA subsystem

Describe the USB subsystem




Uempty

Figure 8-2. Character Devices LX033.1

Notes:

As you may know already, any device on a Linux/UNIX system is either characterized as a character device or a block device. The difference between these is that a block device allows random seeks, and a character device doesn’t: a character device can only be read from and written to serially.

A lot of devices in Linux are character devices:

• The console itself

• Any serial terminals that are attached to the system. (A serial terminal is a combination of monitor and keyboard, which is attached via a serial cable to a serial port.)

• Printers

• Sound cards

• The random number generator

• The null device, which is typically used to discard unwanted data

Character Devices

A Character Device is any device which does not allow random access (seeks)

Examples:Console (keyboard, mouse)Serial terminalsPrintersSound cardRandom number generatorNull device



Student Notebook

Figure 8-3. Character Device Naming LX033.1

Notes:

All character devices have a representation in /dev. As you can see, the permission fields as shown by ls -l all start with a “c”, which indicates a character device.

Character Device Naming

All character devices have a representation in /dev

# ls -l /devcrw------- 1 root root 5, 1 Oct 18 2002 /dev/consolecrw------- 1 root root 14, 3 Oct 18 2002 /dev/dspcrw------- 1 root lp 6, 0 Oct 18 2002 /dev/lp0crw-rw-rw- 1 root root 1, 3 Oct 18 2002 /dev/nullcrw------- 1 root root 10, 1 Oct 18 2002 /dev/psauxcrw-r--r-- 1 root root 1, 8 Oct 18 2002 /dev/randomcrw--w---- 1 root root 4, 0 Oct 18 2002 /dev/tty0crw-rw---- 1 root uucp 4,64 Oct 18 2002 /dev/ttyS0crw-rw---- 1 root root 1, 9 Oct 18 2002 /dev/urandomcrw-rw-rw- 1 root root 1, 5 Oct 18 2002 /dev/zero




Uempty

Figure 8-4. Virtual Character Devices LX033.1

Notes:

On any Linux system, there are four virtual character devices: Devices that have a representation in /dev, but don’t have matching hardware.

These devices are:

/dev/null Used as the “bit bucket”, to discard unwanted output of a command or script. Example: find / 2> /dev/null

/dev/zero Used as an infinite supply of binary zeroes: If you do a cat /dev/zero, the output will be all ASCII character 0’s. Unfortunately, this is an undisplayable character, so you need to do hexdump -v /dev/zero to see anything at all.

/dev/zero is typically used to create large, empty files. The following command, for example, creates a 1M file:

dd if=/dev/zero of=bigfile bs=1M count=1

Virtual Character Devices

"Null" devices/dev/null: Bit bucket; used for unwanted output/dev/zero: Infinite supply of binary zeroes

"Random" devices/dev/random: Entropy pool - blocks if empty/dev/urandom: Entropy pool - switches to pseudo-random if empty

# dd if=/dev/zero of=/tmp/swapfile bs=1M count=32

Example: Creating a empty file (32 MB)



Student Notebook

/dev/random Truly random numbers are really important in the field of computer security. It is really hard to generate truly random numbers on a “deterministic device”1, such as a computer.

In the past, programs requiring random numbers have always used pseudo-random numbers, and each program had its own implementation to generate these. This has caused a lot of security problems.

To solve this, Linux implements the /dev/random device, which holds a large number of random numbers (called the “entropy pool”). These random numbers are truly random, and are derived from random events in the outside world, such as mouse movements. It is for instance really illustrative to do:

hexdump /dev/random

And then move the mouse.

/dev/urandom The problem with /dev/random is that the entropy pool is generally not overly large: after a few hundred to thousand random characters the entropy pool is empty. If a program requires more than this amount of randomness, it should have to wait before someone moves the mouse. Obviously, mouse events are rare on a heavily loaded server in a computer room.

To solve this problem, /dev/urandom was introduced. This device generates truly random numbers as long as the entropy pool is not empty, but starts generating pseudorandom numbers (based on the earlier random numbers) as soon as the entropy pool is empty.

1 A deterministic device is a device which always gives the same output when presented with the same input.




Uempty

Figure 8-5. Serial Devices, Modems and ISDN LX033.1

Notes:

The devices /dev/ttyS0 and /dev/ttyS1 represent the serial devices COM1 and COM2, respectively. In some documentation you might still find references to /dev/cua0, /dev/cua1 and so forth. The usage of these devices is deprecated: it still works, but you should not use them anymore. The reason is that the ttyS* devices support locking and cua* devices do not.

Serial ports are typically used to connect modems to your system, so that you can connect to an ISP, or that others can dial-in to your system, typically using the PPP protocol. (This is covered in the LX07.)

Using special “multiport” cards, you can add more serial devices to your system (up to 128 in most implementations). This is particularly useful if you are an ISP and want to connect lots of dial-in modems to your systems. Multiport cards are for instance manufactured by Cyclades.

Certain devices create other serial ports too. There are two devices where this is particularly true:

Serial Devices, Modems and ISDN

/dev/ttyS0, /dev/ttyS1: serial ports COM1 and COM2

More serial ports can be added to the system if "multiport" devices are used

For example, Cyclades

Some devices add special device files:Internal modems (beware of win-modems!)ISDN: /dev/ttyI0, /dev/ttyI1, ...

To list and configure parameters (IRQ, I/O, UART type) of a serial port, use setserial

# setserial /dev/ttyS0 irq 4 port 0x3f8 uart 16550A

Be careful when changing settings with setserial. Wrong use may cause the system to hang.



Student Notebook

• Internal modems. These modems have an ISA or PCI form factor so that they can be built into the actual computer case. A true internal modem will configure itself so that it acts as a separate COM3 (/dev/ttyS2) or COM4 (/dev/ttyS3) serial port. However, most internal modems today are so-called “winmodems”, which do not truly implement a serial port with attached modem, but rather require a special driver to operate. This driver then uses the CPU for modulation and demodulation, instead of having a special modulation/demodulation chip itself.

Most manufacturers of winmodems only release drivers for Windows operating systems (hence the name Winmodems). To the best knowledge of the author, only Lucent (Lucent winmodem) and IBM (MWave) have released information and/or drivers for Linux. Using these modems is still far from trivial, however: You typically need to compile, configure and run a special daemon under Linux to be able to use your modem.

• ISDN cards. ISDN cards are not “modems” since they do not do modulation and demodulation. Instead, they are properly called “network adapters”. Their device representation thus is /dev/isdn0, /dev/isdn1 and so forth.

Most dial-up software however is not able to work with such adapters, and Linux therefore implements a number of pseudo-modem devices called /dev/ttyI0, /dev/ttyI1 and so forth. These pseudo-modems accept the regular Hayes compatible AT command set, and thus can be used by all dialer programs2.

The first four serial devices on a system are by default configured by the Linux kernel, who detects the UART type and sets IRQ and I/O parameters correctly. If you have more than four serial devices, you can set their UART type, IRQ and I/O parameters manually with the setserial command.

Another reason why you might want to use setserial is to configure a higher bps rate than usual, such as 115.2 Kbps. This is for instance required when you’ve got an external ISDN modem.

2 The only difference is that these modems generally require the use of the AT&E command to set the MSN (Multiple SubscriberNumber).




Uempty

Figure 8-6. Serial Terminals LX033.1

Notes:

Serial Terminals (sometimes called “dumb terminals”) are devices which combine a keyboard and a monitor into one device, and are connected to the system via a serial cable to the serial port. Depending on the model, you may need a null-modem cable or a straight cable. The serial cable may involve modems as well, allowing you to do easy remote management of the system. Serial terminals are not used often anymore, but can be useful since it allows you to have a console attached to the system over a long distance, without requiring a network. And serial consoles are really useful in large clusters, because they require less cabling than KVM switches.

A serial terminal can be anything from the IBM 3151, a PC with terminal emulation software (such as minicom) or a hand-held PDA with terminal emulation software.

To configure a serial terminal under Linux, you need to run a “getty” on the serial port. This is most commonly done from /etc/inittab, and the getty most often used for this in Linux is mgetty.

Serial Terminals

Serial Terminals are connected to the system via a serial cable to the serial port

Serial Terminals:Hardware, for instance IBM 3151PC with terminal software, for instance minicom(use it within a modem connection)PDA with terminal software

To configure in Linux, add to /etc/inittab:

# cat /etc/inittab...S0:12345:respawn:/sbin/agetty -L 9600 ttyS0 vt102mo:235:respawn:/usr/sbin/mgetty -s 38400 modem

Hint: type "linux console=ttyS0 38400" at the boot prompt to use a serial terminal as system console



Student Notebook

mgetty will automatically configure a modem for dial-in. If you’re running mgetty directly on a serial cable, without a modem involved, use the -r option to prevent modem initialization.

Linux also supports having the console on a serial port. This means that you can run Linux on a box without a graphical adapter, which is really useful in large clusters. To force Linux to use a serial port as console, even if a graphical adapter is present, use the boot option console=ttyS0. The default settings on the serial port are 9600,8N1. To change these settings you can add options to the console boot option. In addition to this, you can also set LILO to use the serial port as console. For more information, see the file /usr/src/linux/Documentation/serial-console.txt.




Uempty

Figure 8-7. Parallel and PS/2 Ports LX033.1

Notes:

/dev/lp0 and /dev/lp1 represent LPT1 and LPT2, respectively.

/dev/psaux represents the PS/2 port used for your mouse.

Parallel and PS/2 Ports

/dev/lp0, /dev/lp1: LPT1 and LPT2 parallel ports

/dev/psaux: PS/2 port (used for mice and keyboards)



Student Notebook

Figure 8-8. Sound Cards LX033.1

Notes:

When a sound card has been detected and activated, the kernel activates the /dev/dsp (digital sound processor) interface. This interface accepts multiple simultaneous streams of sound data, so that multiple applications can send their output to the sound card together.

Sound card support is built-in in the Linux kernel and thus requires only that the correct kernel modules are loaded. However, the sheer number of sound cards available on the market today has lead to an equally large amount of kernel modules. For this reason it is usually best to configure a sound card using a special administration tool such as alsaconf, yast (SuSE) or redhat-config-soundcard (Red Hat).

Sound Cards

When a sound card has been detected and configured, the kernel activates the /dev/dsp interface.

Two different Sound systems does exit:OSS - Open Sound System (included in kernel sources) - used by RedHatALSA - Advanced Linux Sound Architecture (has more features, but is not part of the vanilla kernel) - used by SuSE

Configuring the appropriate modules in the correct way may be a complicated thing. Better use the tools which shipped with the distribution

RedHat: redhat-config-soundcardSuSE: alsaconf




Uempty

Figure 8-9. PCMCIA and USB LX033.1

Notes:

Both PCMCIA (also known CardBus)3 and USB devices are detected by modern 2.4 kernels automatically. If the kernel has support for the particular device, then it is configured and activated automatically.

For historic reasons, PCMCIA devices require the presence of the cardmgr daemon, who uses configuration data in /etc/pcmcia (particularly the *.opts files) to configure a device properly (this might change in the future).

CardBus and USB devices use the PCI hotplug interface: The kernel first activates the device, and then calls the /sbin/hotplug script for user-space configuration. The same happens when the device is removed. In the future, when systems are available that support hot-pluggable PCI cards and other hot-pluggable devices, they will use this mechanism too.

Obviously, removing a device which is in use might lead to problems such as dropped connections, corrupted data and so forth. It is therefore a good idea to manually deactivate

3 Technically, all 16-bit cards are PCMCIA devices, and 32-bit cards are CardBus cards. From the outside, CardBus cards can berecognized by 8 little notches on the top of the connector, while a PCMCIA card is flat.

PCMCIA and USB

PCMCIA (aka CardBus) and USB devices are detected and activated by the kernel automatically

Old PCMCIA (16-bit) is handled by cardmgr For CardBus (32-bit) and USB, the kernel calls the /sbin/hotplug script which configures the device

To list all available devices use the cardctl (PCMCIA) and lsusb (USB) commands

# lsusbBus 002 Device 001: ID 0000:0000Bus 001 Device 001: ID 0000:0000# cardctl statusSocket 0: 5V 16-bit PC Card function 0: [ready]Socket 1: no card



Student Notebook

network interfaces, unmount filesystems and so forth, before removing the hot-pluggable device which implements this network interface or filesystem.

Information on USB and CardBus devices can be obtained from the /proc/bus/usb and /proc/bus/pci virtual filesystem, respectively. The usbview and lsdev commands are deprecated and no longer present in most distributions, and the same applies to the /etc/usbmgr configuration directory.

In order to list the modules that are required for supporting a specific USB device, use usbmodules <device>. In most cases, this will include one of the modules usb-uhci.o and usb-ohci.o, depending on the type of USB controller you have.




Uempty


Notes:

Write your answers down here:

1)

2)

3)

Checkpoint

1)

2)

3)

T/F

A character device allows random "seeks".

What is the difference between /dev/random and /dev/urandom?

What script is used for configuring all hotplugged devices?



Student Notebook


Notes:

Unit Summary

Character devices are devices that do not offer random access; they can only be read serially

Examples of character devices are: mice, keyboards, modems, sound cards and printers

Serial ports can be configured using setserial and can be used to attach serial terminals

The sound card device is /dev/dsp; it accepts multiple input streams

For PCMCIA, USB and other hot-pluggable devices the /sbin/hotplug script is used to configure them




Uempty
Unit 9. Block Devices, RAID and LVM

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



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


Accountability:



© Copyright IBM Corp. 2001, 2004 Unit 9. Block Devices, RAID and LVM 9-1

Student Notebook


Notes:

Unit Objectives


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




Uempty

Figure 9-2. Block Devices LX033.1

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.

Block Devices

A "Block Device" is any device which allows random access ("seeks") and which is divided into "blocks" of a given size.

Typical block devices:Harddisks (and partitions)Floppy disksVirtual block devices (RAID and LVM)

block

1 2 3 4 5 6 7 8

0 512 4096

byte



Student Notebook

Figure 9-3. Block Device Naming LX033.1

Notes:

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

Block Device Naming

All block devices have a special file representation in /dev

fd0, fd1, ...: floppy disk (max 8)

hda, hdb, ...: IDE hard disk (max 8)

sda, sdb, ...: SCSI hard disk (max 128)

# ls -l /devbrw-rw---- 1 root floppy 2, 0 Aug 24 2000 /dev/fd0brw-rw---- 1 root disk 3, 0 Aug 24 2000 /dev/hdabrw-rw---- 1 root disk 8, 0 Aug 24 2000 /dev/sda




Uempty

Figure 9-4. Floppy Disks LX033.1

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.

Floppy Disks

Floppy disks may need to be initialized first with correct size information (low level format) with the fdformat command

# fdformat -n /dev/fd0h1440Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.Formatting ... doneVerifying ... done

Note: to format a floppy disk with a different capacity, use another device file (for example /dev/fd0u2880)



Student Notebook

Figure 9-5. Hard Disks LX033.1

Notes:

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

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

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

IDE device numbering is based on how the device is connected:

• The master on the first bus on the first adapter is hda

• The slave on the first bus on the first adapter is hdb

• The master on the second bus on the first adapter is hdc

• and so forth.

Hard Disks

Most common device for persistent storage

Two common types: IDE and SCSI

IDE (Integrated Drive Electronics)Max 2 disks (master/slave) on one busMax 2 buses on adapterMax 2 adapters in systemAlso supports CD-ROM (ATAPI)Device naming /dev/hda, hdb, ..., hdh

SCSI (Small Computer System Interface)Different subtypes: fast, wide, fast wide, ultra-wide, ...Max 7 or 15 disks on one bus (depends on subtype)Needs correct termination at both ends of busGenerally more expensive than IDEAlso supports CD-ROM, tapes, zip drives, ...Device naming /dev/sda, ..., sdz, sdaa, ..., sddx




Uempty
Most CD-ROM, CD-RW and DVD players for the home market are attached as if they were IDE devices too. This is governed by the ATAPI standard.
SCSI is a technology which is technically superior to IDE, but generally more expensive. It has various subtypes which each have their own performance characteristics and physical connector size and types. Depending on the subtype, there is a maximum of 8 or 16 devices on each bus, one of which is the SCSI controller itself. This leads to a maximum of 7 or 15 disks on each bus. However, an adapter typically supports multiple buses, and multiple SCSI adapters may be used simultaneously.

SCSI device naming is largely based on the SCSI ID: The SCSI drivers will detect and activate each and every adapter and SCSI bus in turn, and subsequently activate each device on that bus starting with the lowest SCSI ID. This number can be manipulated, typically by setting a jumper combination, dip switch combination or rotary dial. All devices are assigned a device entry in the order in which they were detected. So the first drive detected becomes sda, the second device becomes sdb, and so forth.2 Obviously, the first drive detected is also used as the boot device.

Obviously, it is of the utmost importance that no two SCSI devices on the same bus have the same ID number. This can be checked by looking at the output of the dmesg command, or by entering the SCSI BIOS when the system boots. Note that the SCSI adapter always needs one ID for itself too.

The SCSI standard also allows for CD, DVD, tape drives, Zip drives and other block devices to be attached.

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

Information on your SCSI devices can be obtained from the /proc/scsi directory, and with the command scsi_info <device>.

2 This causes a problem if new disks are inserted with IDs lower than the existing drives. Suppose you’ve got one SCSI bus with twodisks connected to it. The disks use ID 3 and 6, respectively, and are named sda (device with ID 3) and sdb (device with ID 6). If youwere to add a disk with ID 5, then this new disk becomes sdb, and the disk with ID 6 becomes hdc. This might lead to boot problems,particularly when the disk partitions need to be fsck-ed and mounted, and their names (/dev/hdb1, for instance) are hard-coded in/etc/fstab, instead of using ext2 filesystem labels.



Student Notebook

Figure 9-6. Monitoring Hard Disk Health LX033.1

Notes:

Disk drives, together with case fans, are typically the first devices that fail in a modern computer system. Because of this, most modern IDE and SCSI disks are equipped with SMART (Self Monitoring and Reporting Technology).

A disk equipped with SMART continuously collects data about its own performance and environment: number of power cycles, temperature, error rates and so forth. The operating system can then collect these parameters through a standardized interface.

The smartmontools use this interface to collect these parameters and report them back to the user. There are two tools available:

smartctl is a tool which collects the parameters from the drive, and reports them back to the user. It can also be used to initiate self-tests, if the drive supports that.

The two most common options are -a, which reports all parameters, and -x, which initiates a long self-test. For more options, see the manual page.

Monitoring Hard Disk Health

S.M.A.R.T.: Self Monitoring And Reporting TechnologyTechnology included in most modern IDE/SCSI disksReports various disk parameters (errors, temperature, various counts, ...) to OS

smartctl: Tool for accessing SMART datasmartctl -a /dev/hda reports all /dev/hda parameterssmartctl -X /dev/hda initialized long self-testman smartctl for more options

smartd: Monitoring daemonMonitors attributes every 30 minutesReports changes to syslogNewer versions can send mail too if attributes change (use /etc/smartd.conf for configuration)




Uempty
smartd is a daemon which monitors all parameters of all disks every 30 minutes. It then reports any changes through the system logger. Newer versions can also report changes via mail. You will need an /etc/smartd.conf file to configure this.
Note that Red Hat and Fedora ship these smartmontools as part of the kernel-utils RPM. SuSE puts the smartmontools in their own RPM.



Student Notebook

Figure 9-7. Hard Disk Partitions LX033.1

Notes:

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

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

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

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

3 Most of the earliest IBM PCs came without a hard disk and only had one 5.25" floppy disk of 360 KB...

Hard Disk Partitions

IDE and SCSI hard disks can be partitioned

Maximum of four primary partitions

One primary partition may be an extended partition

An extended partition can hold an unlimited amount of logical partitions (Linux: max 59 for IDE, 11 for SCSI)

master boot recordpartition table

Windows 95

Linux /

Linux /home

Linux swap

hda1: First primary partition holds a Windows 95 filesystem

hda2: Second primary partition is an extended partition and

holds three logical partitions

hda5: First logical partition holds a Linux filesystem that will

be mounted as /

hda6: Second logical partition holds a Linux filesystem that

will be mounted as /home

hda7: Third logical partition holds a Linux swap space

hda: The first sector of the disk contains the MBR and Partition Table




Uempty
Linux by default supports a maximum number of 63 logical partitions on IDE disks, and a maximum of 11 logical partitions on SCSI disks. The last has to do with SCSI subdevice numbering: According to the SCSI standard, each device can be split up into 16 subdevices. One is used for the device itself, four for the primary partitions, which leaves 11 for the logical partitions.


Student Notebook

Figure 9-8. Partitioning Tools LX033.1

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.

Partitioning Tools

PartitionMagicCommercial DOS/Windows program from PowerQuestCan create/resize/move/delete partitions

fipsFree DOS program, comes with all Linux distributionsCan split an existing Windows partition in two parts

fdiskVirtually every PC OS comes with a tool "fdisk" to create partitions for that OSWindows, OS/2, Linux, ...

partedGPL'ed Linux program, available at www.gnu.orgCan create/resize/move/delete partitions

Disk Druid and othersPartitioning program integrated in Linux install program




Uempty

Figure 9-9. RAM Disks LX033.1

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.

RAM Disks

A RAM disk is a block device created in memoryAutomatically created when usedSize is compiled into the kernelDisappears after reboot

Linux supports up to 16 RAM disks by default (255 max)

To create a RAM disk: write data to it

To delete a RAM disk: use freeramdisk

# tar -cvf /dev/ram0 /etc# tar -tvf /dev/ram0-rw-r--r-- root/root 854 2003-04-19 20:25:41 etc/passwd-rw-r--r-- root/root 440 2003-04-19 20:25:41 etc/group...# freeramdisk /dev/ram0



Student Notebook

Figure 9-10. The “loop” Device LX033.1

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.

The mount -o loop command actually invokes the losetup command to couple a file to a /dev/loop device. You can also invoke losetup manually, and that gives you the opportunity to enable encryption on the device as well.

The encryption methods that are available are dependent on the kernel version and kernel compilation options though, and in practice only distributions that have a 2.6 kernel have a good set of encryption methods available.

The "loop" Device

The "loop" device is used to access files as block devices

Linux supports a maximum of 16 loop devices by default

# mount -o loop bootnet.img /mnt/floppy# mount -o loop,ro SuSE-8.2-CD1.iso /media/cdrom

2.6 kernels have support for encrypted loop devices as well

Use losetup to initially set up the loop deviceCan then mount and unmount the device transparently

# dd if=/dev/zero of=secrets.enc bs=1M count=32# losetup -e blowfish /dev/loop0 secrets.enc... asks for password to be used as encryption key ...# mke2fs /dev/loop0# losetup -d /dev/loop0# mount -o loop,encryption=blowfish secrets.enc /mnt/secrets




Uempty

Figure 9-11. Logical Volume Management (1 of 2) LX033.1

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.

Logical Volume Management (1 of 2)

Traditional disk partitioning scheme has several disadvantages:

Virtually impossible to resize or move a partitionPartition size is limited by disk size

Logical Volume Management solves these disadvantages:

One or more Physical Volumes (hard disks, partitions) are assigned to a Volume Group (VG)All Physical Volumes (PV) are split into Physical Extents (PE) of identical size (default 4 MB)PE's in a VG can be combined into Logical Volumes (LV), which can be used like any block device

An LV can span multiple disks

To increase the size of an LV, add PEs

To increase the size of a VG, add PVs



Student Notebook

3. PEs in a VG are then combined into Logical Volumes. Each logical volume is a block device and can be used to hold a filesystem, for instance. Since an LV always consists of 1 or more PEs, its size will always be a multiple of 4 MB.

The PEs that are part of an LV do not have to be on the same physical disk or disk partition, as long as they are all part of the same volume group. That means that a logical volume can be larger than your physical disk size. Furthermore, the PEs that are part of an LV do not have to be sequentially located on disk. This means that it is easy to extend an LV.

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




Uempty

Figure 9-12. Logical Volume Management (2 of 2) LX033.1

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.

Logical Volume Management (2 of 2)

PE PE PE

PE PE PE

PE PE PE

PE PE PE

PE PE PE

PE PE PE

volume group

physical volume

(hard disk or partition)

physical volume


logical volume



Student Notebook

Figure 9-13. LVM Implementation Overview LX033.1

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.

LVM Implementation Overview

Add hard disks and/or create partitions (type 0x8e) on existing hard disks

Initialize physical volumes (disks or partitions)pvcreate /dev/hda3pvcreate /dev/hdb

Create volume group "vg00" with physical volumesvgcreate vg00 /dev/hda3 /dev/hdb

Create logical volume "lv00" in volume grouplvcreate -L 50M -n lv00 vg00

Can now use /dev/vg00/lv00 as block device




Uempty

Figure 9-14. Physical Volume Commands LX033.1

Notes:

Three commands allow you to manage your physical volumes:

pvcreate This command initializes a physical volume. Among other things, this means that a Volume Group Descriptor Area (VGDA) is added at the start of the PV. This VGDA will later contain LVM information, such as the size of the physical extents.

pvmove This command allows you to move all PEs on a PV to another PV within the same volume group. This is useful if you want to take that PV out of the volume group.

pvdisplay This command allows you to view information about a PV.

Physical Volume Commands

pvcreate <pv>Initializes a physical volume by putting an (empty) Volume Group Descriptor Area at the start of the PV

pvmove [-n <lv>] <source pv> [<destination pv>]Move PEs from one PV to another PV in the volume group

pvdisplay <pv>List information about a PV

VGDA (Volume Group Descriptor Area)



Student Notebook

Figure 9-15. Volume Group Commands LX033.1

Notes:

Several commands are available to let you work with volume groups:

vgcreate This command allows you to create a new volume group. As part of the command, you need to specify the PE size that is going to be used in this volume group. Furthermore, you always need to specify the name of at least one physical volume.

vgdisplay This command displays information about a volume group.

vgchange This command changes attributes of a volume group.

The most important change is to deactivate a volume group with the vgchange -a n <vg> command. This needs to be done before either vgexport or vgremove can be executed.

vgremove This command deletes a volume group.

Volume Group Commands

vgcreate [-s <pe size>] <vg name> <pv> [<pv>...]Create a volume group

vgdisplay [<vg>]Display information about a volume group

vgremove <vg>Delete a volume group

Physical

Volume (PV)Physical

Volume (PV)

Physical

Volume (PV)

Volume Group (VG)




Uempty

Figure 9-16. Logical Volume Commands LX033.1

Notes:

There are several commands that let you manage logical volumes too:

lvcreate This command creates a logical volume of the specified size, with an optional name, in a certain volume group. You can also specify the physical volumes to be used.

lvdisplay This command displays information about a logical volume.

lvremove This command removes a logical volume.

Logical Volume Commands

lvcreate -L <size> [-n <lv name>] <vg> [<pv>...]Create a logical volume in a volume group

lvdisplay <lv> [<lv>...]Display information about a logical volume

lvremove <lv> [<lv>...]Remove a logical volume

Physical

Volume (PV)Physical

Volume (PV)

Physical

Volume (PV)

Volume Group (VG)

Logical Volume (LV) LV LV LV



Student Notebook

Figure 9-17. Striping Logical Volumes LX033.1

Notes:

Logical Volumes can be striped. This means that the logical volume is spread out over several disks. This greatly increases performance for large data transfers, especially if the disks are attached to separate controllers as well.

A slight disadvantage of striping is that if any of the disks involved fails, then your LV is lost.

Striping Logical Volumes

PE PE PE

PE PE PE

PE PE PE

PE PE PE

PE PE PE

PE PE PE

volume group

physical volume


physical volume


# lvcreate -L 300M -i 2 -I 8 -n mystripedlv vg00

/dev/vg00/mystripedlv

A Logical Volume may be striped across two or more Physical Volumes during creation

For large data transfers, this increases performance




Uempty

Figure 9-18. Extending/Reducing a Volume Group LX033.1

Notes:

After a while you will find that the original LVM scheme that you created when you installed the system is not suitable for your needs anymore. With the traditional partitioning scheme, you needed considerable downtime of your system to rearrange your partitions.

With LVM, you can add disks to the system and then, while the system is running, add these disks to volume groups. You can then migrate physical extents to this new disk, and take the old disk out of the volume group. All this while the system is running: You don’t even have to unmount the logical volumes involved.

Extending a volume group with a new physical volume is done with vgextend. Moving physical extents from one physical volume to another is done with pvmove, and reducing the volume group is done with vgreduce.

Extending/Reducing a Volume Group

To add or remove a Physical Volume to or from a Volume Group, use the vgextend and vgreduce commands

To move Physical Extents from one Physical Volume to another use pvmove

# vgextend vg00 /dev/hdc6# vgreduce vg00 /dev/sda5ERROR: can't reduce volume group "vg00" by used physical volume "/dev/sda5"# pvmove /dev/sda5 /dev/hdc6# vgreduce vg00 /dev/sda5



Student Notebook

Figure 9-19. Extending/Reducing a Logical Volume LX033.1

Notes:

Just like we could extend a volume group, we can also extend logical volumes. This is done simply by adding physical extents at the end of the logical volume, or taking them away from the end. The commands for this are lvextend and lvremove.

Important note: If you extend or reduce a logical volume with lvextend and lvremove, then you are not automatically enlarging or shrinking the filesystem inside. This is a separate step and will be covered in the next unit.

Extending/Reducing a Logical Volume

To extend/shrink a Logical Volume use the lvextend/lvreduce commands

Use -L option to specify size in bytes

Use -l option to specify size in PEs

lvextend/lvreduce do NOT extend/shrink a filesystem in the LV automatically!!!

(Extending/shrinking a filesystem will be covered later)

# lvextend -L +300M /dev/vg00/mylvlvextend -- rounding relative size up to physical extent boundarylvextend -- extending logical volume "/dev/vg00/mylv" to 380 MBlvextend -- doing automatic backup of volume group "system"lvextend -- logical volume "/dev/vg00/mylv" successfully extended# lvreduce -l -12 /dev/system/mystripedlv...




Uempty

Figure 9-20. LVM Backup and Recovery LX033.1

Notes:

When backing up your system, it is vitally important to save the LVM metadata (which is stored in the VGDA) as well. (Just as it is equally important to save the partition table of a system when doing a backup.)

Creating a text file that contains the LVM metadata is done with the vgcfgbackup command. The resulting text file, /etc/lvmconf/<vgname>.conf can be archived just like any file.

In the event you need to restore your system, you can create your LVM configuration with the vgcfgrestore command. Obviously, you also need to restore the data stored in your logical volumes as well in that case, but that’s another topic.

LVM Backup and Recovery

1. vgcfgbackup

2. vgcfgrestore -n vg_name PV

VGDA VGDA VGDA

/etc/lvmconf/vg_name.conf

VGDA VGDA VGDA

It is very important to save the LVM metadata stored in the VGDA for recovering reasons.



Student Notebook

Figure 9-21. Additional LVM Considerations LX033.1

Notes:

There are several considerations when working with LVM:

The Linux LVM implementation has a “snapshot” capability. This allows you to make instant copies of logical volumes. There are several benefits from this. Consider for instance the situation where your logical volume contains a database which needs to be “up” at all times, but does not allow you to make backups while running. In that case, with LVM, you can stop the database, make a snapshot of the logical volume that holds the database, and start the database again. This whole procedure takes less than a minute. After this is done, you can mount the snapshot logical volume and make the backup at your leisure.

Kernel information about LVM can be obtained from the /proc/lvm tree.

When you have filesystems on an LVM Logical Volume, and these filesystems are listed in the /etc/fstab file to mount them automatically, make sure that the LVM module (“lvm-mod”) is included in the Initial Root Disk (initrd).

Unlike other LVM implementations (like AIX), the Linux LVM implementation does not (yet?) support mirroring.

Additional LVM Considerations

Linux LVM implementation has "snapshot" capabilityCan be useful for fast backups

LVM information can be obtained from /proc/lvm tree

If LVM-based filesystems are listed in /etc/fstab, then LVM support needs to be included in the initrd

Unlike other LVM implementations, Linux LVM does not support mirroring (yet?)




Uempty

Figure 9-22. RAID LX033.1

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.

RAID

"Redundant Array of Inexpensive Disks"

Typical PC hard disks, compared to expensive mainframe-quality hard disks are

SlowerLess reliableSmaller...But less expensive

Idea: Use multiple hard disks in an array to create a larger, logical device that is

FasterMore reliableOr larger...And still relatively inexpensive



Student Notebook

Figure 9-23. RAID Levels (1 of 2) LX033.1

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

RAID Levels (1 of 2)

RAID-Linear

12345

6789

10

RAID-0: striping

13579

2468

10

RAID-1: mirroring

12345

12345

RAID-4: striping with parity disk

13579

2468

10

ppppp

RAID-5: striping with parity

13p79

2p58p

p46p10




Uempty
single file (except for the really small ones) was stored at least partly on the disk that had crashed. You should therefore use RAID-0 only for data which can be missed or easily restored.4
RAID-1 uses the second (and third disk) for mirroring: data written to the first disk is written to all other disks as well. This will cost a lot of disk space, but means that you can sustain multiple disk crashes without losing your data.

RAID-4 also offers redundancy, but not by mirroring but by storing parity information5 on a separate disk. Should one disk (or the parity disk) fail, then the data on this disk can be calculated from the data on the other disks. RAID-4 therefore needs at least three disks.

RAID-4 uses striping to store the data blocks on disk for increased performance.

RAID-5 is similar to RAID-4 in that it calculates the parity of two disk blocks and stores this in a third disk block. It also stripes the data onto the disks. The difference between RAID-4 and RAID-5 is that RAID-4 stores all parity information on the same disk. This disk then quickly becomes a bottleneck, unless this disk is significantly faster than the others. With RAID-5, the parity information is striped too, leading to better performance.

Several other RAID levels exist, but these are not implemented in Linux, and not widely used anyway.

4 The author of this course uses a RAID-0 array for storing the /export filesystem of a network install server. If a disk fails, the data on itcan simply be restored from the distribution CDs.5 The parity in this case is calculated by XORing the data on disk 1 with the data on disk 2. If one of the three elements (disk1, disk2,parity) should fail, then that element can be calculated based on the other two.



Student Notebook

Figure 9-24. RAID Levels (2 of 2) LX033.1

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.

RAID Levels (2 of 2)

RAID Levels have different characteristicsRAID-5 is not "better" than RAID-1

Use RAID level according to needs

RAID level

Min # disks

Read performance (*)

Write performance (*)

Redundancy Data capacity with 3x1Gb disk

Other remarks

linear 2 equal equal no 3 Gb Can be used if disk sizes are not equal

0 2 fast fast no 3 Gb

1 2 fast somewhat slower

yes 1 Gb Can sustain N-1 disk crashes

4 3 somewhat faster

slow yes 2 Gb Can sustain 1 disk crashParity disk is bottleneck

5 3 somewhat faster

somewhat faster

yes 2 Gb Can sustain 1 disk crashCPU intensive

(*) Performance compared to a single disk, for data transfers greater than block size




Uempty

Figure 9-25. Linux RAID Support LX033.1

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.

Linux RAID Support

Software RAIDImplemented in Linux kernelNeeds raidtools packageUses disk partitions to create RAID devicesLogical device name: /dev/mdn

Hardware RAIDImplemented in special adapter cardsAdapter needs to be supported by Linux kernelGenerally specific software needed to configure adapter correctly (might not be available under Linux)RAID devices show up as regular SCSI disk



Student Notebook

Figure 9-26. Linux Software RAID Implementation (1 of 2) LX033.1

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.

Linux Software RAID Implementation (1 of 2)

Create RAID partitionsPartition type 0xfd (Linux RAID autodetect)

Create /etc/raidtab file

# cat /etc/raidtabraiddev /dev/md0 raid-level 0 nr-raid-disks 2 persistent-superblock 0 chunk-size 8 device /dev/hda1 raid-disk 0 device /dev/hdb1 raid-disk 1




Uempty

Figure 9-27. Linux Software RAID Implementation (2 of 2) LX033.1

Notes:

When you’re finished editing the /etc/raidtab file, you need to initialize the RAID volume with mkraid. This will initialize the RAID volume and, if necessary, start a synchronization (RAID-1, RAID-4 and RAID-5) in the background. From that point on, you can access the block device /dev/mdn as any block device.

Linux Software RAID Implementation (2 of 2)

Initialize RAID devices with mkraid /dev/md0

/dev/md0 may be used as a normal block device

# mkraid /dev/md0# mkfs /dev/md0...# mount /dev/md0 /mnt/raid0



Student Notebook

Figure 9-28. Watching a Running RAID LX033.1

Notes:

To check the health status of your RAID subsystem, view the contents of the /proc/mdstat file. This contains all the information you need.

Particularly important are the letters between the square brackets. These signal the health status of each of the disk or disk partitions that make up a RAID volume. A “U” means that the device is up and running normally, but an “F” means that the device failed. You should investigate this and possibly replace the device as soon as possible.

If you want to simulate a failing RAID device, you can use the command raidsetfaulty.

Watching a Running RAID

To see the current state of your RAID, watch /proc/mdstat

Very important!

# cat /proc/mdstatPersonalities: [linear][raid5]read_ahead 1024 sectorsmd0: active raid5 sdc1[2] sdb1[1] sdd1[3] sde1[0]633849 blocks level 5, 32k chunk, algorithm 2 [4/4] [UUUU]unused devices: <none>

"U" means all devices are up. If a device fails, "F" is shown.

To simulate a failed disk use raidsetfaulty.




Uempty

Figure 9-29. Spare Disks LX033.1

Notes:

To make a RAID-1 or RAID-5 configuration more fail-save, you can add spare disks. These disks sit idle until one of the active disks fails. The spare disk is then used in place of this active disk.

For a RAID-1 volume, this means that the spare disk is now being mirrored with the other disks. For a RAID-5 volume, this means that the parity information, together with the data remaining on the other disks, is used to re-create the data that is now lost.

You may wonder why a RAID-1 configuration can benefit from spare disks, while this disk can also be configured to perform continuous mirroring anyway. The reason is simply performance: keeping disks mirrored costs time. It is faster to have two mirrored disks and one spare, than to have three mirrored disks.

If a disk in a RAID array fails, you will want to replace it. This can be done without taking the RAID array down. First, you execute the raidhotremove command to remove the failed disk. You then swap disks and execute the raidhotadd command to add the new disks. Note that the new disk will take the place of the spare disk (if you configured spare disks), and the former spare disk will remain production disk.

Spare Disks

To make RAID1/RAID5 more failsafe in case of a disk failure, use spare disks!

spare disk

The spare disk takes over...

# cat /etc/raidtab...nr-spare-disks 1device /dev/sdd1spare-disk 0...

Remove a failed disk with raidhotremove

Add a new disk to the array with raidhotadd



Student Notebook

Figure 9-30. Additional RAID Considerations LX033.1

Notes:

There are a few things to note when using RAID:

Always put your RAID partitions on different disks, or you will nullify any advantage that RAID might try to give you.

If possible, use different SCSI and/or IDE controllers for the different disks (or partitions) that make up your RAID volume. This will increase your performance and reliability.

Never use RAID for your /boot partition, and note that if you use RAID for any other filesystems listed in /etc/fstab (that are mounted automatically), you need to include the RAID modules (“linear”, “raid0”, “raid1”, “raid5” and/or “xor”) in your Initial Root Disk (initrd).

Software RAID-4 and RAID-5 needs a lot of CPU time to perform the parity calculations.

For maximum reliability, RAID-4 and RAID-5 allows you to configure spare disks. These disks (usually only one per array) are not used, until one of the other disks in the array fails. If that happens the RAID software will automatically start using the spare disk instead of the disk that failed. The data on that disk is created automatically from the parity information on the other disks.

Additional RAID Considerations

Put RAID partitions on different disks

Use different SCSI or IDE controllers if possible for different disks that are part of a RAID volume

Do not use RAID for /boot partition

If RAID-based filesystems are listed in /etc/fstab, then RAID support needs to be included in the initrd

Software RAID-4 and RAID-5 needs a lot of CPU time

Do not use RAID-linear or RAID-0 for swap spaceThe Linux kernel can stripe across swap spaces more efficiently




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.

Checkpoint

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:

Unit Summary

Block devices are devices that offer random access

Block devices are: hard disks, hard disk partitions, floppy disks, RAM disks, files, LVM logical volumes and RAID volumes

Block devices can be used to store a filesystem, as swap space, or "raw"

Logical Volume Management allows you to go beyond the limits of regular partitioning, since it allows you to create logical volumes that are larger than the disk size, and which can be resized

RAID is a technology to use inexpensive, less reliable, relatively slow and small IDE or SCSI disks in such a fashion that the virtual volume is larger, more reliable or faster than the individual disks



Student Notebook




Uempty
Unit 10. Filesystems

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



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


Accountability:



© Copyright IBM Corp. 2001, 2004 Unit 10. Filesystems 10-1

Student Notebook


Notes:

Unit Objectives


Describe what a file is

Describe what a filesystem is

List possible filesystems

Describe inodes

Create/mount/unmount filesystems

Create predefined mounts

Set up user and group quota




Uempty

Figure 10-2. What is a File? LX033.1

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).

What is a File?

Consecutive number of bytesNo internal structure by default (applications define their own structure)

Stored and referenced in a filesystemCan have multiple references (names)

Special files existBlock, Character -> DevicePipes, Sockets -> Interprocess communication



Student Notebook

Figure 10-3. What is a Filesystem? LX033.1

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.

What is a Filesystem?

Place to store files and refer to them

Hierarchical structure through use of directories

A filesystem can be stored on any block deviceFloppy diskHard diskPartitionRAID, LVM volumeFile (for use with a loop device)RAM disk

/

/usr /lib /etc /bin /var /sbin




Uempty

Figure 10-4. The Virtual Filesystem Switch LX033.1

Notes:

Linux supports a large number of filesystems. You will find a full list on the next page. All these filesystems have their own way of storing data and metadata on disk. However, a typical user is not interested in the internal workings of these filesystems, but needs a single way of dealing with them all. That is the job of the VFS (Virtual Filesystem Switch) abstraction layer.

Typical user programs such as vi, ls and others use four primitive system calls to work with files: open(), close(), read() and write(). (There are a few others for working with directories, permissions and so forth.) These system calls are translated into the appropriate, filesystem-specific system calls by the VFS layer. Because of this, a user is presented with a uniform interface to each filesystem.

Note that the VFS layer emulates certain features if the filesystem does not support these. For instance, Linux is able to mount a VFAT (MS-DOS, Windows) filesystem. A VFAT filesystem does not support permissions however. The VFS layer therefore will always present a default set of permissions to the user. These permissions can be set when the filesystem is mounted, but cannot be changed.

The Virtual Filesystem Switch

file oriented system calls

open() read() write() close()

VFS abstraction layer

ext2/

ext3reiserfs iso9660 vfat

user or system programs

vi ls mv rm file strings cat touch ...



Student Notebook

Figure 10-5. Filesystems Supported LX033.1

Notes:

Linux supports a wealth of filesystems. Its traditional filesystem is ext2, the second extended filesystem. Currently a number of new filesystems for Linux are being developed and are starting to become available in distributions. These include ext3, ReiserFS, IBM’s JFS and XFS. All have distinct advantages over ext2, but a clear winner has not been identified. As an example, Red Hat currently uses ext3 as their default filesystem, while SuSE uses ReiserFS by default.

Filesystems from other operating systems are also supported.

Filesystems Supported

Traditional: ext2

Newest: ext3, ReiserFS, IBM JFS, xfs

Other UNIX: minix, ext, xiafs

FAT-12, FAT-16, FAT-32, VFAT, NTFS (read-only)

HPFS (OS/2) read-only, HFS (Macintosh) read-only

AFFS (Amiga), System V, Coherent, Xenix

CD-ROM (ISO 9660)

UMSDOS (UNIX-like FS on MS-DOS)

NFS (Network File System)

SMBFS (Windows share), NCPFS (Novell Netware share)

/proc (for kernel and process information)

SHMFS (Shared Memory Filesystem)




Uempty

Figure 10-6. A Typical UNIX Filesystem: ext2 LX033.1

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 Typical UNIX Filesystem: ext2

Partition divided into blocks of 1024, 2048 or 4096 bytesBlocksize depends on size of fs and expected usage

Blocks can have different usage:SuperblockInode (Index node) block(Double, Triple) indirect blockData block

S I I D D SD ID D D DI I



Student Notebook

Figure 10-7. Superblock LX033.1

Notes:

The first block of the filesystem (block 1) will be the superblock1. It is a very important block, since it contains information about the rest of the filesystem. Copies therefore are kept on block 8193, 16385 and so on. Should block 1 become corrupt, then mount will attempt to use the other superblocks.

The superblock contains general information about the filesystem, for instance, the time of last usage, the last used mountpoint, the blocksize, and so on. Furthermore, the superblock (indirectly) points to the list of free inodes and the list of free blocks. Last, the superblock contains an (indirect) pointer to the root directory of the filesystem.

1 Block 1 is the second block in the partition. But the first block of the partition, block 0, is never used for the filesystem since this blockmight contain a boot loader.

Superblock

First block of filesystem, several copies (at 8193, 16385, ...)

Contains general info on filesystemLast mounted time/placeBlock sizePointers to free inodesPointers to free blocksPointer to root of filesystem





Uempty

Figure 10-8. Inodes (Index Nodes) LX033.1

Notes:

An inode is 128 bytes large. With a blocksize of 1024 bytes, this means that there are eight inodes in a block. Each inode contains information about a file: user/group information, permissions, size, ctime (creation time), atime (last accessed time) and mtime (last modified time).

It also contains information about the data blocks where the file resides. This structure is a little complicated but very efficient:

The first twelve data blocks (12 KB) are directly addressed; the block numbers are stored in the inode itself.

The next data blocks are indirectly addressed. The inode contains a pointer to an indirect block, and the indirect block contains the block numbers of the data blocks. Since each pointer is four bytes, we can address 256 data blocks, assuming a blocksize of 1024 bytes.

The next 65536 (256*256) data blocks are double indirectly addressed: The inode contains a pointer to a double indirect block, the double indirect block contains pointers to indirect

Inodes (Index Nodes)

128 bytes (8 per block of 1024 bytes)

Contains information about a file: owner, group, type, size, permissions, ctime, atime, mtime, ...

Contains pointers to data blocks

Contains pointers to an indirect block, a double indirect block and a triple indirect block


owner/group

time stamps:create time

access time

modification time

pointers to data blocks

additional flags

(ACL, EXT2_FLAGS)

file type

file size

file permissions

link counter



Student Notebook

blocks, and the indirect block contains pointers to the data blocks (again assuming a blocksize of 1024 bytes).

The next 16777216 (256*256*256) data blocks are triple indirectly addressed. If you read this far you should be able to figure out how that works. The theoretical maximum filesize in the ext2 filesystem is therefore something like 16 GB, when 1K blocks are used.




Uempty

Figure 10-9. Data Blocks LX033.1

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.

Data Blocks

Contain file data

File may be a directory, in which case the data is the list of file names and inodes in that directory.

So multiple file names may point to the same inode! (Or files may have multiple names)

Inode 3694 Data 6417 Inode 8391 Data 9041

name inode

. 3694

.. 13

xyz 8391

abc 8391

type: d

data: 6417

size: 1024

user: 0

group: 0

type: f

data: 9041

size: 21

user: 0

group: 0

link: 2

This is the file xyz.

A directory A regular file



Student Notebook

Figure 10-10. So... LX033.1

Notes:

It is not important to know the exact internal structure of the ext2fs filesystem. What is important to know is that there are two important components of a filesystem: inodes and data blocks. Any file needs an inode and one or more data blocks. If there are no more inodes or data blocks available in the filesystem, the filesystem is full.

If you really want to use your filesystem to the limit, it is important to tune it according to the data you expect.

The blocksize can be 1024, 2048 and 4096. This size is chosen when the filesystem is created, based on the expected usage of the system. If you expect a lot of small files, choose a small blocksize. If you expect a large number of large files, choose a larger blocksize.

The bytes-per-inode is 4096 by default. With a blocksize of 1024 this means that for every four data blocks there is one inode available. If you expect a large number of small files, decrease this value, since you will probably want one or two inodes per data block.

So...

The most important components of a filesystem are the inodes and the data blocks.

The filesystem is full ifNo more inodes are availableNo more data blocks are available

So tune your filesystem according to the number of bytes per file

Blocksize (1024, 2048 or 4096 possible)Bytes-per-inode (4096 default)




Uempty
In general, it is easier to explain to the users why a filesystem is full if there are no more data blocks left, than it is to explain that a filesystem is full if you ran out of inodes. And since an inode is smaller than a data block, you usually overestimate the number of inodes, just to be sure. The default values of mke2fs also do this.


Student Notebook

Figure 10-11. Other Filesystem Features LX033.1

Notes:

All filesystems are able to store your files, possibly under multiple names. They also all support the default UNIX permissions (rwxrwxrwx). They do however differ in the additional features that they can offer. Some of the features that can be offered by filesystems are:

• Access Control Lists: These are lists of user and/or group names with the permissions that these users/groups might have on the file. This allows you to set permissions that go further than the standard possibilities. It is for instance possible to define that a certain group is able to execute a program with the SUID bit set, and another group is able to execute it, but without the SUID bit.

Currently, the Linux kernel itself does not have support for ACLs, although certain filesystems may support it. A kernel patch is available to add ACL support to the Linux kernel, but this patch has not been integrated into the mainstream kernel (at the time of this writing).

• Journaling: This is a technique where every intended write action is first listed in a journal (a fixed-size file or other partition) and only then performed. If the action has succeeded, this is listed in the journal as well.

Other Filesystem Features

Filesystems can have other features that can be useful:

Access Control Lists (ACL)Allow more extended permissions, not just rwxrwxrwxNot yet supported by VFS abstraction layer

JournalingKeeps a journal of operations that are going to take place, and operations that were successfully committedMakes fsck far fasterSlight performance decrease

Extended file attributesExamples: immutable, auto compression, undeletable

LabelsAllow mounting based on label instead of device name

Performance optimizations




Uempty
This of course leads to a performance decrease, but yields one important benefit: When the system crashes, you don't have to do an fsck of the whole disk to look for inconsistencies, but just need to look at the journal and retrieve all transactions that were started but not finished. Only the disk areas that were involved in those transactions need to be searched.
An fsck on a crashed journaled filesystem will typically only take a few seconds, while a non-journaled filesystem may easily take several minutes, depending on the size of the filesystem.

• Extended File Attributes: This allows you to specify additional attributes of a file. An example is the immutable flag, which prevents anyone from modifying or deleting the file (even root), as long as this flag is set.

• Labels: These are labels that are attached to the filesystem itself (in the superblock). This allows you to specify a filesystem label instead of a device name in your /etc/fstab file. The advantage of this is that if you add or remove any disks and/or partitions, that your filesystems can still be found, even though they might now be located on a differently named device.

At the point of this writing, only the ext2/ext3 filesystem supports labels, and only Red Hat is configured to use them.

Apart from this, filesystems also differ in various optimization details. For example:

• Filesystems like ReiserFS and JFS do not use a linear list to hold the contents of a directory, but use binary or B+ trees for this. These trees are far faster to search and thus increase performance if you have a large number (1000 or more) files in one directory. This typically happens on news server, for instance.

• Some filesystems use a variable number of inodes, which are added and deleted when needed. This avoids the problem of running out of inodes, while you still have data blocks left.

• Filesystems may also use data blocks more efficiently, by storing multiple, smaller files in one data block.

• Some filesystems can work efficiently with “sparse files”. Sparse files are files which are mostly empty. They are the result of programs who open a new file for writing, and then lseek to a location somewhere in the file to write something there. The area before the written area is empty and need not be saved on disk - until the program actually starts writing there. Sparse files are common in databases.



Student Notebook

Figure 10-12. Creating a Filesystem LX033.1

Notes:

Once we have decided which block device we are going to use, and the type of filesystem we want, we are going to create it. This is usually done with some variation on the mkfs command, such as mke2fs2, mkreiserfs or mkjfs.

Typical options include the blocksize to use, and the bytes-per-inode number. This last number determines the number of inodes to create on the filesystem, and should reflect the average size of the files on your filesystem, rounded down to the nearest 2n kilobytes (1024, 2048, 4096, ... bytes).3

2 mke2fs is used to create an ext2 filesystem. mke2fs -j creates an ext3 filesystem.3 If you round up rather than down, then you will run out of inodes before you run out of data blocks. That's harder to sell to your users.

Creating a Filesystem

Creating a filesystem is done with an mkfs variantmke2fs, mke2fs -jmkreiserfsmkjfs

Typical options:-b blocksize sets blocksize-i bytes-per-inode sets number of inodes-c checks disk for bad blocks

Example:

# mke2fs -b 1024 -i 4096 -c /dev/hda6...Writing inode tables: doneWriting superblocks and filesystem accounting info: done...#




Uempty

Figure 10-13. Mounting a Filesystem LX033.1

Notes:

Mounting a filesystem is done with the mount command. The syntax is:

mount [-t <type>] [-o <options>] <device name> <mount point>

For instance: mount -t iso9660 -o ro /dev/cdrom /mnt/cdrom to mount the cd-rom device /dev/cdrom, which contains an iso9660 filesystem on the mount point /mnt/cdrom, read-only.

To show all mounted filesystems, use the mount command without arguments:

[root@sys1 /root]# mount /dev/hda2 on / type ext3 (rw) /dev/hda6 on /mountpoint type ext3 (rw) /dev/cdrom on /mnt/cdrom type iso9660 (ro) none on /proc type proc (rw) [root@sys1 /root]# _

Mounting a Filesystem

Using the mount command:Supply device nameSupply mount point (empty directory)

Optional: supply filesystem typeOptional: supply other options

Optional: use different superblock

To show mounted filesystems, use mount without arguments

# mount -t ext3 /dev/hda6 /mnt/extra# mount -o nodev,noexec /dev/system/mylv /usr/local/proj1



Student Notebook

Figure 10-14. Mounting Filesystems at System Startup LX033.1

Notes:

If filesystems need to be mounted automatically at system restart, or if you need to create shortcuts for fast mounting of common filesystems, add them to /etc/fstab. This file contains lines for each filesystem to be mounted. Every line consists of six fields:

• The block device which contains the filesystem.

Recent kernels also allow a “label” to be specified here, instead of the device. This is the label that is stored in the ext2/ext3 superblock. The kernel searches all ext2/ext3 filesystems for the filesystem holding this label and mount the first filesystem where the label matches. This is very useful if you make changes to your partition tables or the order of your disks (in particular, SCSI disks).

Labels are currently only supported on ext2/ext3 filesystems, and the use of these labels also requires modifications of utilities (for example, mount) and scripts. Only Fedora/Red Hat has made these modifications and uses filesystem labels by default. SuSE does not support filesystem labels at all.

• The mountpoint at which the filesystem needs to be mounted.

Add to /etc/fstab:

Mounting Filesystems at System Startup

/dev/hda1 /boot ext3 defaults 1 2/dev/hda5 / ext3 defaults 1 1/dev/cdrom /mnt/cdrom iso9660 noauto,ro,user 0 0/dev/fd0 /mnt/floppy msdos noauto,user 0 0/dev/hda6 /mnt/extra ext3 defaults 0 0

Alternative notation, using ext2/ext3 filesystem labels (used by Fedora/Red Hat)

LABEL=/boot /boot ext3 defaults 1 2LABEL=/ / ext3 defaults 1 1/dev/cdrom /mnt/cdrom iso9660 noauto,ro,user 0 0/dev/fd0 /mnt/floppy msdos noauto,user 0 0LABEL=extra /mnt/extra ext3 defaults 0 0




Uempty
• The type of the filesystem. Recent kernels also allow the “auto” type, which indicates that the kernel itself should try to figure out the filesystem type. This is useful for removable media, in particular floppy disks.
• The options.

• A dump indicator (see man fstab).

• A sequence indicator for fsck (see man fstab).



Student Notebook

Figure 10-15. Mount Options LX033.1

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.

Mount Options

Various options can be used when mounting a filesystem:auto: Mount fs automatically when bootingnoauto: Do not mount fs automaticallyuser: Users are allowed to mount this fsowner: Same as auto but user must be owner of devicero: Read onlyrw: Read-Write

For more options, see man mount




Uempty
ro - Mount the filesystem read-only
nodev - Do not allow usage of block and character special devices on the filesystem.

noexec - Do not allow execution of programs on the filesystem.

nosuid - Do not allow suid and sgid bits to take effect. nodev, noexec and nosuid are mainly used for security reasons.

For more options see man fstab and man mount.



Student Notebook

Figure 10-16. Unmounting Filesystems LX033.1

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

Unmounting Filesystems

Filesystem may not be in use -> check with fuserOpen filesPrograms being executedActive directories

Use the umount command with eitherThe device nameThe mount pointOr both

# fuser -v /usr USER PID ACCESS COMMAND

/usr root Kernel mount /usr

# umount /dev/cdrom# umount /mnt/cdrom




Uempty

Figure 10-17. Checking a Filesystem LX033.1

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.

Checking a Filesystem

Checking a filesystem is done automatically when the system boots

If a filesystem is cleanly unmounted, no further checks are doneMinor errors repaired automaticallyMajor errors drop you in a shell; allows you to do a more thorough check manually

fsck -y /dev/hda1

Can start filesystem checks manually as well with fsckOnly on filesystems that are mounted read-only or not mounted at all



Student Notebook

Although the implementation details may change, the general behavior of all these fsck programs is always the same:

• When the fsck program detects that the filesystem was unmounted cleanly, then no further checks are performed.4

• If the filesystem was not clean, the consistency will be checked. On a non-journaled filesystem this basically means that the whole filesystem needs to be scanned, while a journaled filesystem only needs to scan the filesystem areas which are listed as possibly dirty here.

• If minor errors are detected, then these are usually corrected automatically.

• If major errors are detected, then the system drops you into a shell and you need to fix these errors manually. This is typically done with the fsck -y command.

Filesystem checks can also be started by hand. This can only be done on filesystems that are not mounted at all, or are mounted read-only.

4 Cleanly unmounted means that the filesystem was properly unmounted. This allows the kernel first to bring the filesystem in aconsistent state, where all cached write actions are actually written out. As the last action, the kernel writes the “clean” bit to thesuperblock.




Uempty

Figure 10-18. ext2/ext3 Specific Information LX033.1

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.

ext2/ext3 Specific Information

ext3 adds journaling to ext2 using a special, hidden ".journal" file of arbitrary size (recommended: 10 MB)

Thus, downwards compatible with ext2For new ext3 filesystems, use mke2fs -jFor converting ext2 -> ext3, use tune2fs -j

Useful ext2/ext3 commands:tune2fs tunes an ext2 filesystemdebugfs debugs an ext2 filesystemchattr changes ext2 extended attributes of a file

ImmutableCompressedUndeletableAnd so forth (see man chattr for details)

e2label changes filesystem label of an ext2 filesystemresize2fs can resize an unmounted ext2 filesystem



Student Notebook

• chattr: Change attributes of files on an ext2 filesystem.

Files on an ext2 filesystem can have a number of additional attributes, which can be useful in some situations. Note that not all attributes are currently implemented by the Linux kernel.

• e2label: Change the filesystem label in the superblock. This label can be used in the first column of your /etc/fstab file.

• resize2fs: Resize an ext2 filesystem. The filesystem needs to be unmounted first, before it can be resized.




Uempty

Figure 10-19. ReiserFS-Specific Information LX033.1

Notes:

ReiserFS is a filesystem that was designed specifically for Linux by Hans Reiser. Two features stand out, compared to ext2:

ReiserFS uses a 32 MB journal by default. (Its minimum size is 513 blocks of 4k each, so a little over 2 MB.) This journal is usually part of the filesystem, but it can also be stored in a separate partition.

ReiserFS uses balanced trees instead of linear lists for indexing directories. This makes it useful for filesystems that hold a large number (1000+) files in one single directory.

Some useful commands for ReiserFS are:

• debugreiserfs: Debug a ReiserFS filesystem.

• resize_reiserfs: Resize a ReiserFS filesystem.

Extending a ReiserFS filesystem can be done without unmounting it, but if you want to reduce it in size, you need to unmount it first.

ReiserFS-Specific Information

Filesystem for Linux only, created by Hans Reiser

32 MB journal by default (minimum 2 MB)Thus, do not use ReiserFS for small filesystemsJournal may be in the filesystem itself or on a separate partition

ReiserFS uses balanced trees instead of linear directory lists

Extremely useful for directories which contain 1000+ files

Useful commands:debugreiserfs debugs a ReiserFS filesystemresize_reiserfs resizes a ReiserFS filesystem

Extending can be done on a mounted filesystemReducing can only be done on an unmounted filesystem



Student Notebook

Figure 10-20. JFS-Specific Information LX033.1

Notes:

JFS is the Journaling Filesystem from IBM's AIX and OS/2, which was ported to Linux and made available under the GPL. Like ReiserFS, it decided not to use linear lists for directories, but uses B+ trees.

JFS will also support ACLs in the near future.

Some useful JFS commands are:

• extendfs: Extend a JFS. For this, the filesystem does not need to be unmounted. Reducing a JFS is not possible.

• xpeek: This allows you to debug a JFS.

JFS-Specific Information

Journaling filesystem from IBM AIX / OS/2

Uses B+ trees for fast directory indexing

Will support ACLs in the future

Useful commands:extendfs extends a JFS filesystem

Can be done without unmounting firstJFS does not support reducing a filesystem

xpeek allows you to debug a JFS filesystem




Uempty

Figure 10-21. Comparing Filesystems LX033.1

Notes:

The visual shows a quick comparison of the filesystems we mentioned here. Also included is XFS, the filesystem that was donated to Linux by SGI. XFS is not used in the major distributions though.

Note that the maximum size for files and filesystems shown is always calculated when the maximum blocksize is used. In addition to this, the kernel or your application may not support files or filesystems of the sizes mentioned.

For reference:

• A kilobyte is 1024 (210) bytes. • A megabyte is 1024 kilobyte, or 220 bytes. The capacity of a CD is about 650 megabyte. • A gigabyte is 1024 megabyte, or 230 bytes. The largest PC hard disks currently available

are about 250 GB in size. • A terabyte is 1024 gigabyte, or 240 bytes. • A petabyte is 1024 terabyte, or 250 bytes. • An exabyte is 1024 petabyte, or 260 bytes.

Comparing Filesystems

Journaled Filesystems used by Linux:

ext2 ext3 jfs reiser xfs

Journal noyes

(10 MB default)

yes(auto

resized)

yes(32 MB default)

yes

resizeableyes, but

only when unmounted

yes, but only when

unmountedyes yes

yes - only when mounted

maximum size

File: 2 TBFS: 16 TB

File: 2 TBFS: 16 TB

File: 4 PBFS: 32 PB

File: 16 TBFS: 1 EB

File: 2 TBFS: 8 EB

type

I-Nodes (completely

block oriented)

I-Nodes (completely

block oriented)

I-Nodes (allocated in a b-tree)

B-TreeI-Nodes

(allocated in a b-tree)



Student Notebook

Figure 10-22. SHMFS-Specific Information LX033.1

Notes:

The last filesystem we want to cover here is the Shared Memory Filesystem, or SHMFS in short. It is a POSIX compliant filesystem, which resides in memory. You can think of SHMFS as a RAM disk formatted as a filesystem. The difference is that SHMFS automatically grows and shrinks as needed, while formatting a RAM disk would yield a filesystem with a fixed size. But as with a RAM disk, it is not persistent across a reboot.

Most distributions enable an SHMFS by default, typically mounted on /dev/shm. Red Hat does this with an entry in /etc/fstab, while SuSE enables it from /etc/init.d/boot.swap, which in turn is called from /etc/init.d/boot. The maximum size of the SHMFS is configurable, but is usually set to half the amount of real memory in the system.

SHMFS is required by certain applications, among which Apache, Oracle, and SAP.

SHMFS-Specific Information

SHMFS: POSIX compliant Shared Memory Filesystem

Filesystem stored in memory, expands when used to required size

Not persistent across reboot

Typically mounted on /dev/shm

Required by certain applications




Uempty

Figure 10-23. Quota Concepts LX033.1

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.

Quota Concepts

Quota limit the amount of data a user/group is allowed to store

Defined on a per-filesystem basis

Based on block and/or inode usage per user or group

Per quota two limits: Soft and HardUser exceeds soft limit -> warning onlyUser exceeds hard limit -> error

Grace period identifies how long the soft limit may be exceeded

After that period, a user gets errors instead of warnings

20 MB

Filesystem 300 MBeach user may consume only 20 MB permanently and 25 MB temporarily

5



Student Notebook

Figure 10-24. Quota Implementation on Linux LX033.1

Notes:

Quota support in Linux is compiled into the kernel, so you don't need to run extra daemons. What you do need to do is indicate that a certain filesystem uses quota when that filesystem mounts. This is done with two mount options: usrquota and grpquota. After mounting, you need to turn quota on with the quotaon command. In addition to that, you also need to specify the quota themselves. This is done in the files aquota.user and aquota.group5 in the root of the filesystem.

5 Earlier implementations used the quota.user and quota.groups file. To convert the old format in the new format, use convertquota.

Quota Implementation on Linux

Quota support compiled into the kernelNo daemon necessary

Implemented on a per-filesystem basisA user can have different quota on different filesystemsStored in aquota.user and aquota.groups in the root of the filesystem

Quota checking should be enabled when mounting the filesystem

Mount options: usrquota, grpquotaCan be specified in /etc/fstab

Quota checking should be turned on after mounting with the quotaon command

Automatically executed from bootscript after mount -a




Uempty

Figure 10-25. Enabling Quota LX033.1

Notes:

So how do we go about enabling quota? The first step is to change the /etc/fstab file to indicate that a certain filesystem uses quota. Obviously we will want to enable quota every time the system boots, that's why we specify it here.

The next step is remounting the partitions. This ensures that all options are re-read from the /etc/fstab file.

Now that quota are enabled on this filesystem, we need to calculate the actual usage, and store this in the aquota.user and aquota.group file. This is done with the quotacheck command.

Finally, we have to turn the quota on with the quotaon command. Quota checking is now fully functional.

Enabling Quota

Modify /etc/fstab

Create aquota.user and aquota.group in the filesystem's root directory

Remount the partition

Calculate current usage and turn on quota checking

/dev/hda2 / ext3 defaults 1 1/dev/hda4 /home ext3 defaults,usrquota,grpquota 1 2/dev/hdb /mnt/cdrom iso9660 noauto,owner,ro 0 0/dev/hda3 swap swap defaults 0 0/dev/fd0 /mnt/floppy msdos noauto,owner 0 0none /proc proc defaults 0 0none /dev/pts devpts gid=5,mode=620 0 0

# touch /home/aquota.user /home/aquota.group# mount -o remount /home# quotacheck /home# quotaon /home



Student Notebook

Figure 10-26. Configuring Quota LX033.1

Notes:

After quota checking is turned on, we can specify the quota per user or group. This is done with the edquota command.

edquota is a somewhat strange command. It reads the aquota.user and aquota.group file (which are binary files), extracts the relevant information and writes it to a temporary file. It then starts your favorite editor (identified with the $EDITOR shell variable) and lets you edit this temporary file. After you finished, it will read the contents of the temporary file and merge it back into the aquota.user and aquota.group file. For this reason, you should be careful editing the temporary file. If you change the wrong fields, edquota will get confused and will not do what you expected it to do. You are only supposed to edit the fields under “soft” and “hard”: four fields per filesystem in total.

The syntax of edquota is really straightforward. Use the -u option to edit user quota, use the -g option to edit group quota, and use the -t option to edit the grace period (which is the same for everyone on the system).

Configuring Quota

Done with the edquota commandStarts $EDITOR (default: vi) in a subshellOnly edit the block/inode soft/hard quota numbers!

User quota: edquota -u <username>

Group quota: edquota -g <groupname>

Grace period: edquota -t

Copy quota: edquota -p tux1 -u tux2 tux3 tux4

Disk quotas for user tux1 (uid 501):Filesystem blocks soft hard inodes soft hard/dev/hda4 10700 20000 25000 407 0 0/dev/hda9 320 300 350 23 30 50~~~"/tmp/Edp.a9fSEQK" 3L, 213C




Uempty
A very useful feature of edquota is the copying of quota information. If you want tux2, tux3 and tux4 all to have the same quota limits as tux1, just run the command edquota -p tux1 -u tux2 tux3 tux4 and you're done.


Student Notebook

Figure 10-27. Quota Information LX033.1

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.

Quota Information

quota commandReports on the quota of one userCan be executed by anyoneA regular user can only view his own quota

repquota commandReports on the quota of all users and groupsCan only be executed by root

tux1$ quotaDisk quotas for user tux1 (uid 501):Filesystem blocks quota limit grace files quota limit grace/dev/hda4 10700 20000 25000 407 0 0

root# repquota /dev/hda4 Block limits File limitsUser used soft hard grace used soft hard graceroot -- 848804 0 0 56892 0 0 . tux1 ++ 1500 1000 1500 7days 112 112 115 nonetux2 -- 176 1000 1500 44 0 0




Uempty


Notes:


1.

2.

3.

Checkpoint

Assuming a blocksize of 1024, how many inodes and data blocks do you need for a file on an ext2 filesystem

a. with size 0?b. with size 1?c. with size 2000?d. with size 12289 (12 K+1)?

______________________________________________

What are the two methods of copying a file to a (not yet mounted) MS-DOS floppy?

______________________________________________

What files are important with respect to quotas?

______________________________________________

1)

2)

3)



Student Notebook


Notes:

Unit Summary

What is a file?

What is a filesystem?

Supported filesystems

Inodes

Creating/mounting/unmounting filesystems

Predefined mounts

Quota




Uempty
Unit 11. Memory Management

This unit will teach you how Linux manages its memory.



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


Accountability:



© Copyright IBM Corp. 2001, 2004 Unit 11. Memory Management 11-1

Student Notebook


Notes:

Unit Objectives


Describe the principles of memory management in Linux

Create paging space partitions

Create paging space files




Uempty

Figure 11-2. Linux Memory Management LX033.1

Notes:

Linux memory management uses a very simple but effective scheme: About one megabyte of your memory is used for the kernel program and kernel data. This area, on Intel systems, also holds the memory area for devices (640 KB - 1 MB). That means that roughly the first megabyte of your system cannot be used for applications. The rest of your real memory is used for processes. If all processes combined use more memory than is available, pages will be paged out to disk into paging space. If there is memory to spare in your system, it will be used for caching data from disk. On Intel-32 (the 386 up to and including the Pentium), Linux can use a total of 4 GB of real memory. Starting with the Pentium Pro and later models, sometimes written down as i686, Intel added PAE, which stands for Processor Address Extension. This allows memory addresses of 36 bits to be used instead of 32 bit, and thus extends the total amount of real memory on the system to 64 GB. Individual applications however are still limited to 32 bit addresses and thus cannot allocate more than 4 GB.1 On 64-bit architectures, the total amount of addressable real memory is 16 Exabyte. That's more than the total amount of memory that has been produced so far on this planet.

1 Technical issues under Linux currently limit this to 3 GB.

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

Figure 11-3. Example: Lightly Loaded System LX033.1

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




Uempty

Figure 11-4. Example: Heavily Loaded System LX033.1

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



Student Notebook

Figure 11-5. Creating Paging Space LX033.1

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 volume or a regular file (not recommended, poor performance)

Partition type 82 (Linux swap)

Create paging space in that partition

Activate paging space

Deactivating paging space is done using swapoff

Check swap space in procfs

# mkswap /dev/sda3

# swapon -p 42 /dev/sda3

# cat /proc/swapsFilename Type Size Used Priority/dev/sda3 partition 65563 4096 42




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

If you want to make your swap space permanent, you can add this to /etc/fstab, just like a filesystem.



Student Notebook

Figure 11-6. Useful Commands LX033.1

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

sync flushes the cache to disk

xosview graphically displays a system overview

xload graphically displays system load

xsysinfo graphically displays system information

vmstat displays memory and other statistics every second

procinfo displays processor statistics




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



Student Notebook


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:

Unit Summary

Memory management

Paging space partitions

Paging space files

Useful commands



Student Notebook



Student NotebookV1.2.2 VISUNIT

Uempty
Unit 12. Linux on IBM eServer
What This Unit is About

This unit describes the various IBM architectures that Linux runs on, lists their main characteristics, advantages and disadvantages, and lists the issues that are important in determining which IBM eServer is best suited for your workload.



• Describe how businesses are using Linux

• List the main features of the IBM eServer brands

• List the considerations involved in selecting an IBM eServer for your workload


Accountability:

• Checkpoint


© Copyright IBM Corp. 2001, 2004 Unit 12. Linux on IBM eServer 12-1

Student Notebook


Notes:

Unit Objectives


Describe how businesses are using Linux

List the main features of the IBM eServer brands

List the considerations involved in selecting an IBM eServer for your workload




Uempty

Figure 12-2. How Customers are Using Linux LX033.1

Notes:

Linux is a general purpose operating system. As such, it can be used for a variety of workloads. The five main workloads that Linux is used for today are:

• Workload Consolidation

• Linux Clusters

• Distributed Enterprise

• Application Solutions

• Infrastructure Solutions

These five workloads will be covered in detail in the next few visuals.

© 2003 IBM Corporation

How Customers are Using Linux

Workload Consolidation Linux Clusters

Distributed Enterprise

Infrastructure SolutionsApplication Solutions



Student Notebook

Figure 12-3. Workload Consolidation LX033.1

Notes:

The first workload that Linux is typically used for is Workload Consolidation. It’s actually not a workload, but more a process of consolidating all the different workloads that are running on all your machines onto one or a few Linux machines.

Most organizations buy a new computer system for each new application that they’re going to run. After a few years, this leads to a variety of hardware vendors, architectures, operating systems and applications that don’t scale well and are hard to manage.

When consolidating workloads, you are buying one or a few identical servers that are able to handle all the different applications in your organization. Once these servers are configured, you start migrating one application at the time from the legacy server to the new server farm. This eventually leads to uniformity in configuration, savings on hardware costs and easier management.

Note that moving your application to one or a few servers doesn’t have to mean that they all run on the same instance of the operating system. Most IBM architectures support virtualization or partitioning of hardware, so that each application still runs on its own server. You just run multiple servers on one box. This will be discussed later.

Workload Consolidation

Workload currently spread over a large number of individual servers (different architecture, OS, version, capacity)

Consolidate onto one or a few identical servers

Advantages:

Homogeneous environment leads to easier management

Cost saving

Examples:

File, Print services

Web servers

Database servers

Mail servers




Uempty

Figure 12-4. Linux High-Performance Clusters LX033.1

Notes:

A lot of parallel processing supercomputers today are based on Linux because of its low cost, remote management capabilities, flexibility and performance in general. Linux supercomputers have found their way into life sciences, geophysics, weather forecasting, the movie industry and a variety of other places.

Linux High-Performance Clusters

When supercomputer performance is needed for a microcomputer price

Typical applications:

Life sciences (protein folding, cancer research)

Geophysics (oil exploration, earthquake prediction)

Weather forecasting

Movie industry



Student Notebook

Figure 12-5. Distributed Enterprise LX033.1

Notes:

A distributed enterprise is an enterprise with one or a few head offices, where ICT staff is located, and a lot of branch offices that need basic computer services, such as file and print services, checkout desks, inventory tracking and so forth. An important characteristic is that there is no or virtually no ICT staff present at the branch offices: all maintenance and support is done from the head office. For this reason, reliability and remote maintenance are important characteristics for the servers that are located in the branch offices.

Examples of distributed enterprises are restaurant franchises and the retail industry.


Enterprise with a lot of branch offices that need basic computer services at each office


Checkout desks

Inventory tracking

Examples:

Restaurant franchises

Retail industry




Uempty

Figure 12-6. Application Solutions LX033.1

Notes:

With application solutions we mean that large, mission-critical applications are run on Linux. Examples of these architectures are databases, transaction monitoring software, Enterprise Resource Planning applications and large Web servers.

Running mission-critical applications on Linux

Examples:

DB2, Oracle

MQ Series

PeopleSoft

SAP

WebSphere

Application Solutions



Student Notebook

Figure 12-7. Infrastructure Solutions LX033.1

Notes:

Every computer network needs a number of low-level services to support various network operations. Examples of these services are DHCP, DNS, File and Print services, routing, firewalls, VPNs, Network Monitoring, Intrusion Detection and Backup services.

For this, small Linux machines are used a lot.

Infrastructure Solutions

Low-level services that are needed in each computer network

Examples:

DHCP

DNS


Routing

Firewalls

VPN services

Network Monitoring and Intrusion Detection

Backup services




Uempty

Figure 12-8. And How About Linux on the Desktop? LX033.1

Notes:

Linux is well established on the server right now, and a lot of people are talking about Linux on the desktop. The actual market share of Linux on the desktop however is still so small that this is not an official IBM strategy. But of course we’ll support everyone who asks. And for IBM internal, an easy-to-install desktop, based on Linux and running all important IBM internal applications, including Lotus Notes, is available.

And How About Linux on the Desktop?

Not an official IBM strategy (yet), but...

Internal Linux-based desktop is available (client for e-business) and fully supported

Will support customers if they ask for it

Solutions:

WINE, CrossOver Office

win4lin

StarOffice/OpenOffice

VMWare



Student Notebook

Figure 12-9. Introducing the IBM eServer Brand LX033.1

Notes:

The IBM eServer brand was introduced a few years ago. It’s a consolidation of all the original IBM server brands (RS/6000, AS/400, S/390 and Netfinity) under one common name. Within the eServer brand, four series can be distinguished:

• IBM eServer iSeries (formerly known as AS/4000): For Integration

• IBM eServer pSeries (formerly known as RS/6000): For Power

• IBM eServer zSeries (formerly known as S/390): For Zero downtime

• IBM eServer xSeries (formerly known as Netfinity): For eXtendable

Obviously, all of these -series run their own native operating systems, such as OS/400, AIX, OS/390 and Windows. But they all run Linux as well: IBM has made sure that the Linux kernel natively supports all architectures, and that the main Linux business partners (Red Hat and SUSE) have enterprise versions of their distributions available for all four architectures.

But the IBM eServer brand is more than just the sum of its parts. As part of project eLisa, various technologies have been ported between the different series. Because of that, for

Introducing the IBM eServer Brand

Consolidation of the names RS/6000, AS/400, S/390, Netfinity in one brand name

Porting of technology between all -series (project eLiza)

Reliability, Availability, Serviceability (RAS)

Four series:

iSeries (FKA AS/400) - Integration

pSeries (FKA RS/6000) - Power

zSeries (FKA S/390) - Zero downtime

xSeries (FKA Netfinity) - eXtendable

All -series run their original respective operating systems

All -series run Linux natively

All -series fully supported by Red Hat (RHEL) and SuSE (SLES)




Uempty
example, the xSeries servers now support ChipKill memory. ChipKill is a technology where a two-bit error can be corrected. Compare this to regular ECC memory, which can only correct one-bit errors.


Student Notebook

Figure 12-10. IBM eServer xSeries LX033.1

Notes:

The IBM eServer xSeries brand is the brand which uses Intel or Intel-compatible CPUs. It’s available in 32-bit and 64-bit variants.

Linux runs natively on this architecture because this is the architecture that Linux was developed for, initially, and the architecture that’s in use by most Linux developers. Because of this, it’s the most popular architecture to run Linux on.

Intel and AMD are currently both marketing 64-bit processors: the Intel Itanium and the AMD Opteron. xSeries machines can be obtained with any of these processors. However, there is not much experience with these chipsets, and most people are still a little hesitant to use these for mission-critical applications without thorough testing.

Compared to other IBM architectures, the xSeries architecture is quite simple though. The main drawback is that it doesn’t have any hardware/microcode support for partitioning your system into multiple machines. If you want partitioning, you have to use VMware ESX/GSX server.

xSeries = Intel compatible

Intel-32 (Pentium, Xeon)

Intel-64 (Itanium)

AMD-64 (Opteron)

Architecture that Linux was developed for, originally

Architecture in use by most Linux developers

Architectural limitations:

32-bit limits memory to 4 GB (64 GB with PAE)

64-bit only now becoming available, but not much experience yet

VMWare ESX/GSX server allows virtualization

IBM additions (project eLiza):

Chipkill memory (corrects 2-bit errors)

Lightpath diagnostics

Service Processor

IBM eServer xSeries




Uempty
As said before, IBM has made several additions to the standard Intel architecture. These additions are the result of project eLiza:
• ChipKill memory

• Lightpath diagnostics: a blinking LED next to the failed component will indicate to a service technician which component has failed and needs replacement

• Service Processor: Independently monitors the health of the system, and can alert the administrator of any anomalies.



Student Notebook

Figure 12-11. VMware ESX/GSX Server LX033.1

Notes:

VMware ESX/GSX server is a commercial product (http://www.vmware.com) that “splits” your hardware into virtual machines. Each of these virtual machines can run its own operating system, with its own kernel, root password, IP address and so on. That makes it easy to separate functionality and create identical test-, staging- and production environments without investing in a lot of hardware.

Since VMware is a software-solutions, you will have to consider a performance loss. This is typically a few percent only, but can occasionally reach 30%, depending on your workload.

VMware ESX/GSX Server

Commercial product that "splits" your Intel-32 system into virtual machines

No support for Intel-64, AMD-64 or other architectures

Main system:

Max 64 GB memory

Max 16 CPUs

Split into 64 virtual machines

3.6 GB memory

4 SCSI adapters

4 serial (COM) ports

2 printer (LPT) ports

4 Ethernet NICs




Uempty

Figure 12-12. IBM eServer iSeries LX033.1

Notes:

The IBM eServer iSeries, formerly known as AS/400, is based on the PowerPC chip. Recent iSeries machines can be split into multiple Logical Partitions, each running a different operating system. At least one of these partitions needs to run OS/400 for LPAR management.

All partitions are connected to each other using a virtual LAN. This means that all these partitions can communicate with each other with speeds that approach memory-to-memory copy speed.

iSeries = PowerPC chip

Recent versions allow system to be split in Logical Partitions, each running a different OS (OS/400 or Linux)

Current models: max 32 LPARs, future models will support more

At least one OS/400 LPAR is required for management

Operating Systems in LPARs can communicate using virtual LAN

LPAR1

OS/400

V5R1

LPAR2

OS/400

V4R5

LPAR3

Linux

Primary Partition

LPAR4

Linux

IBM eServer iSeries



Student Notebook

Figure 12-13. IBM eServer pSeries LX033.1

Notes:

Just like the iSeries, the pSeries is also built around a PowerPC chip. In fact, the iSeries and pSeries have more hardware in common.

Just like with iSeries, a pSeries machine can be split into a number of Logical Partitions, each running a different operating system. There is one slight difference between iSeries and pSeries here: pSeries LPAR requires a Control Workstation (a separate machine) to manage the LPARs.

Again, the operating systems in the various partitions can communicate with each other using a virtual LAN.

pSeries = PowerPC chip

Recent versions allow system to be split in Logical Partitions, each running a different OS (AIX or Linux)

Current models: 16-32 LPARs, future models will support more

Control Workstation (CWS) required for management

IBM eServer pSeries




Uempty

Figure 12-14. IBM eServer zSeries LX033.1

Notes:

The IBM eServer zSeries is sometimes still referred to as a mainframe. It’s a system which traditionally already allows for a mixed workload, consisting of various operating systems (VSE, VM, OS/390, MVS, z/OS) with different tasks, interactive or batch oriented.

Because of this mixed workload, it was the first architecture to receive virtualization/partitioning technology. This was initially only done using VM (Virtual Machine), which was a software-only implementation. Later systems also received LPAR, which allows hardware/microcode partitioning.

Linux can run natively, in an LPAR or under VM. Especially VM is interesting, since it allows you to run literally hundreds of Linux instances on a single box. And reasonably efficient too: VM was optimized for the mainframe, but the mainframe hardware is also optimized for running VM. This means that VM only incurs an overhead (performance loss) of about 1%.

When running Linux on zSeries, you have to be aware of something called the Integrated Facility for Linux. The story behind this is as follows: Mainframe software licenses are based on the number of processors that are actually used1. This means that most 1 All mainframes have multiple processors, and these can be enabled/disabled at will.

zSeries = Mainframe

One system traditionally allows virtual machines for a mixed workload

VM: Software partitioning

LPAR: Hardware/microcode partitioning

Linux can run native, in an LPAR or under z/VM (100s of virtual machines possible)

Integrated Facility for Linux (IFL) allows you to use spare processors for Linux (and z/VM running Linux) without incurring additional software charges for legacy environments

VM or IBM zSeries Virtual Image

Facility for Linux

Linux for zSeries images

Single purposeInternet-related

servers

Server farms

Inter Partition Communication

zOS*zOS*

IBM eServer zSeries



Student Notebook

mainframes have spare processors available that are sitting idle all day long. If the customer would start using these processors for Linux, then their license charges for their legacy operating system would increase as well. Not something a customer likes to see, of course.

Enter the IFL. This is a special mode in which a processor can be activated. When in this mode, the processor can run Linux and z/VM, but cannot run any legacy operating systems, such as OS/390. Because of this, IFL processors are not influencing the legacy operating systems license fees.




Uempty

Figure 12-15. IBM eServer BladeCenter LX033.1

Notes:

The IBM eServer BladeCenter is a recent development. It mainly consists of two parts: a BladeCenter chassis and Server Blades.

The BladeCenter chassis is a box, 7U or 8U in height, containing the power supply, KVM switch, floppy drive, CD drive and various attachments and options, but no CPU, memory. Instead, it has up to 14 bays (depending on model) in which a Server Blade can be put.

A Server Blade is a fully self-contained server with CPU, memory, disks, network adapters and so forth, which slots into a BladeCenter chassis. It takes power from the chassis and connects to the chassis KVM switch but it otherwise fully independent. Currently, three different Server Blades are available:

• HS20: One to two Intel Xeon processors

• HS40: One to four Intel Xeon processors

• JS20: Two PowerPC 970 processors

The advantage of a BladeCenter solution is obvious: it allows you to pack far more CPUs in a rack than what would be possible with regular 1U servers. A second advantage is that it

BladeCenter Chassis: Chassis containing power units, networking attachments, FD and CD, and space for up to 14 "server blades"

Server Blade: Fully contained system (CPU, memory, disk) which slides into a BladeCenter Chassis

Currently available blades:

HS20: 1-2 way Intel Xeon (32 bits)

HS40: 1-4 way Intel Xeon (32 bits)

JS20: 2 way PowerPC 970 (64 bits)

Advantage of BladeCenter vs separate servers:

High density: over 100 processors in a rack

Easy maintenance and addition of new servers: 80% less cabling required

Disadvantage:

Limited server upgrades (disks, network adapters, peripherals) possible: Use a SAN if you need more disk space

Considerations: Weight, Power, Cooling

IBM eServer BladeCenter



Student Notebook

is far easier to install and manage blades: a typical BladeCenter requires 80% less cabling than a regular rack-mounted server setup.

There is also a disadvantage to a BladeCenter: because of the physical dimensions of a single blade, it is impossible to extend a blade with more accessories, such as additional disk drives, network adapters and the like. If you need that capability, you have to use stand-alone or rack-mounted servers, or (for additional disk space) use a SAN (Storage Area Network).

When buying a BladeCenter, make sure you perform your calculations for power, air conditioning and weight correctly!




Uempty

Figure 12-16. IBM eServer Comparison LX033.1

Notes:

The chart above summarizes the previous visuals.

Note that the kernel version that is used in current Linux distributions, 2.4, does not scale well beyond eight processors. If your system has more than eight processors, some form of virtualization (VMWare, LPAR or VM) is recommended. The 2.6 kernel is expected to scale far better.

eServer Architecture bits max # processors virtualization

xSeries Intel-32 32 1 (Pentium)4 (Xeon)32 (Xeon MP) (*)

VMWare

Intel-64 32/64 4 (Itanium 2) -

AMD-64 32/64 2 (Opteron) -

pSeries POWER4+ 32/64 16 (*) LPARiSeries POWER4+ 32/64 16 (*) LPAR

zSeries z/Architecture 32/64 32 (*) LPAR, VMBladeCenter Intel-32 32 4 (Xeon) VMWare

POWER4+ 32/64 2 -

(*) Current Linux distributions, using the 2.4 kernel, do not

scale well beyond 8 processors; virtualization recommended

IBM eServer Comparison



Student Notebook

Figure 12-17. Which is “the Best” for Running Linux? LX033.1

Notes:

We’ve seen that all IBM eServer brands run Linux natively, and are fully supported by IBM, Red Hat and SuSE. We therefore have a choice of architecture on which to run our workload. But which architecture is the best? That depends on a large number of factors. Here are the most important considerations:

• Performance and scalability requirements with regards to CPU (number and speed), memory, disk space and network.

• Cost and budget

• Communication/collaboration with existing applications

• Availability of spare/unused hardware or capacity

• Current expertise

• Application availability: Not all ISVs support their applications on all architectures.

Which is "the Best" for Running Linux?

All -series run Linux natively

All -series are fully supported by IBM, Red Hat and SuSE

The best architecture depends on a number of factors:

Performance and scalability requirements (CPU, SMP. virtualization, memory, disk, network)

Cost/Budget

Communication/Collaboration with existing applications

Available "spare" hardware/unused capacity

Current expertise

Application availability (not all ISV applications are supported on all architectures)




Uempty

Figure 12-18. Workloads Revisited LX033.1

Notes:

The issues mentioned in the previous visual play out differently for the various workloads that we’ve discussed so far. So we’re revisiting our workloads again to see how things work out.

Workloads Revisited

Workload Consolidation Linux Clusters


Infrastructure SolutionsApplication Solutions



Student Notebook

Figure 12-19. Workload Consolidation LX033.1

Notes:

When you are doing Workload Consolidation, the most important consideration is whether the architecture that you’d like to use supports your application(s). If you’re consolidating standard Open Source software such as Samba or Apache, you’ll find that all these applications run on any architecture. But applications from commercial vendors might only be compiled for one or two architectures. In that case, obviously, your choice is limited.

Other considerations are the scalability of the architecture and the availability and suitability of virtualization technology. And last: if the application you are consolidating onto a Linux system requires a lot of communication with a legacy application, then you might want to consolidate onto the architecture where your legacy application runs. Having both on the same box means that you can use the internal, virtual network (LAN or otherwise) for communication.

Depending on these issues, all of the IBM eServer architectures may be suitable.


Important considerations:

Does the architecture support your application?

Is the architecture scalable enough for current workload and future growth?

Do you need LPAR or other virtualization technology to logically separate workloads on one physical box?

Do you need to communicate/collaborate with a legacy application?

Architectures recommended:

All - Depends on application availability, required scalability and existing expertise




Uempty

Figure 12-20. Linux HPC Clusters LX033.1

Notes:

When using Linux for high-performance clustering, the most important consideration is typically to get the most “bang” for your “buck”. In other words: the ratio between price and performance is all-important. Other considerations are the manageability of 100s or 1000s of identical systems, and the network bandwidth and memory size of each individual node.

Considering the price and performance of the IBM eServers, you will typically want to look at the xSeries or pSeries architecture. For “average” clusters, xSeries and pSeries perform about as well. But pSeries clusters are capable of scaling farther and deeper: you will want to use them if you want to do massive SMP (more than 16 processors), when you need to support a huge amount of memory (more than 64 GB per node), or when 64-bit floating point operations are required.

Granted, xSeries machines have 64-bit processors as well. But these processors are fairly new and there’s not much experience with them. You need to consider that you’re one of the first using that new technology if you use xSeries 64-bit.

When doing High Performance Clustering, you will definitely have to look at BladeCenters too. Since most HPC applications only require a fast CPU, a reasonable amount of

Linux HPC Clusters


Price per node

CPU Performance

Manageability of 100s or 1000s of identical systems

For some applications: network bandwidth and/or memory size

Recommenced architectures:

pSeries or xSeries for "average" clusters

pSeries for massive SMP, when a huge amount of memory is required per node, or 64-bit floating point operations are required

Consider BladeCenter (xSeries or pSeries)



Student Notebook

memory, and one network adapter, BladeCenters are ideal for creating Linux High Performance Clusters. And the ability to mix and match xSeries and pSeries blades might be beneficial too.




Uempty

Figure 12-21. Distributed Enterprise LX033.1

Notes:

For distributed enterprises, the most important factor is the total cost, including maintenance, per box. That means that features such as remote management and easy on-site maintenance and repair are key. Performance is typically not an issue, and the reliability of todays hardware is typically good enough.

Because of these issues, all else being equal, the xSeries is usually the best choice. There is one exception to this: if for some reason an AIX or OS/400 application is needed on-site too, then you will want to use an LPAR-capable machine running Linux and AIX or OS/400 simultaneously.



Low cost per box

High but not extreme reliability

Remote management

Easy on-site maintenance and repair

Performance is typically not an issue

Recommended architectures:

xSeries

pSeries or iSeries if you also need an AIX or OS/400 application on-site



Student Notebook

Figure 12-22. Application Solutions LX033.1

Notes:

The issues that are important in application solutions are nearly the same as the issues in workload consolidation: the single most important factor is whether the application you want to run is supported by the architecture. Other factors are:

• Scalability of the architecture

• Current expertise and installed base

• Communication to legacy applications

Depending on these requirements, all four IBM eServer architectures are candidates.



Which architecture is supported by your application and -vendor?

Which architecture scales enough for your application

Current experience

Current installed base

What communication to legacy applications is required


All - Depends on application availability, required scalability and communications requirements




Uempty

Figure 12-23. Infrastructure Solutions LX033.1

Notes:

When installing infrastructure servers, the most important consideration is typically the cost per box, since performance is not an issue at all. Other considerations are remote management, easy on-site maintenance and repair, and security. In fact, the issues are largely the same as with distributed enterprise, and so is the obvious choice: xSeries.

Again, there is an exception here: You can also run these infrastructure solutions on any of the other architectures, provided that existing machines have spare capacity available, and their network location is convenient.



Low cost per box

High but not extreme reliability

Remote management

Easy on-site maintenance and repair

Performance is typically not an issue

Security


xSeries

iSeries, pSeries or zSeries if you have spare capacity on existing hardware and their network location is convenient



Student Notebook

Figure 12-24. ...And On the Desktop? LX033.1

Notes:

We’ve said it before: Linux on the desktop is not an official IBM strategy, but we’ll support customers if they ask for it. As for platform choice, most people will use xSeries or ThinkPads for desktop usage. There are basically two reasons for this:

• ThinkPads and xSeries machines are the only machines with a convenient form factor for laptop or desktop use.

• You need an Intel-compatible CPU in order to run the various solutions that allow Windows integration: WINE, CrossOver Office, win4lin and VMware.

For deskside use, in addition to xSeries, you can also use pSeries machines. That is a solution that is sometimes seen for scientific and development workstations, and often the user of such a machine will have an Intel-machine on or near his desk as well.

...And On the Desktop?

The only IBM architecture that has a convenient form factor for desktop/laptop use is the xSeries/ThinkPad

IBM eServers with deskside form factor: xSeries and pSeries

Advantage of xSeries:

Can dual-boot with Windows

Can run VMWare, WINE and others for Windows compatibility

Is the only architecture that supports APM and ACPI (Power Management)




Uempty


Notes:

Checkpoint

Name the six main types of Linux usage, today:

______________________________________________

What is a BladeCenter?

______________________________________________

What is the main consideration when determining the architecture on which you want to run an ISV application?

______________________________________________

1)

2)

3)



Student Notebook


Notes:

Unit Summary

The reasons Linux is used most, today, are:


High Performance Clusters




IBM has four main eServer architectures: iSeries, pSeries, xSeries and zSeries, and Linux runs natively on all four of them

A BladeCenter chassis can contain both Intel Xeon and PowerPC-based blades

The architecture for your workload depends on a number of factors:

Availability of your application on that architecture

Cost, budget

Current experience

Performance, scaling requirements

Interoperability requirements with other legacy applications

Availability of spare/unused hardware




Uempty
Unit 13. Scheduling

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



• Use crontab files to schedule jobs on a periodic basis • Use anacron to schedule jobs on a workstation • Use the at command to schedule jobs or series of jobs at some

time in the future • Use the batch command to schedule jobs in a queue, to alleviate

immediate system demand


Accountability:



© Copyright IBM Corp. 2001, 2004 Unit 13. Scheduling 13-1

Student Notebook


Notes:

Unit 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 13-2. Scheduling LX033.1

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 13-3. Cron LX033.1

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.

Cron

Cron is used for repeating tasks (jobs)

Jobs are configured by adding them to a crontab file

crontab files are stored:In /var/spool/cron (Red Hat)In /var/spool/cron/tabs (SuSE)

A crontab entry has the following syntax:<hour> <minute> <day> <month> <weekday> <cmd>

To regulate the use of crontab, list the users involved in one of the following files:/etc/cron.allow (strongest) and /etc/cron.deny (Red Hat)/var/spool/cron/allow and /var/spool/cron/deny (SuSE)




Uempty
Being able to schedule tasks is really useful for recurring tasks that you don’t want to think about every hour, day or week. Examples include:
• Backups

• Periodically checking whether key processes are still running

• Periodic cleanup of directories

• Periodically sending status messages by mail

• Automated starting and stopping of services which should only be available at certain times

All output of commands that are run by cron are automatically mailed to the user who configured these jobs. But obviously you can send the output anywhere you want, including to pagers and to cell phones with SMS, as long as the pager or cell phone can be reached via a scriptable interface.

As system administrator, you may want to regulate the use of cron. This can be done using two files: /etc/cron.allow and /etc/cron.deny. (On a SuSE system, these files are /var/spool/cron/allow and /var/spool/cron/deny, respectively). These files are checked in turn:

• If a user wants to use the cron facility, and none of the two files exist, the usage is allowed.

• If the file /etc/cron.allow (/var/spool/cron/allow) exists, the username has to be in it in order to be able to use cron.

• If the file /etc/cron.allow (/var/spool/cron/allow) does not exist, but the file /etc/cron.deny (/var/spool/cron/deny) exists, the username should not be in it in order to be able to use cron.

If both files exist, then only the allow file is read and everybody not in it is automatically denied usage of cron. That is why the allow file is called the strongest.



Student Notebook

Figure 13-4. User crontab Example LX033.1

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_day0,30 9 * * * Twice_a_day0,30 8-18 * * * Twenty_Two_times_a_day*/5 * * * * Every_five_minutes12 13 1 * * Once_a_month49 23 16 9 * Once_a_year0 15 * * 1 Every_monday32 14 1 1 1 ??? (caveat!)




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


Student Notebook

Figure 13-5. crontab Command LX033.1

Notes:

All user crontab files are stored in /var/spool/cron, and cannot be edited by the users directly. Users therefore need to invoke the crontab command to edit their files.

There are three ways of invoking the crontab command:

• crontab -l lists your current crontab file.

• crontab -r removes your crontab file and then signals crond that a change has occurred.

• crontab -e edits your current crontab file using your favorite editor (as specified by the $EDITOR variable). After the editor finishes, the crond daemon is signaled that a change has occurred.

crontab Command

A regular user cannot edit his own crontab file directly

crontab command runs SUID root, so can edit the users crontab file

Three usage methods:crontab -l List your crontab filecrontab -r Remove your crontab filecrontab -e Edit your crontab file using $EDITOR

# crontab -e30 12 * 1-12 1-5 echo "Having lunch." | /usr/bin/wall~~~"/tmp/crontab.2989" 1L, 45C 0,0-1




Uempty

Figure 13-6. System crontab File LX033.1

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 File

A system wide crontab file is used to automate system tasks. This file is called /etc/crontab

Slightly different syntax:<TIME> <UID> <COMMAND>

SHELL=/bin/shPATH=/usr/bin:/usr/sbin/:/sbin/:/bin:/usr/lib/news/binMAILTO=root*/15 * * * * root /usr/lib/crons/run-crons59 * * * * root rm -f /var/spool/cron/lastrun/cron.hourly14 0 * * * root rm -f /var/spool/cron/lastrun/cron.daily29 0 * * 6 root rm -f /var/spool/cron/lastrun/cron.weekly44 0 1 * * root rm -f /var/spool/cron/lastrun/cron.daily



Student Notebook

Figure 13-7. Anacron (Red Hat Only) LX033.1

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 (Red Hat Only)

Most crontab jobs typically run at night

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 boot scripts and by cronJob execution information stored in /var/spool/anacron

Note: Anacron is not supported on SuSE




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


Student Notebook

Figure 13-8. /etc/anacrontab LX033.1

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

Example:

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

SHELL=/bin/shPATH=/usr/sbin:/usr/bin:/sbin:/bin

1 5 cron.daily run-parts /etc/cron.daily7 10 cron.weekly run-parts /etc/cron.weekly30 15 cron.monthly run-parts /etc/cron.monthly




Uempty

Figure 13-9. at LX033.1

Notes:

The at command can be used to run a command once in the future. It creates a script in the /var/spool/at (Red Hat) or /var/spool/atjobs (SuSE) directory, containing the commands to be executed. This file will be read and executed by the atd daemon at the specified time.

To enter an at job you must enter the time you want the job to be executed. Some examples of the at command are:

# at 4am run the at job at the next 4am.# at 6pm run the at job at the next 6pm.# at 16 ditto# at 16:00 ditto# at 5pm + 4 days run the at job at 5am over 4 days.# at 4 tomorrow run the at job tomorrow at 4am.# at -f commandfile 19 run the commands in commandfile at 7pm.# at 19 < commandfile ditto

at

Run a command once in the future

# at 4amps aux^d (CTRL+D)

# at -f bshfile 16:00 + 3 days

# echo "mail -s report < rep.txt boss" | at now +2min



Student Notebook

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




Uempty

Figure 13-10. batch LX033.1

Notes:

When you start a command, then this command will get executed by the system no matter what the workload on the machine is. This also happens with commands started by the crond and atd daemons. More commands will also mean that the overall performance of the machine will degrade.

The batch command gives you a means of entering a command which will affect the performance of the system to a lesser extent. With the batch command you indicate that a job should be delayed until the workload on the system is below a certain threshold.

batch

run a command when the system load is low enough.

Command will be run when average workload is below 0.8

Workload: number of processes waiting for cpu time

$ batchecho workload is low enough<ctrl-d>



Student Notebook

Figure 13-11. Controlling at Jobs LX033.1

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

To control at jobs, use the at command

You can also use atq to list all jobs and atrm to delete a given job

Regulate the use of at /etc/at.allow (strongest) /etc/at.deny

# at -l93 2003-05-24 04:15 a tux194 2003-12-14 15:47 a tux1# at -d 93




Uempty


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)



Student Notebook


Notes:

Unit 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

anacron is not supported on SuSE

at jobs are initiated by the atd daemon

batch jobs are executed by the atd daemon




Uempty
Unit 14. Backup and Restore

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



• Discuss backup schemes

• Discuss backup media

• List the different backup tools supported in Linux


Accountability:

• Checkpoint questions

• Exercises


© Copyright IBM Corp. 2001, 2004 Unit 14. Backup and Restore 14-1

Student Notebook


Notes:

Unit Objectives


Discuss backup schemes

Discuss backup media

List the different backup tools supported in Linux




Uempty

Figure 14-2. Backup Schemes LX033.1

Notes:

It is not always necessary to back up everything that is stored on the hard disk of a computer. That's why there are a number of different backup types possible.

The first backup type is the full backup. As the name implies, this backup contains everything stored on disk, with the possible exception of /tmp. When this backup is restored, the system can continue working where it left of. The disadvantage is that a system backup takes a long time to perform.

A system backup only backs up the operating system itself, and any application programs that were installed. This is useful when doing system upgrades.

A data backup only backs up the user data.

An incremental or differential backup only backs up files that have changed since the last (incremental, full or data) backup. Before restoring an incremental backup, you will always need to restore the other (full or data) backup too and possibly all the incremental backups that have been made since then.

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 or differential backup Only backup files that changedVery fast, but takes more time to restore Must be used carefullyNeeds more media



Student Notebook

Figure 14-3. Incremental versus Differential Backup LX033.1

Notes:

The visual lists the difference between an incremental and a differential backup: An incremental backup backs up the differences between the current situation and the last differential backup, while a differential backup backs up the differences between the current situation and the last full backup, irrespective of differential backups in between.

The difference is academic: most backup tools only have a very primitive way of doing incremental/differential backups, and the backup tools that do support this typically support more levels, so that you can make your own combination.

With dump, for example, it is possible to take a backup every day of the week, which backs up the changes made on the last two days. In other words, an incremental backup against the previous-but-last backup.

Incremental versus Differential Backup

Full L 1 L 2 L 3

incremental backup

Full L 1 L 1 L 1

differential backup

Day 1 Day 2 Day 3 Day 4




Uempty

Figure 14-4. Sample Backup Scheme LX033.1

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 (for example, financial) should be kept available for a number of years (up to 50 years). By keeping the tapes available, you are fulfilling this legal obligation.

- Certain events or activities only occur once a year or less. It is very likely that people will delete files as part of a cleanup operation and discover after a year or so that they still need that one special script/file/macro that was used last year too. If you still have it on tape, you certainly made their day.

• After system maintenance, a system backup is made. If these are kept for at least a month or so, you can always trace back which file has changed at which moment in

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



Student Notebook

time, and therefore figure out why the system's behavior has changed. Plus, it allows you to do a downgrade rather easily.

• Every weekend, a data backup is made. This backs up all the user data.

• Every weekday evening, an incremental backup is made. This backs up the user files that have changed since the last data or incremental backup.

Obviously, you are free to implement your own scheme.




Uempty

Figure 14-5. Sample Monthly Backup Scheme LX033.1

Notes:

The visual shows a backup scheme for a full month, using the schedule of the previous visual.

Sample Monthly Backup Scheme

Su Mo Tue We Thu Fr Sa

1Level 0

2

34

Level 25

Level 36

Level 47

Level 58

Level 19

1011

Level 212

Level 313

Level 414

Level 515

Level 116

1718

Level 219

Level 320

Level 421

Level 522

Level 123

2425

Level 226

Level 327

Level 428

Level 529

Level 030

31



Student Notebook

Figure 14-6. Backup Devices LX033.1

Notes:

Various devices and media can be used to perform backups.

Tape drives are excellent devices for performing backups. They are comparatively fast, cheap and have a large capacity. There is one disadvantage though: reading from and writing to tape means that the tape itself has to glide along the read/write head at high speed. The friction caused by this movement wears the tape out pretty quickly, and it is therefore important to use new tapes regularly.

CD-R, CD-RW and DVDs are a fairly new way of backing up. They are cheap and have a large capacity. The disadvantage is that they are comparatively low, and that it is currently hard to predict how long the data on the CD will actually be readable. A few years is not a problem, but there have not been tests with storing data for more than a dozen years.

Hard Disks are very useful to do backups on. They are fast but relatively expensive. But, unless you have a removable hard disk, they cannot be taken away from the computer, which doesn't help you if your computer burns down or is stolen.

Backup Devices

Tape driveLarge capacity, fastUse new tapes regularly!

CD-R, CD-RW, DVDCheap 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 almost any computer.
A Zip drive or Jaz drive may also be a good alternative to floppy disks. They are relatively fast and have a large capacity. The biggest disadvantage is that these are not standard media types. If your computer burns down, or your Zip drive breaks down, you will have a hard time reading your precious backups.

Backing up over the network is a good idea in large installations. In such environments however, the backup strategy usually becomes complex enough to warrant the usage of commercial backup solutions such as ADSM.



Student Notebook

Figure 14-7. Default Backup Tools LX033.1

Notes:

Linux by default only has four backup commands available, although various distributions sometimes do offer additional commands.

tar and cpio roughly do the same thing: they back up individual files into a tar or cpio file which can for instance be written to a block device such as a tape. The choice between tar and cpio is a matter of preference.

dump is a tool which can back up complete filesystems. It can handle special files (such as in /dev) and symbolic links, and it can make incremental backups up to 9 levels.

dd is a tool which is not designed to do backups, but can be used as such. It makes a bit-for-bit dump of a disk or filesystem and can thus be used to restore systems to an exact state.

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)

ddUseful for making bit-for-bit dumps of disks and filesystems




Uempty

Figure 14-8. tar Command LX033.1

Notes:

The tar (tape archiver) utility has been used with UNIX systems for many years. You could say that it is an old command. Unfortunately, it is not user friendly and can be quite difficult at times, especially when you are unfamiliar with the syntax to make tar do useful things. With tar you can combine many files into one large file, which makes it easier to move the collection to another disk or make a backup to tape.

The general syntax is:

tar <options> [files]

The available options can be lengthy. Files can be specified with or without wildcards. An example to create a tar archive is:

tar -cvf archive11.tar /home/johan

This command creates (c) an archive called archive11.tar (f archive11.tar), and is verbose (v) in what it does.

Important to note here is that tar does not conform to the regular way of specifying options: It first requires the user to list all relevant options, and if any of these options require

tar Command

Traditional UNIX tape archive command

Backup with tar:

Restore with tar:

List contents of a tar backup:

# tar -cvf home.tar /home

# tar -tvf home.tar

# tar -xvf home.tar [ files to extract ]



Student Notebook

arguments, then these arguments are listed straight after one another. Finally, the last argument(s) list the files to be archived.

Other options include:

x extract files from an archive

t list files in an archive




Uempty

Figure 14-9. GNU tar LX033.1

Notes:

The tar command that is provided by the GNU project has a number of important features that set it apart from traditional tar. These features include compression with gzip or bzip2, another way of working with pathnames, and multivolume backups.

The first feature is support for compression using gzip (using the z option) or bzip2 (using the j option). bzip2 compression is better but not really standard yet.

Traditional tar always included the leading slash in the tar archive. This meant that a file would always be restored at the exact same place. In most cases, this is not what you want. Because of that, GNU tar strips the leading slash from the pathname when making a tar archive. If you want the leading slash to be included, you can use the P option though.

The last feature is the M option, which allows you to create multivolume backups. This is useful for backing up to a floppy disk, for instance.

GNU tar

The GNU version of tar has a lot of improvements:

Compression: use z option (gzip) or j option (bzip2)

To include absolute pathnames use P option

To make a multivolume backup: use M option

# tar -zcvf home.tar.gz /home# tar -jcvf home.tar.bz2 /home

# tar -cvfM /dev/fd0 1440 /home

# tar -Pcvf home.tar /home



Student Notebook

Figure 14-10. cpio Command LX033.1

Notes:

cpio stands for CoPy Input Output This command is similar to tar. However it can use archive files in a number of different formats, including the tar format. Normally cpio reads the names of the files to copy into the archive from standard input (stdin) and produces the archive as standard output (stdout). When extracting files from an archive, cpio reads the archive as standard input.

As with tar, some options can be given in both a short, single-letter form or a more descriptive word form. On the other hand, the syntax of the two forms differs when the option must be followed by additional information.

In the short form, you must use a space between the option and the additional information. With the word form you must separate the two options with an equal sign and NO space. It should be used with care, as it will not preserve, unless instructed to do so, the ownership and permissions of files.

In fact, cpio can even lose the directory structure on the restore side. When using cpio to copy files into a directory, you must give the name of the target directory as an argument to cpio.

cpio Command

Common UNIX backup command

Backup with cpio:

Restore with cpio:

List contents of a cpio backup:

# cpio -ov <files> > <device> # find /home cpio -ov > /dev/fd0

# cpio -iv[-dum] [files] < <device> # cpio -ivdum "/home/j*" < /dev/fd0

# cpio -itv < <device> # cpio -itv < /dev/fd0




Uempty

Figure 14-11. dump Command LX033.1

Notes:

dump is a backup tool which can backup whole filesystems. It correctly handles symbolic links and special device files, and it can handle incremental backups up to 9 levels. Information about these incremental backups is stored in the file /etc/dumpdates.

dump can also back up to another system, using the rsh protocol. This feature is not often used today though: If you want to make network backups, then there are far better tools available, including Amanda and Tivoli.

Restoring a backup made by dump is done with the restore command.

dump Command

To backup a complete filesystem use the dump command

Can handle incremental backups up to 9 levelsInformation is stored in /etc/dumpdates

To restore a dumped filesystem:

# dump -0 -u -a -f /backupdir/home.dump /home# dump -1 -u -f backup@remhost:/tux.dump /

The -a option is used to determine the size of the backup medium

# cd /home# restore -xvf /backupdir/home.dump....set owner/mode for .? [y/n]



Student Notebook

Figure 14-12. LVM Snapshots LX033.1

Notes:

LVM Snapshots are not backup tools as such, but can be really useful when creating backups.

An LVM snapshot can be though of as a direct copy of a logical volume, but this copy is deferred until data on the original logical volume actually changes. Until that time, the physical extent is “shared” between the original LV and the snapshot LV.

The advantage of this over a real LV copy is that a snapshot, even of very large LVs, can be done in a very short time, because no actual data needs to be copied. The only thing that needs to be done is allocate the blocks for the snapshot, and some administration. This rarely takes more than a second.

This is really useful if you are running programs (for example, databases, web servers and the like) that need to be running as close to 24 hours a day as possible, but need to be backed up nevertheless in a consistent state. With LVM snapshots, the interruption in service can be kept down to mere seconds:

• Stop the service

LVM Snapshots

/dev/vg00/mylv /dev/vg00/mylv_snap

# umount /dev/vg00/mylv# lvcreate -L 200M -s -n mylv_snap /dev/vg00/mylv# mount /dev/vg00/mylv# dump -0 -u -f /dev/st0 /dev/vg00/mylv_snap && \> lvremove /dev/vg00/mylv_snap

An LVM snapshot logical volume allows you to backup a read-write mounted filesystem with active programs (for example, databases) running without much downtime

Snapshots are created using copy-on-writeOnly the physical extents that are actually modified after the snapshot has been taken are copied in their original form to the snapshot LV




Uempty
• Unmount the filesystem
• Take an LV snapshot

• Mount the filesystem

• Start the service again

This whole procedure should not take more than 10 seconds. After this, the LV snapshot contains an image of the unmounted filesystem, which can be backed up when time permits.



Student Notebook

Figure 14-13. dd Command LX033.1

Notes:

The dd command is not a backup command per se, but can be used as such. It basically copies data bit-for-bit to and from disks, filesystems, floppy disks or files.

dd can for instance be used to create disk images: files which have the exact size as the original disk. These disk images can then be used to clone a system, or to restore it to its original state.

dd Command

Command to make bit-for-bit dumps of files, filesystems and disks

To make a full disk backup image and restore it again:

To make a backup of your MBR

To trash your system thoroughly

# dd if=/dev/hda of=/mnt/nfs/hda.img bs=1M# dd if=/mnt/nfs/hda.img of=/dev/hdc bs=1M

# dd if=/dev/hda of=/mnt/nfs/mbr.img bs=512 count=1

# dd if=/dev/zero of=/dev/hda bs=1M# dd if=/dev/urandom of=/dev/hda bs=1M




Uempty
The syntax of dd is rather strange. Instead of using regular options, it only accepts arguments. Here are some example arguments:
if= Input file

of= Output file

bs= Block size, in bytes. May also use the abbreviation K, M or G, for kilo-, mega- and gigabytes, respectively.

The block size identifies the block size that dd uses. Experience has shown that the default block size of 512 bytes is too small to obtain good performance when working with local disks. It is therefore recommended to use a block size of 1M or more when working with local disks (including floppy disks).

count= Number of blocks to copy



Student Notebook

Figure 14-14. Other Backup Tools LX033.1

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://www.amanda.org

IBM/Tivoli Storage Manager (TSM): http://www.tivoli.com/products/linux




Uempty


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



Student Notebook


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




Uempty
Unit 15. User Administration

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



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


Accountability:

• Checkpoint questions • Lab exercises


© Copyright IBM Corp. 2001, 2004 Unit 15. User Administration 15-1

Student Notebook


Notes:

Unit Objectives


Add, change and delete user accounts

Add, change and delete groups

Manage user passwords

Communicate with the user community




Uempty

Figure 15-2. Security Concepts LX033.1

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.

Security Concepts

User Accounts Groups

Unique name

Unique ID

Users who need access to the same files

Unique name

Unique ID

Password

File ownership is determined by user ID



Student Notebook

Figure 15-3. User Hierarchy LX033.1

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.

User Hierarchy

rootSuper UserFile permissions do not apply for rootCan do anything except the obviousAccount for the system administrator

bin, daemon, lp, sync, news, ftp ...User accounts used by different applications and daemonsCannot (and should not) be used to log in

Ordinary user accounts




Uempty

Figure 15-4. Groups LX033.1

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.

Groups

A group is a set of users, all of whom need access to a given set of files

Every user is a member of at least one group and can be a member of several groups

Primary group: used for file/directory creation

Group set: used to determine access permissions

The user has access to files in all of the groups in its groupset. The groups command shows all the groups a user is member of



Student Notebook

System-defined groups The system-defined groups are used to control certain subsystems.

There are two different kinds of groups available to users. The first group is the primary group. The primary group is used by the system when you create a file (and directory). Every file created is assigned a group and this is the primary group of the user creating the file. The group set is the set of groups determining the permissions you have on a given file or directory. The group set is used by the system when you want to work with a file or directory.




Uempty

Figure 15-5. User Private Groups LX033.1

Notes:

In the previous visual we’ve seen that every user is a member of at least one group. By default, in most UNIX and Linux systems, this is a generic group called “users” or “staff”. But some distributions, including Red Hat, have introduced something called “User Private Groups”.

With this scheme, a group is created for each and every user account. This account is made member of that group. The user name and group name are the same, as are the UID and GID numbers.

This has an advantage over the traditional scheme in that it is easier to give someone (for instance a secretary) access to someone elses home directory (for instance the boss’ directory): Simply make the secretary member of the boss group. With the traditional scheme, still used by SuSE, this is virtually impossible.

And note that this scheme still allows all the things the traditional scheme allows as well: groups related to a project, where every project member is member of the group and can access the files of that group.

User Private Groups

User Private Groups: Scheme where every user has its own "private group" as primary group, instead of one big, generic group of which everyone is member

Advantages:Easier to give users access to home directories of other users (for example, secretary to boss' home directory)

Disadvantages:Requires changes to authorization subsystem (for example, umask, useradd, ...)

Red Hat uses User Private Groups, SuSE does not

john mary

group

"john"

group

"mary"

john mary

group "users"



Student Notebook

Figure 15-6. Shadow Password Suite LX033.1

Notes:

In the early days of UNIX, all user information, including the encrypted password, was stored in /etc/passwd. This file needs to be readable for the whole world: programs such as ls, for instance, need to be able to perform UID <-> username mapping.

This meant that every user on the system could get a list of all the encrypted passwords of all users, which he or she could then subject to a dictionary attack. When CPUs were comparatively slow by today’s standards, this was a lot of work and not really practical. Today however, dictionary attacks take mere seconds, and with hardware which is currently available to wealthy hackers, a brute force attack which tries out every possible password is becoming feasible.

It is therefore of paramount important that also the encrypted passwords of the users are shielded from ordinary users. This is performed by the shadow password suite. This suite of programs and libraries adds two additional files to the system: /etc/shadow and /etc/gshadow. These files are read-write only for root, so ordinary users can’t get access to them, except for a few carefully written SUID programs that are part of the shadow password suite.

Shadow Password Suite

Local users and groups secret information (passwords, ...) are managed by the Shadow Password Suite

/etc/login.defs

/etc/{passwd,group}

/etc/{shadow,gshadow}

useradd

usermod

userdel

groupadd

chage

chfn

passwd

...

User and group database

User and group database secret entries

Utilities

Configuration file




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


Student Notebook

Figure 15-7. Command Line User Tools LX033.1

Notes:

adduser or useradd A tool to add users to your system. The adduser and useradd command will only create the user account. You have to set the password manually afterwards. Depending on the configuration in /etc/login.defs, useradd creates the home directory of the user as well. To always create the home directory, regardless of these settings, use the -m option.

userdel Remove users from your system. The -r option also removes the contents of the user's home directory, and the directory itself.

usermod Change settings of a user. This command can also be used to lock and unlock a user account. This is done by putting an exclamation point in front of the password in /etc/shadow.

Command Line User Tools

Add a user account

Delete a user account

Change a user account

Locking and unlocking a user account

# useradd -m -g staff -G audio,uucp tux20# passwd tux20

# userdel -r tux20

# usermod -g users -G video tux20

# usermod -L tux20# usermod -U tux20




Uempty

Figure 15-8. /etc/skel LX033.1

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.

/etc/skel

Directory with skeleton files that users will receive in their home directory upon creation of their account

useradd -m creates the home directory with files from /etc/skel

In Red Hat, the -m may be omitted

useradd -m -k allows you to specify a different skeleton directory

# useradd -m tux25# useradd -m -k /etc/my_own_skel tux30



Student Notebook

Figure 15-9. Command Line Group Tools LX033.1

Notes:

You could also use the command tools to manage your groups.

An interesting feature of UNIX/Linux is that you, as the superuser, can assign group administration rights to other users. This allows group administrators to add users to their group, and remove them from their group. Obviously, the user accounts themselves still need to be created by the superuser.

Command Line Group Tools

Adding, deleting, changing of groups

Adding, deleting users to/from groups

Defer administration of a group to a user

# groupadd penguins# groupmod -n oldname newname# groupdel penguins

# gpasswd -A linus penguinslinus$ gpasswd -a tux1 penguinslinus$ gpasswd -d tux2 penguins

# usermod -G penguins tux1 tux2# gpasswd -a tux1 penguins




Uempty

Figure 15-10. Passwords LX033.1

Notes:

Users can change their passwords by using the passwd command. Root can also use this command to reset passwords of other users.

A useful tool is mkpasswd. This generates a random password and, optionally, assigns this password to a user. Note that the mkpasswd command is not installed by default. On a Red Hat system, it is part of the expect RPM, while on a SuSE system, it is part of the whois RPM.

Another useful tool is chage. This allows you to view and change the password aging information.

Passwords

Change a users password with passwd

Generate a random password for a user with mkpasswd

Change a users password expiry information with chage

# passwd tux30New password:...# mkpasswd tux30VjOmnoYXyPP4U# chage -l tux30Minimum: 14Maximum: 186Warning: 21Inactive: 7...



Student Notebook

Figure 15-11. /etc/passwd LX033.1

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.

/etc/passwd

# cat /etc/passwdroot:x:0:0:root:/root:/bin/bash...postfix:x:51:51:Postfix Daemon:/var/spool/postfix:/bin/false...tux30:x:537:100::/home/tux30:/bin/bash

Fields are separated by ":"

1) login name

2) password field (x means: encrypted password available)

3) UID

4) GID

5) GECOS field (user information)

6) home directory

7) login shell

The /etc/passwd file contains non-secret information about the users




Uempty

Figure 15-12. /etc/shadow LX033.1

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.

/etc/shadow

# cat /etc/shadow...bin:*:10787:0:99999:7:-1:-1:...tux1:$1$VOHuuCQM$Kqc9m7wSlQnRtqANtZCba/:10792:0:99999:0:0:10787:13453tux2:$1$BgSP6XLW$/tDKJTmLZzqh9372X7U7o0:10791:-1:99999:-1:-1:-1:13544

1) Login name

2) Encrypted password (md5)

3) Last change of credentials (days since Jan 1, 1970)

4) Days before password may be changed

5) Days after which password must be changed

6) Days before password is to expire that user is warned

7) Days after password expires that account is disabled

8) Days since Jan 1, 1970 that account is disabled

Credentials of any user account are stored in the /etc/shadow file



Student Notebook

• Number of days the user will be warned of a password expiry.

• Number of days after expiry, after which the account is disabled.

• The day the account was disabled.

• A reserved field.

The /etc/shadow password file should be read/writable by root only. Other users should not be able to read this file at all.




Uempty

Figure 15-13. /etc/group and /etc/gshadow LX033.1

Notes:

The /etc/group file contains group information. From left to right:

• The group name

• The group password. This is set to “x” if the group password is in /etc/gshadow.

• The Group ID (GID)

• The list of users that have this group as their secondary group.

The /etc/gshadow file contains extended group information. From left to right:

• The group name

• The group password. Group password are ancient UNIX concepts which are no longer being used. For backwards compatibility this field is kept alive though.

• The name of the group administrator

• The list of users that have this group as their secondary group.

/etc/group and /etc/gshadow

# cat /etc/grouproot::0:rootbin::1:root,bin,daemondaemon::2:root,bin,daemonsys::3:root,bin,admadm::4:root,adm,daemon...penguins:x:500:linus,tux1,tux2tux1:x:501:tux2:x:502:

# cat /etc/gshadow...penguins:!:linus:tux1,tux2



Student Notebook

Figure 15-14. /etc/issue and /etc/issue.net LX033.1

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

/etc/issue and /etc/issue.net

Contain the login message for mingetty and telnetd

# cat /etc/issue

Welcome to Generic Linux 1.0Kernel \r on an \m

#

Several backslash escaped sequences are supported by mingetty:

\r kernel release

\m machine type

\o domain name

For a complete list type "man mingetty"




Uempty

Figure 15-15. Message of the Day LX033.1

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.

Message of the Day

/etc/motd

Should only contain information necessary for the users to see

If $HOME/.hushlogin exists, /etc/motd will not be shown when the user logs in.

# cat /etc/motd

***************** SYSTEM OUTAGE ****************Due to a hardware upgrade this system will notbe available between 10pm and 11pm tonight.************************************************



Student Notebook


Notes:


1.

2.

Checkpoint

What is a User Private Groupa. A group for users who need privacyb. A group which has the same name as the user; this user has this group as

its primary groupc. A group which is used for sharing files between the members of this groupd. The "staff" group

Where are the passwords of users stored?______________________________________________

1)

2)




Uempty


Notes:

Unit Summary

Users and groups can be added, deleted and modified with command line tools

Passwords must be set for all users and must be changed regularly

User information is stored in /etc/passwd

Password and account information is stored in /etc/shadow

Group information is stored in /etc/group

Shadow files stop ordinary users from reading the encrypted passwords



Student Notebook




Uempty
Unit 16. 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, 2004 Unit 16. User-Level Security 16-1

Student Notebook


Notes:

Unit Objectives


Define ways of controlling root access to the system

Define the use of SUID, SGID and Sticky Bit permissions bits

Identify the data files associated with users

Describe the concepts of PAM




Uempty

Figure 16-2. User-Level Security Overview LX033.1

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.

User-Level Security Overview

Authentication: Verifying that you are who you say you are

Can be based on:Something you only know (for example, password, PIN)Something you only have (for example, smartcard, token, key)Something you only are (for example, fingerprints, retina scan)

Authorization: Determining your level of accessFile permissionsAccount restrictions (login times, login tty, and so forth)

112

2

3

4

56

7

8

9

10

11



Student Notebook

Figure 16-3. Pluggable Authentication Module (PAM) LX033.1

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.

Pluggable Authentication Modules (PAM)

Authentication system of Linux

Implemented as a suite of shared libraries

Enables the system administrator to choose how applications authenticate users

Initially developed by Sun MicrosystemsAdapted for Linux




Uempty

Figure 16-4. Authentication Before PAM LX033.1

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.

Authentication Before PAM

login ftp httpdother

program

/etc/passwdhttpd

authentication

other

authentication

very secure

program

retinascanvoice

recognition



Student Notebook

Figure 16-5. Authentication with PAM LX033.1

Notes:

With PAM, every application that needs some kind of authentication, needs to be rewritten to use the PAM authentication mechanisms. But then, the only thing that program has to do, is ask PAM: “Is this user authorized to use me?”. And PAM will tell the program yes or no.

To authenticate that user, the system administrator can set up different authentication mechanisms, and specify which program should use which kind of authentication mechanism.

There are a number of authentication mechanisms currently available. Some of the more important are:

• Userid/password checking

• Anonymous login (for example, for anonymous ftp)

• Deny, for services that may not be used

• Secure tty, meaning that logging in is only allowed from a secure terminal

Authentication with PAM

PAMPAM config files

in /etc/pam.d

login ftp httpdother

program

very secure

program

/etc/passwdhttpd

authentication

other

authenticationretinascan

voice

recognition




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 16-6. PAM Configuration File Example LX033.1

Notes:

The visual above shows an example PAM configuration file. Every file you will encounter within PAM is split up in four sections, which apply to the four phases of the login process:

1. auth: Verify the authentication of the user, usually by checking the password.

2. account: Manage the account. For instance force a user to change its password if the password used is expired.

3. password: Change the password itself. This phase can also be called from the passwd program.

4. session: Manage the session where the user logged in.

The first file is the configuration file which is used for the login process. From top to bottom, the lines mean roughly:

• When the user tries to authenticate, perform the following checks:

- Require that root only logs in from a tty listed in /etc/securetty.

- Check that the UNIX password is correct.

PAM Configuration File Example

# cat /etc/pam.d/login#%PAM-1.0auth required /lib/security/pam_securetty.soauth required /lib/security/pam_unix.so likeauth nullokauth required /lib/security/pam_nologin.soauth required /lib/security/pam_env.soaccount required /lib/security/pam_unix.sopassword required /lib/security/pam_cracklib.so retry=3 type=password required /lib/security/pam_unix.so nullok use_authtok md5 shadowsession required /lib/security/pam_limits.sosession required /lib/security/pam_unix.sosession optional /lib/security/pam_console.so

Note: PAM configuration is different from

distribution to distribution




Uempty
- Don’t allow a regular user in if the file /etc/nologin exists. Instead, print the contents of the file /etc/nologin.
- Set a number of environment variables used in the login process.

• For the account management, only perform the regular UNIX checks of password expiration.

• When a user sets a password, perform a dictionary attack first. Then, set the password using the regular UNIX files.

• When the users session is set up, apply a number of limits (CPU, memory, ...), and perform standard UNIX login tasks, such as switching to the appropriate user ID. If the user logs in on the console, make the user owner of certain console devices such as /dev/fd0 and /dev/cdrom.

More information on PAM can be found in /usr/share/doc/pam-version This includes a description of every function of every PAM module.

Note that the file in the visual is not an actual file, but merely an example.

Some actual examples of a Red Hat system are:

/etc/pam.d/login:#%PAM-1.0auth required /lib/security/$ISA/pam_securetty.soauth required /lib/security/$ISA/pam_stack.so service=system-authauth required /lib/security/$ISA/pam_nologin.soaccount required /lib/security/$ISA/pam_stack.so service=system-authpassword required /lib/security/$ISA/pam_stack.so service=system-authsession required /lib/security/$ISA/pam_stack.so service=system-authsession optional /lib/security/$ISA/pam_console.so

/etc/pam.d/system-auth:#%PAM-1.0# This file is auto-generated.# User changes will be destroyed the next time authconfig is run.auth required /lib/security/$ISA/pam_env.soauth sufficient /lib/security/$ISA/pam_unix.so likeauth nullokauth required /lib/security/$ISA/pam_deny.so

account required /lib/security/$ISA/pam_unix.so

password required /lib/security/$ISA/pam_cracklib.so retry=3 type=password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadowpassword required /lib/security/$ISA/pam_deny.sosession required /lib/security/$ISA/pam_limits.so



Student Notebook

As you can see, Red Hat uses the pam_stack.so module to refer to a generic system-auth file. This file is modified by authconfig and used in virtually any PAM authentication configuration file.

The $ISA shell variable is used to distinguish between 32-bit and 64-bit architectures.

An actual example from a SuSE system is:

/etc/pam.d/login:#%PAM-1.0auth requisite pam_unix2.so nullok #set_secrpcauth required pam_securetty.soauth required pam_nologin.soauth required pam_env.soauth required pam_mail.soaccount required pam_unix2.sopassword required pam_pwcheck.so nullokpassword required pam_unix2.so nullok use_first_pass use_authtoksession required pam_unix2.so none # debug or tracesession required pam_limits.so

As you can see, SuSE uses pam_unix2 instead of pam_unix. The reason for this is largely historic: SuSE did not like the quality of the earlier pam_unix.so module, and decided to write its own. Today, the quality and functionality of pam_unix and pam_unix2 is virtually equal.




Uempty

Figure 16-7. Common PAM Modules LX033.1

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.

Common PAM Modules

Some commonly used PAM modules are:pam_unix.so: Regular UNIX authentication (passwords)pam_env.so: Set environment variablespam_cracklib.so: Check passwords for strengthpam_pwdb.so: Enforce password aging rulespam_pwcheck.so: Check passwords (SuSE only) pam_nologin.so: Deny login if /etc/nologin existspam_listfile.so: Allow/deny login if user listed in filepam_securetty.so: Allow login for root only from secure ttyspam_time.so: Allow/deny login based on time of daypam_stack.so: Include another PAM config file (RH only)pam_limits.so: Set limits on CPU and memory usagepam_console.so: Set permissions for console userspam_deny.so: Always gives an error

Several PAM modules have additional configuration files in /etc/security



Student Notebook

Figure 16-8. Principles of Authorization LX033.1

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.

Principles of Authorization

Authorization in Linux based on file permissionsException: root is allowed to do everything

Once logged in, users cannot change their identity, except through a SUID program, which allows them to run a command as someone else (most often root)

Examples of SUID programs:passwd: Allows users to update the /etc/shadow filemount: Allows users to mount a floppy or CDsu: Runs a shell as another user, after supplying the passwordsudo: Runs a particular command as another userVarious games (to track highscores)

All SUID programs should be known to the administrator and checked/updated for security problems




Uempty
• sudo: This was invented when people started noticing that sometimes users need to execute scripts or complicated commands as root, without allowing them to actually become root. Traditional methods would either mean giving these users the root password, or set the SUID bit on that particular command. The first is not desirable for obvious reasons, but the second can be too permissive too: The user would be able to run the command with any arguments that he would choose.
sudo only allows specific users to run specific commands with specific options as specific users, and nothing more. The list of users and commands that they are allowed to run is in /etc/sudoers.

Make sure that you always use absolute paths to programs when creating a sudoers file, since otherwise users might change their $PATH variable and use sudo to start arbitrary scripts in their own $HOME/bin directory.

• Various games may have their SUID bit set. This is usually needed to implement some sort of highscore tracking.

Apart from kernel bugs, SUID programs are the only means for a hacker to gain root privileges when he is logged in as a regular user. This means that all SUID programs on the system should be known to the system administrator and checked/updated regularly for security problems.

The following command will list all SUID programs on your system:

find . -perm +6000 -ls



Student Notebook

Figure 16-9. File Permissions LX033.1

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

File Permissions

Perm. File Directory

r User can read contents of file

User can list the contents of a directory

w User can change contents of file

User can change the contents of directory

x User can execute file as a command

User can cd to directory and can use it in PATH

SUID Program runs with effective user ID of owner

SGID Program runs with effective group ID of owner

Files created in directory inherit the same group ID as the directory

Stickybit

Only the owner of the file and the owner of the directory may delete files in this directory




Uempty
SUID (Switch UID) If the file gets executed, it will run with an effective UID of the owner of the file. This permission is not supported on shell scripts. This permission has no meaning on directories.
SGID (Switch GID) On an executable file it means that when the file runs, the process runs with an effective GID of the group owner of the file. On a directory it means that any file/directory made within the directory will have the same group ownership as the directory rather than the primary group of the user. SUID and SGID programs are hackers' favorites. When a hacker has entered your system he will usually leave some SUID /SGID programs (“trojan horses”) around. With these programs he is then able to gain root access anytime he is logged on as a regular user, even without knowing the root password. It is therefore important that the system administrator knows which SUID and SGID programs are installed on the system. They can be listed with the following command:

find / -perm +6000 -ls

Sticky Bit On an executable file (thus, a program) this bit used to mean that the program should not be removed from memory after it was executed. The next time the program were to be executed, the program would start significantly quicker. With modern memory management this usage is no longer implemented. On a directory it means that even if the directory has global write permissions, users cannot delete a file in that directory unless they either own the file or the directory.



Student Notebook

Figure 16-10. Changing Permissions LX033.1

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

Changing Permissions

Setting file permissions is done with the chmod command

Changing user and group

# chmod 1755 (or o+t) commondir# ls -ld commondirdrwxrwxr-t 3 root proj1 4096 2003-05-13 08:53 commondir# chmod 2755 (or g+s) myprogls -l myprog-rwxr-sr-x 1 root proj1 729402 2001-07-18 12:45 myprog# chmod 4755 (or u+s) passwdls -l passwd-rwsr-xr-x 3 root shadow 73680 2003-03-17 16:39 passwd

# chown john finance# chgrp staff finance# chown john.staff finance




Uempty

Figure 16-11. umask LX033.1

Notes:

The umask specifies what permission bits will be set on a new file when it is created. The umask is an octal number that specifies the which of the permission bits will not be set. On a file, the execute permissions can never be set automatically.

The root user may have a different umask than normal users. For root, the default umask is 022 and for normal users this will be 002 (when User Private Groups are used) or 022 (otherwise).

For example, a umask of 022 specifies that the permissions on a new file will be 644 and on a new directory will be 755. A umask of 000 would give 666 permissions on a file and 777 on a directory.

To view the current umask value, just run the umask command.

The default umask for all users is specified in the /etc/profile file. For specific users, it could be set in the $HOME/.bash_profile or $HOME/.profile file.

umask

Sets the default permissions on new files

System-wide umask for all users in /etc/profile

Individual umask in $HOME/.bash_profile or $HOME/.profile

Default value of umask is:For root 022For user 002 (if user private groups are used) or 022 (otherwise)



Student Notebook

Figure 16-12. Example: Creating a Team Directory LX033.1

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.

Example: Creating a Team Directory

Create a group

Add users to the group

Create a directory and set group, permissions

# groupadd penguins

# usermod -G penguins tux1or:# gpasswd -a tux1 penguins

# mkdir /groups/penguins# chgrp penguins /groups/penguins# chmod 2770 /groups/penguins




Uempty

Figure 16-13. Root Access LX033.1

Notes:

If the root password is known by too many people, no one can be held accountable for changes in the system. The root password should be limited to the lowest number of users possible. The fewer people who know the root password the better. However, do not make the mistake of keeping the root password as your personal secret. Should you be on vacation and the systems crash, key personnel should be able to gain root access to the systems. A good method to achieve this is to put the root password in a sealed envelope and store it in a safe somewhere.

The system administrator should ensure that distinct root passwords are assigned to different machines. You may allow normal users to have the same passwords on different machines, but never do this for root.

Attempts to become root through su can be investigated. Successful and unsuccessful attempts may be logged by the audit system.

Most Linux systems have remote login (through telnet) for root disabled by default: root is only able to login on consoles that are listed in /etc/securetty.

Root Access

Dangerous

root's password should be changed on an unannounced schedule by the system administrator

Assign different root passwords to different machines

Always log in as yourself, not as root

Remote login as root by default disabled



Student Notebook

Figure 16-14. su LX033.1

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.

su

Switch to another userid

Executing a command as another user

$ whoamitux1$ suPassword:# whoamiroot

$ su - root -c /sbin/poweroffPassword:$Broadcast message from root (tty1):The system is going down for system halt NOW!

Using su - <user> changes to the environment of that <user>




Uempty

Figure 16-15. sudo LX033.1

Notes:

The sudo command, as mentioned, allows users to execute specific commands with the authentication of another user, on specific hosts. Which combination is possible is configured in the /etc/sudoers file.

The basic syntax of this file is easy:

user host = [(newuser)] command

This means that user is allowed to execute command as newuser on host. If no newuser is specified, it is assumed that the command is executed as root.

What makes this complicated, but also terribly flexible, is that for all four elements, macro definitions can be added. These macros are typically written in capital letters, and there is a special ALL macro defined as well. See the visual for an example of this.

The /etc/sudoers file supports a large number of options as well, which govern for instance whether a user is allowed to add any options to the command or not. For examples of this, see the sudoers manual page.

sudo

Allows users to execute specific commands another user without requiring that users password

Do NOT use sudo for interactive commands!

/etc/sudoers file list which users are allowed to execute which commands on which host as which user

Edit this file with visudo only

Macros can be defined to reduce complexity

Syntax:user host = [(newuser)] command

# cat /etc/sudoersUser_Alias OPERATORS = tux1, tux2, tux3Host_Alias WEBSERVERS = www, www-1, www-2Cmnd_Alias PRINTCMDS = /usr/bin/printtool, /usr/bin/klpqtux1 WEBSERVERS = (root) /sbin/service httpd restartOPERATORS printsvr = (root) PRINTCMDS



Student Notebook

Because of security and locking issues, only edit this file with the visudo command, not with a regular editor.

Note that the intention of sudo is to allow users to execute a specific command as another user, most often root, without having to supply that users password. This also leads to a security risk if the command that is allowed can be used for something unintended. As an example, if you let a user start vi, through sudo then that user is able to edit that particular file. But by using the :r and :w commands in vi, the user is also able to edit other files owned by root. And by using :! in vi, the user is able to execute any command as root. You should therefore be really careful in configuring your /etc/sudoers file, so that it cannot be used to edit arbitrary files or execute arbitrary programs.




Uempty

Figure 16-16. Security Logs LX033.1

Notes:

/var/log/lastlog Records the last time a user logged in. This file can be examined with the lastlog command. /var/log/messages This is the general log file. Most applications and daemons will write log information to this file. The messages file is an ASCII file which can be viewed with tail -f or more. /var/log/secure Keeps track of the failed login attempts. Use more /var/log/secure to view the contents of this file. /var/log/wtmp All successful logins are saved in this file. This file can also be examined with the who command. Another tool for viewing this file is the last command. /var/run/umtp Logs the users currently logged in the system. The default output of the who command is the contents of this file.

Security Logs

/var/log/lastlog - last successful login

/var/log/messages - general log file

/var/log/secure - failed logins

/var/log/wtmp - successful logins

/var/run/utmp - currently logged in users



Student Notebook

Figure 16-17. Useful Commands LX033.1

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.

Useful Commands

# w Who is logged in and doing what?

# who Who is logged in and examine the contents of /var/log/wtmp and /var/log/utmp

# id Show information about a user

# last Show the last time a user logged in or the last time a tty was used to log in

# lastlog Show the last login time of all users




Uempty


Notes:


1.

2.

Checkpoint

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. When User Private Groups are used, the default umask of a user is 002,

and 022 otherwise

1)

2)



Student Notebook


Notes:

Unit Summary

PAM (Pluggable Authentication Modules) is the subsystem responsible for authentication of a user

Various PAM modules offer various authentication method, including username/password, time of day, secure tty and others

Authorization in a Linux system is based on file permissions

An SUID or SGID bit on a program elevates your authorization level while running that program to the authorization level of the owner of that program

Typical SUID/SGID programs are su and sudo




Uempty
Unit 17. 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, 2004 Unit 17. Logging 17-1

Student Notebook


Notes:

Unit Objectives


Describe logging concepts

Configure the syslog daemon

Use the logger program

Use the logrotate program




Uempty

Figure 17-2. Logging Concepts LX033.1

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:

Logging Concepts

Various daemons generate log information

All log items are sent to the syslog daemonTagged with facility and priorityThrough UDP/IP or UNIX socket

Syslogd decides what to do, based on /etc/syslog.conf

lpr

user

cron

kernel

syslogd

klogd

/var/log/{warn,messages}

/etc/syslog.conf

to tty, wall etc



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 17-3. Facilities, Priorities LX033.1

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)

Facilities, Priorities

Each log item is tagged with a Facility and a Priority

Facility identifies the sourceauthcronkernlpr...

Priority identifies the importancedebuginfowarncritpanic...

For a complete list see man syslog.conf



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 17-4. /etc/syslog.conf LX033.1

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.

/etc/syslog.conf

# /etc/syslog.conf - Configuration file for syslogd(8)# selector action# [ facility.priority ] [ log to ...]

# Example:# kernel messages (priority warn and higher) will be sent# to /dev/tty10kern.warn /dev/tty10# messages (priority crit and higher) generated by the MTA# will be sent to root if logged on mail.crit root# More examples:*.info;mail.none;authpriv.none /var/log/messagesauthpriv.* /var/log/securekern.*;*.=crit /dev/consolekern.*;*.=crit root,fred*.emerg **.emerg @sysadmin.acme.com



Student Notebook

• Send it to someone by using the write command. In this case, the action is the username of the recipient. Multiple recipients may be specified, separated by a comma.

• Send it to everyone on the system using wall. In this case the action is a '*'.

• Send it to the syslogd daemon on another system. In this case the action is a '@', followed by the hostname of the receiving system.

Note that, when sending the message to another system, the selection criteria from that /etc/syslog.conf file are applied too.

Also note that the log items are sent over the network unencrypted. If your log messages contain privileged information, such as plain-text passwords, they may be intercepted.

In order to receive log messages on this other system, you need to allow incoming UDP traffic on port 514, and you need to configure the syslog daemon for incoming messages through this port. This is done by starting the syslog daemon with the -r option. You can typically enable this in the startup configuration file /etc/sysconfig/syslog, which is read by the startup script /etc/init.d/syslog.




Uempty

Figure 17-5. logger Command LX033.1

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.

logger Command

Logs messages to system logger

Syntax: logger -p <facility>.<priority> <message>

# logger -p daemon.info This is a test# tail -1 /var/log/messagesFeb 18 16:34:32 pentium logger: daemon.info This is a test

$ logger -p kern.panic Kernel panic! Please log off NOW!$Message from syslogd@host at Fri Feb 18 16:42:38 2000 ...host logger: Kernel panic! Please log off NOW!



Student Notebook

Figure 17-6. logrotate LX033.1

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.

logrotate

logrotate automatically "rotates" logs:Copies the current log to archive logCan compress archive logCan mail archive logCleans the current logDeletes old archive logs

Usually run from cron

Criteria for rotation:TimeSize

Config file: /etc/logrotate.conf




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 17-7. Sample /etc/logrotate.conf LX033.1

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.

Sample /etc/logrotate.conf

# cat /etc/logrotate.conf# Global options (may be overwritten by local options)weeklyrotate 4errors rootcreate# Include several config files in the given directoryinclude /etc/logrotate.d# local options for some logfiles/var/log/wtmp { monthly create 0664 root utmp rotate 1}/var/log/messages { size 500k postrotate /usr/bin/killall -HUP syslogd endscript}




Uempty

Figure 17-8. Analyzing Logfiles LX033.1

Notes:

Logfiles are not collected for fun. They contain valuable information about the overall health of your system, and things that went wrong. It is therefore a good idea to analyze your logfiles regularly.

There are several strategies for analyzing a logfile:

• You can read through the whole logfile. With short logfiles this generally is not a problem, but it quickly becomes tedious when your logfiles are longer than a few hundred lines. Nevertheless, in case of strange problems it might be necessary anyway, so that you can correlate different logfile entries.

• You can search through the logfile (using grep or vi’s search capability) for interesting items. This is typically done when you are looking for something specific, such as all the actions of a particular user. Searching for specific items like this is called a positive search.

• You can perform a negative search through the logfile. A negative search typically uses a list of non-interesting items. Using for instance the grep -v command the logfile is

Analyzing Logfiles

Analyze logfiles regularlyPreferably through a cron job, every day

Possible strategies:Read through whole logfileSearch for interesting things (positive search)Discard uninteresting things (negative search)Use automated tools for analysis

Automated toolsSimple: grep, grep -v, logcheck, logdigestIntermediate: logwatch, logsurferAdvanced: swatch

Automated tools typically send e-mail with resultsDo not work if your e-mail subsystem is broken or disabled



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 e-mailed to the administrator. grep allows you to list the expression to search for on the command line, but the expression to search for can also be stored in a file, which is then referenced using the -f option.

• logcheck is a simple script which checks your logfiles from a cron job. It uses grep and grep -v extensively in a smart combination. Another advantage of logcheck over plain grep is that logcheck keeps track of what it has analyzed already, so it will not present results twice.

logcheck can be found on http://www.psionic.com

• logdigest is based on logcheck, and works generally the same. All configuration files are in /etc/logdigest. It is available on SuSE, although it is not installed by default.

• logwatch is a series of perl scripts that are able to check different logfiles and services. Logwatch itself knows the default behavior of just about every service that might be running on your Linux system, and filters the interesting log items automatically. Therein lies its weakness too: it is really hard to configure logwatch for a specific situation or service. The logwatch configuration directory, /etc/log.d, is a myriad of scripts, configuration files and symbolic links which make it real hard to figure out where to make a change to get a certain thing to be reported or not.

logwatch is installed on a Red Hat system by default.

• logsurfer again uses positive and negative matches to browse through a logfile, but it uses a slightly more elaborate pattern file, /etc/logsurfer.conf.

logsurfer is available on a SuSE system by default, although it is not automatically installed.

• swatch is a heavy-duty logfile analysis tool which is really popular in the UNIX network administrators world. It is highly configurable and is capable of performing real-time logfile analysis: you’ll hear of any problems only a few seconds after the log lines are added to the logfile, instead of having to wait for a scheduled logfile analysis.

The “hear” in the last sentence can be taken literally: If your pager or cell phone has a scriptable interface, then swatch can send the relevant log entries to your pager or cellphone (SMS) automatically.




Uempty
Depending on your distributions, one or more of these tools might already be installed by default, or need to be installed separately.
A last note: most automated tools submit their results by e-mail, and don’t submit a report if there’s nothing to report. That means that not receiving a report may have two causes:

• There is nothing to report

• Your e-mail subsystem is broken or disabled

Beware of this last pitfall, especially if you use these tools to monitor a large number of systems who do not all send in a report every day.



Student Notebook


Notes:


1.

2.

3.

Checkpoint

What is the purpose of the syslogd daemon?

______________________________________________

What does the logger command do?

______________________________________________

What does logrotate do?

______________________________________________

1)

2)

3)




Uempty


Notes:

Unit Summary

(Nearly) all logging on a Linux system is done through the syslogd daemon

The syslogd daemon sorts the log items according to facility and priority

The logger command allows you to submit log items manually

The logrotate command automatically cleans up old logs



Student Notebook




Uempty
Unit 18. 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, 2004 Unit 18. Printers 18-1

Student Notebook


Notes:

Unit Objectives


Describe the purpose and the benefits of a queuing system

List different printing subsystems

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




Uempty

Figure 18-2. Users, Printer Queues, Printers LX033.1

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.

Users, Printer Queues, Printers

Queue

"bulk"Queue

"color"



Student Notebook

Figure 18-3. Printing Overview LX033.1

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

Printing Overview

Printing Interface

Printer Spool Daemon

Config

files Spool

Print Filter

Printer Backend

Printing subsystem

User interface to

printing subsystem

Daemon manages

the printing subsystem

Temporary storage

space for print files

Converts the print job into

a format suitable for the printer;

performs color substitution,

and so forth

Sends the converted job to the

printer, possibly via the network




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 18-4. Common Printing Subsystems LX033.1

Notes:

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

Common Printing Subsystems

BSDTraditional BSD style printing subsystem (lpr/lpd)RFC 1179

AT&TTraditional AT&T style printing subsystemNot often found on Linux; used in AIX

LPRngPrinting subsystem downwards compatible with BSDUsed in slightly older Linux distributions

CUPS (Common UNIX Printing System)Completely new, modular implementationBased on IPP (Internet Draft)Used in the newest Linux distributions, including Red Hat and SuSEExpected to be the standard in the future on all UNIX




Uempty

Figure 18-5. BSD Printing Subsystem LX033.1

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

BSD Printing Subsystem

User interface exclusively through commandslpr: Submit jobs to printerlpq: List submitted jobslprm: Remove a submitted joblpc: Start/stop queue and printer

Shell variable $PRINTER determines default queue

Spool daemon: lpd

Printer configuration file: /etc/printcap

Authorization files: /etc/hosts.equiv, /etc/hosts.lpd

Supports filters for text and Postscript

Backends supported: parallel port and other LPD printer on network



Student Notebook

that the printer subsystem has no means of communicating the type of print job to the filter. So it’s up to the print filter to determine the type of print job and apply the correct conversions to it.

Print jobs that have been submitted to a BSD printing subsystem can be followed with the lpq command, and can be cancelled with the lprm command. Furthermore, the system administrator can run the lpc command, which allows him/her to prevent jobs being submitted to the queue, prevent jobs being sent to the printer, and to promote jobs to the top of the queue.

In traditional BSD printing, several modern features are not supported. This includes:

• Migrating jobs from one queue to another

• Queues with multiple printers attached for load balancing

• Queue authorization based on username

• Color conversions

Traditional BSD printing supports network printing too. On the print client, the only thing you have to do is identify the print server and printer queue name in the /etc/printcap file. On the server, it requires you to alter the /etc/hosts.equiv or /etc/hosts.lpd file to include the names of all clients that are allowed to print.




Uempty

Figure 18-6. LPR Next Generation (LPRng) LX033.1

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).

LPR Next Generation (LPRng)

Downwards compatible with BSDprinttool, lpr, lpd, lpc, lpq still work

Additional features:Multiple printers per queueMove jobs from one queue to another

Increased security:Does not run as rootDoes not use hosts.lpd, hosts.equivAuthentication can be based on hostname and userid

Configuration files/etc/lpd.conf/etc/lpd.perms/etc/printcap

Supports SMB, NCP and JETDIRECT backends too



Student Notebook

There are more features added, but these are the most important ones.

LPRng also offers increased security. The lpd daemon no longer runs as root, for instance, but can run with user privileges. LPRng no longer uses hosts.lpd and hosts.equiv, thus removing conflicts with rlogin, rsh and rcp. Instead, it uses the /etc/lpd.perms file to configure remote printing authentication. Authentication can be based on both the hostname and the username of the user submitting the job, which allows for a more granular approach.

The last new file is /etc/lpd.conf, which holds a large number of configuration options for LPRng.




Uempty

Figure 18-7. Common UNIX Printing System (CUPS) LX033.1

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.

Common UNIX Printing System (CUPS)

Completely rewritten implementation of UNIX printing system

Supports various frontends:CommandsNetwork (both LPD and IPP)C interface (used by kdeprint)

Supports various backends:Local port (parallel, serial, USB)Network (LPD, IPP, SMB, NCP, JETDIRECT)

Supports printer classes: multiple identical printers in printer pool for load balancing

Supports color conversion and color management through advanced filters

See http://www.cups.org for more information



Student Notebook

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




Uempty

Figure 18-8. CUPS Overview LX033.1

Notes:

The visual shows an overview of CUPS. Important to note is that CUPS can be configured using several methods, and that CUPS allows several frontends to be used for submitting print jobs.

CUPS Overview

Cupsd (Scheduler)

Configuration files

BSD commands (lpr, ...)

kdeprint

System V commands (lp, ...)

Printer filter

Backends

Configuration Tools:

lpadmin, Browser,kdeprint

CUPS-API



Student Notebook

Figure 18-9. Printer Classes LX033.1

Notes:

Before covering the configuration of CUPS, we also need to cover “printer classes”. A “printer class” is a group of multiple more-or-less identical printers. When a user submits a job to a printer class instead of to an individual printer, the print job will be printed using the printer in that class that happens to be free.

Printer classes thus allow you to put multiple, inexpensive printers next to each other and get the same performance as a single, more expensive printer. And you will get redundancy on top of it too.

Obviously, the more the printers are alike, the easier it is to administer a printer class. And obviously users will also appreciate the fact that you put all printers in the same location.

Printer Classes

Printer Class: Laser

# lp -d Laser /file/to/print# lpr -P Laser /file/to/print

A printer class contains multiple more-or-less identical printers

Print jobs are distributed over these printers




Uempty

Figure 18-10. CUPS Configuration with lpadmin LX033.1

Notes:

The first of the three CUPS administration methods is through the command-line tool lpadmin. It allows you to add and remove printers, and to manage printer classes.

When adding a printer, you need to specify what printer model you have. In order to obtain the list of supported models, use the command poll_ppd_base -a, and pick the printer you need.

The printer device is a URI (Uniform Resource Identifier). Some examples of URIs are:

• file:/dev/lp0

• http://hostname:631/ipp/port1

• lpd://hostname/queue

• smb://hostname/sharename

CUPS Configuration with lpadmin

Important options:-p Printername

-m Printer Model (PPD File)

-u Configure User-based Authentication

-v Printer Device (URI)

-E Enable Printer

-c Add this printer to a printer class

-r Remove this printer from a printer class

lpadmin allows you to configure CUPS from a command line



Student Notebook

Figure 18-11. CUPS Configuration with a Browser LX033.1

Notes:

CUPS is usually configured through a browser, connecting to the cupsd daemon at port 631. This gives an easy to use interface for performing the most common management tasks.

Note that cupsd, by default, only allows connections from localhost (127.0.0.1).

CUPS Configuration with a Browser

Use URL http://servername:631




Uempty

Figure 18-12. CUPS Configuration with kprinter LX033.1

Notes:

The third way of configuring CUPS is through its built-in API. An API (Application Programmers Interface) allows an application programmer to build its own tools, and communicate with the cupsd daemon using a standard interface.

The most commonly used tool for configuring CUPS through this API is kprinter, which is the default printer dialog for all KDE applications. It was originally written only to provide an interface to submit jobs, but has later been extended to also allow configuration of printers.

It is expected that more tools will emerge in the future that make use of the CUPS API for job submission and printer configuration.

CUPS Configuration with kprinter

kprinter: Standard printer dialog of all KDE applications

Can also be used to add and manage printers



Student Notebook


Notes:


1.

2.

3.

4.

Checkpoint

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:

Unit Summary

A printer subsystem consists of a printing interface, a printer spool daemon, a printer spool directory, various print filters and a printer backend

Linux distributions use on of the following printer subsystems:

BSDLPRngCUPS

Configuring and managing of the printer subsystem is best done using a system administration program



Student Notebook




Uempty
Unit 19. 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, 2004 Unit 19. Troubleshooting 19-1

Student Notebook


Notes:

Unit Objectives


Perform basic problem determination

Use the rescue mode




Uempty

Figure 19-2. Troubleshooting LX033.1

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.

Troubleshooting

Identifying and fixing problems

Required:Deep understanding of the systemKnowledge of dependencies in the systemKnowledge of problem determination toolsKnowledge of problem solving methodsExperience

Useful:DocumentationReference systemsInternet accessNo outside distractionSparring partner



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 19-3. Identifying the Problem LX033.1

Notes:

Identifying the problem usually starts with reading the logfiles, both the generic logfiles (such as /var/log/messages) and the applications specific logfiles, which are usually located in or under /var/log as well. Most services have a debugging switch which greatly increases the output to the logfile, especially if you reconfigure your /etc/syslog.conf file to log debug output too.

If your logfiles don't give you a clue, read the configuration files for the service that you are debugging. Use syntax checkers like checkpc where available.

Don't forget that a problem in a service might be caused by a problem in an underlying service, such as networking, DNS, PAM, full filesystems, wrong permissions or things like the X Font Server (xfs).

If you’re in a situation where multiple system administrators manage the same systems, then it might be a good idea to start keeping change documentation for each system. This will generally at least provide hints as to what has changed.

Identifying the Problem

Read logfiles (generic and application specific)Debugging switch or key might give more information

Read configuration filesUse syntax checkers if available

Check lower-level servicesNetworking + DNSPAMFilesystem full, wrong permissions?xfs

Check the change documentation for the system

Compare with reference system

Check the Web



Student Notebook

It might be useful to compare the actual situation with a working reference system, for instance your own laptop running Linux.

It might also be useful to check the web. Various Web sites, 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 19-4. strace, ltrace, ldd LX033.1

Notes:

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

ldd is a program which shows you what shared libraries are used by a program, and where these shared libraries reside. Shared libraries are libraries of code which are shared (hence their name) by a number of programs. They typically reside in /lib or /usr/lib, and can be updated independently of the program itself. The /etc/ld.so.conf file lists all the directories (except for /lib and /usr/lib) which contain shared libraries, and the ldconfig command reads all these directories, updates any symbolic links and then writes the cache file /etc/ld.so.cache, which is then used by the runtime linker, ld.so. ld.so is typically automatically invoked by a program that uses shared libraries.

On a well-designed distribution, shared libraries should all be installed correctly due to RPM’s dependency mechanism. Shared library problems typically only occur when this

strace, ltrace, ldd

strace, ltrace: Programs which allow you to see which system calls (strace) and library calls (ltrace) a program makes

Useful to see what a program was trying to do when an error occurred

Usage:strace program [options] [arguments]ltrace program [options] [arguments]

Requires some programming experience to use effectively

ldd: Program which shows what shared libraries are required by a program, and (if present) where they reside

Usage: ldd program



Student Notebook

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




Uempty

Figure 19-5. Core Dumps LX033.1

Notes:

Due to programming or compilation errors, programs may misbehave in certain ways:

• They may try to access memory outside their assigned memory area

• They may try to perform illegal instructions. For instance, a program might try to run a Pentium-III specific instruction on a 80386.

• They may try to divide by zero.

In most cases, the kernel will detect this behavior1, interrupt the program and dump the current state of the program to a “core file”. This file is usually called “core” and may be several megabytes in size.

It is also possible to force the creation of a core dump by sending the program the SIGQUIT signal. This is usually done with <Ctrl-\>. Note however that it is possible for the programmer to write a signal handler that assigns a different meaning to this signal.

1 In fact, it’s usually the CPU that detects these illegal instructions. The CPU will then suspend the program and start the error handler ofthe kernel.

Core Dumps

Due to programming/compilation errors, programs may misbehave

Access memory outside the assigned memory areaPerform illegal instructionsDivide by zero...

In this cases, the kernel will detect this behavior and "dump core": Save the current program state in a "core" file

A core dump can usually be forced with <Ctrl-\>

This file can be read by debuggers such as gdbIs only useful for the programmerCore dumps can generally be deleted without consequence

Saving core dumps can be prevented with ulimit -S -u 0



Student Notebook

This core file can then be used by the programmer to figure out what went wrong in his/her program. For this, the programmer will typically use a debugger such as gdb to read the core file. For other users, a core file is normally not interesting and can safely be deleted. In fact, most system administrators will run a cron job which deletes all core files older than three days automatically.

If you don’t want core dumps to be saved, you can set the maximum size of them to zero with the command ulimit -S -u 0 or ulimit -H -u 0. With the -S option, you are setting a soft limit which can be increased later on, and with the -H option you are setting a hard limit which cannot be increased. Most distributions will set a soft core dump limit of zero by default.




Uempty

Figure 19-6. Fixing the Problem LX033.1

Notes:

Once the error has been found, it needs to be fixed. This is typically a trivial task, but may become more complicated if the system refuses to boot properly because of that error. In that case, there is a number of things you can do:

• Boot from the boot disk that was created during the installation process. This boot disk usually consists of a boot loader (LILO or GRUB), a Linux kernel and (if needed) an Initial Root Disk. This allows you to bypass any problem that might exist in your master boot record or in your /boot partition (kernel image, initrd), but will not help you if the problem is in your root filesystem or further along in the boot process.

A boot disk is typically created with the mkbootdisk shell script, and is system specific to a certain degree:

- The boot loader configuration contains the device name of your root partition, typically something like /dev/hda5. If your root partition has moved, you need to specify a new one at the LILO or GRUB boot prompt with linux root=/dev/hda6

Fixing the Problem

Fixing the problem is usually obvious once you found the error

Can be more complicated if system refuses to boot normally

Solutions:Boot from boot floppyBoot into single user mode and/or with special kernel parameters such as init=/bin/bashBoot into rescue mode



Student Notebook

- The kernel on the boot disk is optimized for your processor. This means that you cannot use a boot disk created on a Pentium-II machine to boot a regular Pentium machine.

- The initial root disk on the boot disk only contains the modules that are needed on your system.

• Boot into single user mode. This requires the boot process, up to and including the /etc/rc.sysinit file to be in full working order, but might help you if you have a problem starting certain services.

On a Fedora/Red Hat system, the single user mode does not prompt for the root password. Therefore, it can be used to recover the root password if that was lost. A SuSE system does require the root password before booting in single user mode, and can thus not be used to recover the root password.

You can also use a boot parameter such as init=/bin/bash or init=/bin/sh. This uses /bin/bash or /bin/sh as first program to start, instead of /sbin/init, and thus gives you a shell prompt immediately. The only disadvantage of this, compared to the single user mode, is that your boot scripts have not yet been executed. This means that only the root filesystem is mounted, read only. Before you can do anything useful you will probably have to mount this read-write with the command mount -o remount,rw / and you might also need to mount other filesystems with mount -a.

• Boot into a rescue mode. In this case, the full boot process is done from CD-ROM or the network. This allows you to fix virtually any problem on disk.




Uempty

Figure 19-7. Rescue Mode LX033.1

Notes:

The rescue mode is a special boot process from a “live” filesystem on CD-ROM or over the network. “Live” in this respect means that the filesystem is either accessed from CD-ROM/network directly, or the CD-ROM/network contains an image of a live filesystem that is loaded into a RAM disk. In both cases, the live filesystem contains enough utilities to fix almost any problem on disk.

Most distributions include the rescue mode as an option in the installation process and/or include special CDs, sometimes the size of a credit card, which allow you to boot into a rescue mode. But credit-card sized rescue CDs are a popular giveaway at trade shows as well.

You can use these rescue CDs real easy since the rescue mode is completely independent of the distribution used. It is perfectly possible to use the SuSE rescue mode to repair a Red Hat system, for instance.

Note that because rescue modes have to operate in limited environments, they usually can not include large programs. Some distributions, including Red Hat, therefore leave out vi and only include the tiny text editor pico.

Rescue Mode

Boot from a "live" filesystem on CD-ROM or networkContains most utilities to fix a systemUsually supported as part of installation program

After booting:May need to create /dev entries with mknodRun fdisk to determine/fix partition tableActivate LVM/RAID volumes if neededRun fsck to check/repair filesystemsRun mount to mount all filesystemsRepair problem; may need/want to use chroot to access filesystem with correct filesystem rootsync and umount all filesystems in proper orderreboot and remove boot media

Some rescue modes do mknod/fdisk/fsck/mount automatically



Student Notebook

No matter which rescue mode you use, some steps will have to be done after the boot process has finished:

• Create /dev device entries with mknod.

Most rescue modes do not include the hundreds of device entries that a normal /dev filesystem would contain (with the resulting space loss) but include an intelligent mknod command which will make these device entries for you, with the proper major and minor numbers.

• Run fdisk to view and/or fix the partition table.

• Activate LVM and/or RAID subsystems.

An LVM detection can be done automatically with the vgscan command. This automatically detects all your volume groups. You then need to activate them with the vgchange -a y <vgname> command, after which your logical volumes are available normally.

Fedora does not include the individual LVM tools (vgscan, vgchange, lvdisplay, ...) but uses an all-in-one, interactive command lvm. After starting this program (without any options) you can type in the familiar LVM commands (vgscan, ...). These commands are then interpreted by lvm.

Activating RAID subsystems basically involves a raidstart command. This command obviously requires your /etc/raidtab file to be intact.

• Run fsck to check each filesystem for errors.

• Run mount to mount each filesystem, usually starting at a location like /mnt/sysimage.

Once these steps have been performed, you are ready to fix the problem. This will require you to go into the filesystems and edit files and so forth. Going into the filesystems can be done with the regular cd command, but this might cause problems when you try to run commands like lilo or rpm, because these programs use absolute pathnames, hard-coded in configuration files. This cannot always be resolved easily.

If you encounter this, it's best to use the chroot command. This performs the chroot() system call, which makes the specified directory the root of your filesystem, and then starts a shell. All commands executed and pathnames referenced in this shell are now relative to the directory that you chrooted into, instead of relative to the root of your rescue disk. This means that commands like lilo and rpm will work without any special options.

Note that a large number of commands that you might want to run in the chroot-ed environment require the presence of the /proc filesystem. It is therefore wise to mount /proc as soon after you executed the chroot.

You can exit the chrooted environment by exiting the shell with exit.

When you finished fixing the problem, you need to umount each filesystem in the proper order. In addition to this, it is wise to perform a sync every now and then, to make sure that changes are indeed written to disk.2 2 The umount command will perform a sync automatically, but we're not taking chances here, are we?




Uempty
When all filesystems are unmounted, you can reboot your system. Don't forget to take out your boot media!
To make this easier for novice users, some rescue modes try to perform the mknod/fdisk/fsck/mount sequence automatically. This works great if you need to recover a root password, but may actually be a hindrance when you need to fix a partition table problem.



Student Notebook


Notes:


1.

2.

3.

Checkpoint

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:

Unit Summary

Troubleshooting is about determining and fixing problems

Troubleshooting requires deep understanding of the system involved and of troubleshooting tools

Always check your logfiles; use debugging switches if available

Always check proper operation of underlying services

strace and ltrace can give you information about the system calls and library calls that a program performs

If a system won't boot, you can use the boot disk, single user mode or the rescue mode to fix the system



Student Notebook




Uempty
Unit 20. 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, 2004 Unit 20. Policies and Procedures 20-1

Student Notebook


Notes:

Unit Objectives


Discuss the need for policies and procedures

Discuss user and administrator policies

Discuss system management procedures




Uempty

Figure 20-2. About Your Systems LX033.1

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 20-3. The Dilemma LX033.1

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 20-4. Policies LX033.1

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 20-5. User Policy LX033.1

Notes:

A user policy typically describes how users can get access to the systems, what they can expect from the systems, and what is expected of them. These policies typically come in the form of handy booklets which also double as simple manuals for using the system.

Some things that need to be listed in a user policy are:

• The applications that are supported by the system, and the level of support that can be expected.

• The privacy policy with regards to personal and group files, e-mail and such.

• The service times: At what hours can the user expect that applications/servers are running and that the help desk is operational.

• Quota on disk space, CPU time and bandwidth.

• How users can obtain support: via telephone, e-mail or personal contact, and when this support is available.

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 how users can obtain supportTelephone, e-mail, personal

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
• The password policy: How often do passwords need to be changed. What are the criteria for “good” passwords. Are users allowed to divulge passwords to others?
• Is usage of the systems for private purposes allowed and if so, when and how much?

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



Student Notebook

Figure 20-6. Administrator Policy LX033.1

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 (for example, 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 20-7. Security Policy LX033.1

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 versus cost of data




Uempty

Figure 20-8. Procedure Handbook LX033.1

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 20-9. Management of System Management LX033.1

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 contractorsDisaster 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?

If possible and practical, test disaster recovery procedures. In most cases however, disaster recovery cannot be tested due to the sheer costs involved in renting floor space, equipment and so forth.

• Hiring/firing/training system administrators. When hiring, do you give them all privileges right away or do you wait a certain amount of time? When firing, what procedures do you perform to make sure that he/she did not leave any trojan horses in the system? What do you do with the data that was stored in the administrators home directory?

• Purchasing guidelines. What brand of equipment do you buy? Are you going to buy rack-mounted equipment or not? When purchasing equipment, do you do a recalculation for weight of racks, power consumption and air conditioning? Are you always shopping around for the best bargain or are you going to stick to one vendor? The latter certainly makes warranty and maintenance contracts easier.



Student Notebook


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 server and controls the hardware (graphical adapter, monitor, mouse, keyboard).


© Copyright IBM Corp. 2001, 2004 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. 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

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 8

1. False

2. /dev/random is blocking: it does not generate more random data when the entropy pool runs out. /dev/urandom is non-blocking: it switches to pseudo-random data once the entropy pool runs out.

3. /sbin/hotplug


A-2 Linux System Administration I © Copyright IBM Corp. 2001, 2004


AP
Unit 9
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 10

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 11

1. Real memory + paging space - ~ 1MB

2. It is reserved for the kernel

3. A paging partition is directly written in the partition table and to disk, while a paging file has to go through the filesystem

4. top continuously displays some vital system information on the screen

Unit 12

1. a. Infrastructure Solutions

b. Application Solutions

c. Workload Consolidation

d. Linux Clusters

e. Distributed Enterprise

f. Desktop

2. A BladeCenter consists of two components:

a. A chassis, which is placed in a standard 19" rack, and houses power units, cooling fans and various peripherals such as floppy and CD ROM drives.



Student Notebook

b. Server blades, which are essentially computers-on-a-board, and which slot into the BladeCenter chassis. Various server blades exist, containing both Intel and PowerPC chips.

3. The main consideration is the architectures that are supported by that particular ISV and the ISVs application. Second is scalability requirements.

Unit 13

1. crontab -l

2. b

3. /etc/cron.deny and /etc/cron.allow

/etc/at.deny and /etc/at.allow

Unit 14

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.

Unit 15

1. b

2. In /etc/shadow.

Unit 16

1. Display a welcome message to users logging in remotely

2. c, e

Unit 17

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 18

1. True

2. No - only system administrators or root




AP
3. False
4. Yes, they can - by only specifying a queue name and not individual job numbers

Unit 19

1. False

2. d

3. mknod, fdisk, fsck, mount, chroot, fix the problem, exit, sync, umount, reboot

Unit 20

1. False

2. b

3. Security, ease of use and cost.



Student Notebook




AP
Appendix B. Certification Information
As mentioned in this course, Linux is not a product which is owned by a single company. Instead, it is developed by a loose team of volunteers on the Internet. As such, there is no “natural” body responsible for Linux certification. At this moment, at least four organizations have tried to fill this void and have come up with their own Linux certification program. IBM supports three of these organizations:

• The Linux Professional Institute (http://www.lpi.org) is an organization run by volunteers with the sole purpose of implementing a vendor-neutral certification program for Linux. They are sponsored by a number of Linux-related companies, among which IBM. The certification tests are delivered by VUE (Virtual University Enterprises) (http://www.vue.com). LPI aims to implement three levels of certification, of which the first two levels are currently ready.

UnitedLinux (the consortium of Linux distributors SuSE, SCO, TurboLinux and Conectiva, http://www.unitedlinux.com) has announced a UnitedLinux certification, which will be an extension of the LPI certification.

• CompTIA (http://www.comptia.org) is the organization that has, in the past, already developed a number of certifications that are aimed mostly at help desk personnel and hardware engineers. Recently CompTIA introduced the Linux+ exam, which is aimed at Linux Professionals with 6 months of experience with Linux. CompTIA tests are also delivered by VUE, and by Prometric (http://www.prometric.com).

• Red Hat (http://www.redhat.com) is the distributor of Red Hat Linux, one of the leading commercial Linux distributions. As part of their service organization they have developed their own education leading to the Red Hat Certified Technician and Red Hat Certified Engineer exams. In contrast to the other Linux exams, the RHCT and RHCE exams are performance based, which means that the examinee takes place behind an actual Red Hat Linux system and needs to demonstrate his/her skills on this system. The practical components of the RHCT exam takes about 2.5 hours, while the practical component of the RHCE exam take about five hours.

For all three certification programs, the support of IBM extends to the following:

1. Involvement and/or active support in developing the certification program, the exam objectives and test questions.

2. Where appropriate: sponsoring the certification program.

3. Developing courseware and teaching courses to prepare students for certification, and where possible certifying this course material for the exams involved.

4. Exam delivery.


© Copyright IBM Corp. 2001, 2004 Appendix B. Certification Information B-1

Student Notebook

IBM IT Education Services Courseware

IBM IT Education Services started developing courseware for Linux at the end of 1998, when no certification programs for Linux existed. The Linux curriculum was heavily modeled after the AIX curriculum, but has changed since to reflect the different ways Linux and AIX are being used today. IBM's Linux course material is not tied to any particular distribution, and is also not tied to any particular certification.

The total curriculum consists of more than fifteen courses that cover the Linux Operating System, and an even larger number of courses that cover IBM middleware that runs on Linux (such as DB2, MQ Series, Lotus Domino and so forth) and IBM hardware. For the purpose of certification though, only seven courses are important:

The LX02 (Linux Power User) is the entry course in the IBM/Linux curriculum. Its aim is to teach a Linux novice to install and configure Linux so that he/she is able to run Linux on his/her personal workstation or home system in an environment that is mostly based on MS-Windows.

The LX03 (Linux System Administration I: Implementation) is the main system administration course. Its aim is to teach a Linux user the techniques and practices used in installing, configuring, running and maintaining a Linux-based server.

The LX07 (Linux Network Administration I: TCP/IP and TCP/IP Services) is the main network administration course. Its aim is to teach a Linux system administrator how to configure TCP/IP and various TCP/IP services that run on Linux.

The LX22 (Linux Perl Programming) is the course that covers Perl programming.

The LX23 (Linux Bash Programming) is the course that covers Bash shell programming and the various programs that are typically used in shell programs, such as grep, awk and sed.

The LX24 (Linux Network Administration II: Network Security and Firewalls) covers the configuration of a full-function firewall under Linux. As such, it also covers a number of security aspects of Linux that are not particularly related to firewalls, but apply to any networked system.

The LX25 (Linux as a Web server - Apache) is the course which covers Apache, the most commonly used web server on Linux and other UNIX platforms.

The LX26 (Linux integration with Windows - Samba) is the course which covers Samba, the product which emulates a networked Windows NT server to the network.

All these courses are available from IBM IT Education Services and selected business partners (pricing and availability may differ from country to country). For information on pricing and scheduling, contact your local IBM IT Education Services representative.

IBM IT Education Services has developed these courses so that they can be taken in a logical order. Furthermore, the organization of topics into courses is such that at the end of a course, a student is able to fully grasp a topic, and is able to apply this successfully on his Linux system(s).


B-2 Linux System Administration I © Copyright IBM Corp. 2001, 2004


AP
From Education to Certification
IBM’s arrangements of topics into IBM’s Linux courses is not always consistent with the requirements of the supported certifications. This leads to a problem when determining which courses are needed for which certification. A certain test might require “installation and basic configuration” of a product. This is covered by a certain IBM/Linux course, but that very same course also covers “advanced configuration”, which might be the subject of an entirely different test.

As an example, IBM has one, two-day course about Samba (the LX26), which fully covers the whole Samba product and its possibilities. Samba knowledge is tested by the LPI in two places though: Test 102 (topic 1.13, objective 4) requires the examinee to “install and configure Samba using the included GUI tools or direct edit of the /etc/smb.conf file” (which is covered in the first two units of the LX26), while test 201 (topic 2.9, objective 1) requires that “the candidate should be able to set up a Samba server for various clients, including setting up a login script and setting up and nmbd WINS server” (which is the end objective of the LX26).

This problem is too fundamental to solve by simply changing or rearranging the course material, apart from the fact that we think that it is not desirable to specifically write courses for certification. One of the purposes of this attachment is therefore to identify the areas where IBM's course material does not match with certification objectives.


© Copyright IBM Corp. 2001, 2004 Appendix B. Certification Information B-3

Student Notebook

Education/Certification Matrix

The following table lists the required and recommended courses for each of the supported certification programs:

Remarks to the table:

1. Required means: the subjects covered in this course are essential knowledge to pass the exam.

Recommended means that a small portion of the exam (less than 5%) is covered in the course listed. It is possible to pass the exam without this knowledge. Students do so however at their own risk and should compare their knowledge with the exam objectives.

2. CompTIA Linux+ also requires intimate knowledge of PC hardware in general (Domain 7) which accounts for 19% of the exam. This includes knowledge of the BIOS, IRQs, I/O ports, DMA, ATA devices, SCSI devices, IEEE 1394 devices, PCMCIA devices, ISA devices, PCI devices, APM and the ability to configure and replace them, were applicable. This part of the exam is not related to Linux and thus not covered in any of IBM’s Linux courses. CompTIA’s own education (and other education) that leads to CompTIA A+ certification may be used to obtain this knowledge.

3. ProCert (http://www.procert.com) has certified these courses as appropriate course material for preparing for LPI certification tests. This certification is only valid if all courses, including the courses that are listed here as “recommended” are taken before attempting an LPI certification test.

4. IBM IT Education Services is a Red Hat Authorized Training Partner and as such allowed to teach the Red Hat courses RH033, RH133 and RH253. These courses can be used as an alternative to LX02, LX03 and LX07, respectively, to prepare for RHCT/RHCE certification. They cannot be used for other certifications though, and these courses are not scheduled in all countries.

CourseCompTIA LPI Red Hat

Linux+ Test 101 Test 102 Test 201 Test 202 RHCT RHCE

LX02 Required Required Required Required Required Required Required

LX03 Required Required Required Required Required Required Required

LX07 Recomm. Required Required Required Required

LX22 Recomm.

LX23 Recomm. Recomm.

LX24 Required Recomm.

LX25 Recomm. Recomm. Required Recomm.

LX26 Recomm. Required Recomm.


B-4 Linux System Administration I © Copyright IBM Corp. 2001, 2004


IX
Index
Symbols$DISPLAY 6-19$PRINTER 18-7%packages 2-6%post 2-6%pre 2-7.config 7-8, 7-14.hushlogin 15-19.rpmorig file 5-7.rpmsave file 5-7.Xauthority 6-20/boot 3-9/boot/grub/grub.conf 3-13/boot/grub/menu.lst 3-13/dev/dsp 8-12/dev/lp0 8-11/dev/null 8-5/dev/psaux 8-11/dev/random 8-6/dev/sda 9-7/dev/shm 10-30/dev/ttyS0 8-7/dev/urandom 8-6/dev/zero 8-5/etc/anacrontab 13-10, 13-12/etc/at.allow 13-16/etc/at.deny 13-16/etc/cron.allow 13-5/etc/cron.deny 13-5/etc/crontab 13-9/etc/fstab 10-18, 10-20, 10-22, 10-30, 10-33/etc/group 15-17/etc/gshadow 15-8, 15-17/etc/init.d/boot 3-20/etc/init.d/rc 3-21/etc/inittab 3-19, 3-20, 3-27, 7-23/etc/isapnp.conf 7-21/etc/issue 15-18/etc/ld.so.conf 19-7/etc/lilo.conf 3-7, 3-8/etc/login.defs 15-9, 15-10/etc/logrotate.conf 17-12/etc/modules.conf 7-25/etc/motd 15-19/etc/nologin 16-9/etc/passwd 15-14/etc/rc.d/rc 3-21/etc/rc.d/rc.sysinit 3-20/etc/securetty 16-8/etc/security 16-11/etc/shadow 15-8, 15-10, 15-15/etc/skel 15-11

Course materials may not be rwithout the prior writte

© Copyright IBM Corp. 2001, 2004

/etc/smartd.conf 9-9/etc/sysctl.conf 7-27/etc/syslog.conf 17-7/etc/syslogd.conf 17-4/etc/X11/XF86Config 6-11/etc/X11/xorg.conf 6-11/proc/lvm 9-26/proc/sys 7-27/sbin/hotplug 8-13/sbin/init 7-23/var/log/lastlog 16-23/var/log/messages 16-23, 19-5/var/log/secure 16-23/var/log/wtmp 16-23/var/run/umtp 16-23

AAccess Control List 10-14ACL. See Access Control Listadduser 15-10administrator policy 20-8air conditioning 1-10Air conditioning capacity 1-11air fans 1-14AIX 9-26, 10-28Alien 5-30alsaconf 8-12anaconda-ks.cfg 2-8anacron 13-10apt-get 5-29at 13-13

-d option 13-16-l option 13-16

ATAPI 9-7atd 13-13atime 10-9atq 13-16atrm 13-16authconfig 4-5, 16-10authentication 16-3authorization 16-3

BB+ trees 10-15, 10-28bash 3-26Basic Input Output System 3-4batch 13-15binary RPM 5-16binary trees 10-15BIOS. See Basic Input Output System

eproduced in whole or in part n permission of IBM.

Index X-1

Student Notebook

block device 8-3, 9-3boot device 3-4boot loader 3-5, 7-4British Thermal Units 1-11

Ccarbon monoxide 1-12CardBus 8-13cardmgr 8-13cat 7-27CD-ROM 2-3character device 8-3chattr 10-26chkconfig 3-24chmod 16-16chroot 19-14circuit breakers 1-8cleaning 1-14computer room 1-4console 8-3convertquota 10-32core dump 19-9core file 19-9cpio 14-10, 14-14Cron 13-4crond 13-4crontab 13-4, 13-8

-e option 13-8-l option 13-8-r option 13-8

crypt 15-15ctime 10-9Ctrl-Alt-Backspace 6-15Ctrl-Alt-Delete 3-21, 3-27CUPS 18-6, 18-11cupsd 18-16, 18-17curses 4-3

Ddata backup 14-3, 14-6Data block 10-7data block 10-11dd 14-10, 14-18Debian 5-29Debian packages 5-29debugfs 10-25debugreiserfs 10-27depmod 7-17, 7-25dictionary attack 15-8, 16-9diesel generator 1-9diff 7-7directory 10-11Disk Druid 9-12-display 6-19

display manager 3-27dmesg 3-16, 7-16, 9-7double indirect block 10-9dpkg 5-29dselect 5-29dump 10-19, 14-10, 14-15DVD 2-3

Ee2label 10-26echo 7-27edquota 10-34EEPROM 3-4E-IDE 9-6electric power 1-8elm 5-11encryption 9-14ext2 10-6, 10-25ext3 3-17, 10-6, 10-25extended partition 9-10extendfs 10-28

Ffdformat 9-5fdisk 3-5, 9-12, 19-14file 10-3filesystem 10-3fips 9-12fire detection 1-12fire suppression 1-12font server 6-25free 11-8freeramdisk 9-13fsck 10-15, 10-19, 10-23, 19-14

-y option 10-24full backup 14-3, 14-5fuses 1-8

Ggaleon 4-10gdb 19-10gdm 3-21, 6-16, 6-23General Public Licenc 5-3getty 3-21ghostscript 18-7GID 15-3, 15-14gnorpm 5-25GNU 5-3GPL. See General Public Licensegrace period 10-31GRand Unified Boot Loader 3-10grep 17-13

-v option 17-13


X-2 Linux System Administration I © Copyright IBM Corp. 2001, 2004

Student Notebook

ground 1-13Group ID 15-3grub 3-11GRUB. See Grand Unified Boot Loadergrub-install 3-11

Hhalt 3-27Hard disks 9-6Hard limit 10-31Hardware RAID 9-31Hardware-HOWTO 3-15hexdump 8-6hotplug 8-13hot-pluggable devices 8-13humidity 1-10Hummingbird eXceed 6-6Hurd 3-6

IIBM MWave 8-8IDE 9-6immutable 10-15incremental backup 14-3, 14-6Indirect block 10-7indirect block 10-9init 3-19, 3-21, 3-23, 3-26, 6-16, 7-23Initial RAM Disk 3-17Initial Root Disk 3-17initial root disk 7-10initrd 7-15, 9-26, 9-36Inode 10-7inode 10-9, 10-11inode block 10-7insmod 7-17internal modems 8-8Internet Explorer 4-10Intrusion Detection Systems 5-14IPP 18-6isapnp 7-21ISDN cards 8-8ISO images 9-14iso9660 10-17

JJFS 3-17, 10-6, 10-28Joules 1-11Journaling 10-14

Kkdm 3-21, 6-16, 6-23kernel 3-15, 7-3kernel modules 3-17, 7-10

Kernel sources 7-5kerneld 7-18Kickstart 2-6klogd daemon 17-4konqueror 4-10kpackage 5-25kprint 18-11kprinter 18-17ks.cfg file 2-6ksconfig 2-7KVM switches 8-9

LLabels 10-15last 16-23lastlog 16-23ldconfig 19-7ldd 19-7lilo 3-7, 19-14LILO. See Linux Loaderlinks 4-10Linux Documentation Project 19-6Linux Loader 3-5, 3-7linuxrc 3-18logcheck 17-14logdigest 17-14logger 17-9logical partition 9-10Logical Volume Management 9-15Logical Volumes 9-16logrotate 17-10, 17-12logsurfer 17-14logwatch 17-14lokkit 4-5loop device 9-14losetup 9-14lp 18-11lpadmin 18-15lpc 18-8lpd 18-7lpq 18-8lpr 18-4, 18-7, 18-11

-P option 18-7lprm 18-8LPRng 18-6, 18-9ls

-l option 8-4lsdev 8-14lseek 10-15lsmod 7-17ltrace 19-7Lucent winmodem 8-8lvcreate 9-18, 9-21lvdisplay 9-21lvextend 9-24


© Copyright IBM Corp. 2001, 2004 Index X-3

Student Notebook

LVM 3-17lvm 19-14LVM metadata 9-25LVM. See Logical Volume Managementlvm-mod 9-26lvremove 9-21, 9-24LX07 8-7lynx 4-10

Mmail 5-11mailx 5-11make bzImage 7-12make bzlilo 7-13make clean 7-12make config 7-8make dep 7-12make menuconfig 7-8make modules 7-13make modules_install 7-14make mrproper 7-5make oldconfig 7-9make xconfig 7-8make zlilo 7-13man 4-4Master Boot Record 3-4, 3-5master boot record 9-10MBR. See Master Boot RecordMD5 15-15MD5 checksum 5-13Memory chips 1-13Metro-X 6-7mgetty 8-9mirroring 9-26mk_initrd 7-11, 7-15mkbootdisk 19-11mke2fs 10-16

-j option 10-25mkfs 10-16mkinitrd 3-9, 7-11, 7-15mkjfs 10-16mknod 19-14mkpasswd 15-13mkraid 9-33mkreiserfs 10-16mkswap 11-6modinfo 7-18modprobe 7-17, 7-25mount 9-14, 10-17, 10-18, 16-12, 19-14

-o option 9-14, 10-17, 10-20-t option 10-17

mount point 10-4mouse 8-11mouseconfig 4-5mozilla 4-10

mtime 5-13, 10-9multiport cards 8-7MWave 8-8

Nnetconf 4-5netscape 4-10network adapter 2-3network install server 2-3, 2-4network installation 2-3null device 8-3null-modem cable 8-9

Oopera 4-10OS/2 10-28

PPAE. See Processor Address ExtensionPAM modules 16-11PAM. See Pluggable Authentication Modulesparted 9-12partition table 3-5, 9-12partitioning 9-10PartitionMagic 9-12passwd 15-13, 16-12password 15-3, 16-8password aging 15-9patch 7-7patch files 7-6Paul Vixie 13-4PCMCIA 8-13permission bits 16-14Physical Extents 9-15Physical Volume 9-15pico 19-13pine 5-11pivot_root 3-18Pluggable Authentication Modules 16-4pnpdump 7-21poll_ppd_base 18-15POSIX 10-30poweroff 3-27prefdm 3-21primary group 15-6primary partitions 9-10printconf 4-5printer class 18-14printer queue 18-3pristine sources 5-4, 5-16procedure handbook 20-11Processor Address Extensio 11-3procinfo 11-9



Student Notebook

protected mode 3-16ps 11-8pvcreate 9-18, 9-19pvdisplay 9-19pvmove 9-19, 9-23

QQuota 10-31quota 10-36quotacheck 10-33quotaon 10-32, 10-33

Rrack-mounted 1-6RAID 3-17RAID. See Redundant Array of Inexpensive DisksRAID-0 9-28RAID-1 9-29RAID-4 9-29RAID-5 9-29raidhotadd 9-35raidhotremove 9-35RAID-Linear 9-28raidsetfaulty 9-34raidtools 9-31RAM disk 9-13random number generator 8-3rc 3-22, 3-25reboot 3-27, 19-15Red Hat Network 5-27Red Hat Package Manager 5-3redhat-config-bin 4-6redhat-config-date 4-6redhat-config-httpd 4-6redhat-config-keyboard 4-6redhat-config-kickstart 2-7, 4-6redhat-config-language 4-7redhat-config-mouse 4-7redhat-config-network 4-7redhat-config-nfs 4-7redhat-config-packages 4-7, 5-25redhat-config-printer 4-7redhat-config-proc 4-7redhat-config-rootpassword 4-7redhat-config-samba 4-7redhat-config-securitylevel 4-7redhat-config-services 3-24, 4-7redhat-config-soundcard 4-7, 8-12redhat-config-users 4-7redhat-config-xfree86 4-7Redundant Array of Inexpensive Disks 9-27ReiserFS 3-17, 10-6, 10-27reject files 7-7repquota 10-36

rescue mode 19-13resize_reiserfs 10-27resize2fs 10-26restore 14-15rhnsd 5-27rmmod 7-17rpm 5-3, 5-7, 19-14

-a option 5-9--aid option 5-11-bb option 5-4-c option 5-9--checksig option 5-15-d option 5-9-e option 5-8-F option 5-6, 5-26-f option 5-9-h option 5-7-i option 5-6, 5-9--import option 5-15-l option 5-9--nodeps option 5-7-p option 5-9-q option 5-9-s option 5-9-U option 5-6-V option 5-13-v option 5-7

RPM Package Manager 5-3RPM. See RPM Package Managerrpmbuild 5-5, 5-22rpmdb 5-11runlevel 3-19

Sscript 20-8SCSI 3-17, 9-7SCSI ID 9-7scsi_info 9-7security policy 20-10Self Monitoring and Reporting Technology 9-8Self-Referencing Acronym 5-3serial terminal 8-3serial terminals 8-9service 3-25Session Manager 6-16setserial 8-8setup 4-5SGID 5-13, 16-15, 16-16shadow password suite 15-8, 15-9Shared Memory Filesystem 10-30shutdown 3-21, 3-26, 3-27sine wave 1-9single 3-26Single-User Mode 3-26SMART 9-8



Student Notebook

smartctl 9-8-a option 9-8-x option 9-8

smartd 9-9smartd.conf 9-9smartmontools 9-8Smoke detectors 1-12snapshot 9-26Soft limit 10-31Software RAID 9-31sound card 8-12Source RPM 5-4spare disks 9-36sparse files 10-15SPEC file 5-16, 5-17, 5-18

%doc identifier 5-20changelog section 5-21files section 5-20install section 5-20preamble section 5-19prep section 5-20

SRA. See Self-Referencing Acronymstand-alone 1-6startx 6-13Sticky Bit 16-15sticky bit 16-16strace 19-7striping 9-22su 16-12, 16-19, 16-20sudo 16-13, 16-21SUID 5-13, 16-15, 16-16Sun Microsystems 16-4Superblock 10-7superblock 10-8Surge Arresters 1-9swap space 9-37swapoff 11-6, 11-7swapon 11-6swatch 17-14Symbolic link 5-13sync 11-8, 19-14sysctl 7-27syslog daemon 17-3syslogd

-r option 17-8syslogd daemon 17-4System Administration Tools 4-3system backup 14-3, 14-5System.map 7-14

Ttail

-f option 16-24tar 14-10, 14-11temperature 1-10

timeconfig 4-5ton 1-11toolbox 1-14top 11-8triple indirect block 10-10tripwire 5-14tune2fs 10-25

UUID 15-3, 15-14ulimit 19-10umask 16-17umount 10-22, 19-14Uninterruptable Power Supplies 1-9UNIX socket 6-6, 17-4up2date 5-27, 5-29UPS. See Uninterruptable Power Supplyuptime 11-8USB 8-13usbmodules 8-14usbview 8-14user account 15-4user ID 15-3user policy 20-5, 20-6User Private Groups 15-7useradd 15-10userdel 15-10usermod 15-10

VVFS. See Virtual Filesystem Switchvgcfgbackup 9-25vgcfgrestore 9-25vgchange 9-20vgcreate 9-18, 9-20VGDA. See Volume Group Descriptor Areavgdisplay 9-20vgexport 9-20vgextend 9-20, 9-23vgreduce 9-23vgremove 9-20vi 19-13virtual filesystem 10-4Virtual Filesystem Switch 10-5vmstat 11-9Volt 1-8Volume Group 9-15Volume Group Descriptor Area 9-19, 9-25

Wwall 17-4, 17-8Watt 1-8, 1-11Webmin 4-9



Student Notebook

Webmin installation 4-10which 5-10who 16-23window manager 6-4winmodems 8-8write 17-4, 17-8WRQ Reflection X 6-6

XX server 6-4X station 6-4X Window System 6-3xauth 6-20xbanner 6-4xcalc 6-4xdm 3-21, 6-16, 6-22xedit 6-5xeyes 6-4XFree86 6-7XFS 10-6xfs 6-25, 6-26, 19-5xhost 6-20Xi Graphics 6-7xload 11-8xosview 11-8xpeek 10-28xsysinfo 11-8xterm 6-4

Yyast 3-24, 4-8, 5-12, 5-25, 8-12Yast Online Update 5-28YaST. See Yet another Setup Toolyast2 4-8Yellowdog Updater, Modified 5-26Yet another Setup Tool 4-8you 5-28yum 5-26yum-arch 5-26



Student Notebook



V2.0

backpg
Back page

��®