IUTXE Lx30stud

V5.
cover
Front cover
Linux System Administration I: Implementation

(Course code LX03)
Student Notebook
ERC 6.0
IBM certified course material
Student Notebook
Trademarks IBM is a registered trademark of International Business Machines Corporation. The following are trademarks of International Business Machines Corporation in the United States, or other countries, or both: AIX Balance DB2 General Parallel File System iSeries MVS OS/2 POWER pSeries SP System p System z XT z/VM AS/400 BladeCenter Domino GPFS LoadLeveler Notes OS/390 POWER4 RS/6000 System i System p5 System z9 z9 400 AT Chipkill eServer i5/OS Lotus OpenPower OS/400 PowerPC S/390 System i5 System x Tivoli z/OS
VMware and the VMware "boxes" logo and design, Virtual SMP and VMotion are registered trademarks or trademarks (the "Marks") of VMware, Inc. in the United States and/or other jurisdictions. PS/2 is a trademark or registered trademark of Lenovo in the United States, other countries, or both. Adobe and PostScript are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. Intel, Intel Xeon, Itanium, Pentium and Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
January 2009 edition
The information contained in this document has not been submitted to any formal IBM test and is distributed on an as is basis without any warranty either express or implied. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customers ability to evaluate and integrate them into the customers operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will result elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.
Copyright International Business Machines Corporation 2001, 2009. All rights reserved. This document may not be reproduced in whole or in part without the prior written permission of IBM. Note to U.S. Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Student Notebook
Microsoft, Windows and Windows NT are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. AMD and AMD Opteron and combinations thereof, are trademarks of Advanced Micro Devices, Inc. Other company, product, or service names may be trademarks or service marks of others.
iii
Linux System Administration I
Copyright IBM Corp. 2001, 2009
Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Student Notebook
iv
V5.2
Student Notebook
TOC
Contents
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Course description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Certification information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Unit 1. Advanced Linux installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2 Installing Linux: Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3 Disk partitioning: Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5 Network installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7 Network install server: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9 Network install server: Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11 RHEL/Fedora kickstart installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13 RHEL/Fedora kickstart example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15 SLES AutoYaST installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17 AutoYaST example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19 Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20 Exercise 1: Advanced Linux installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21 Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22 Unit 2. Startup and shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1 Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2 Linux startup flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3 Basic Input/Output System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4 Master Boot Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5 GRand Unified Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6 GRUB startup sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8 /boot/grub/grub.conf or /boot/grub/menu.lst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9 Starting the kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11 Initial RAM Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13 init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15 /etc/inittab (RHEL/Fedora/SLES) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18 Starting services (System V init style) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21 Configuring services per runlevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23 Starting and stopping services manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25 Booting Linux in single-user mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-27 Shutting down a Linux system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29 Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30 Exercise 2: Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31 Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32

Contents
Student Notebook
Unit 3. System administration tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1 Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2 System administration tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3 RHEL/Fedora setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5 RHEL/Fedora system-config-* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-7 SUSE YaST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-9 Webmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10 Webmin rpm installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-11 Webmin screenshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12 Users, printer queues, printers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-13 Common printing subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-14 Common UNIX printing system (CUPS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-16 CUPS overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-18 CUPS configuration with lpadmin . . . . . . . . . . . . . . . . . . . 3-21 CUPS configuration with a browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-22 CUPS configuration with system-config-printer . . . . . . . . . . . . 3-23 CUPS configuration with yast . . . . . . . . . . . . . . . . . . . . 3-25 CUPS configuration with kprinter . . . . . . . . . . . . . . . . . . 3-26 Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-27 Exercise 3: System administration tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-28 Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-29 Unit 4. Package management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1 Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2 Software management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3 RPM Package Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4 Software archives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6 RPM-related commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8 RPM database files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9 RPM installing, freshening, and upgrading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-11 RPM uninstalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-13 RPM querying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-14 RPM verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16 RPM signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18 RPM philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-20 Creating RPMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-22 Example Scenario: Hello, world! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-24 hello.spec preamble section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-25 hello.spec prep, build, install, and files section . . . . . . . . . . . . . . . . . . . . . . . . . . .4-26 RPM build process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-28 After RPM build process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-30 Integrated package management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-31 Keeping up-to-date (Fedora) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-33 Keeping up-to-date (Red Hat) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-35 Keeping up-to-date (SUSE Linux) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-36 Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-37 Exercise 4: Packaging tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-38 Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-39
vi Linux System Administration I Copyright IBM Corp. 2001, 2009
V5.2
Student Notebook
TOC
Unit 5. X Window system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1 Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2 X window system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3 X client/server architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-5 Examples of X stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7 X servers in Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9 X.org configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10 Starting X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12 Stopping X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14 Session managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-15 X networked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-16 X applications networked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18 Applications over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19 Secure shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-22 X sessions networked . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-23 X sessions over TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-24 Chooser sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-26 Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-27 Exercise 5: X window system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-28 Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-29 Unit 6. Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1 Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2 Logging concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3 Facilities and priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5 /etc/syslog.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-7 logger command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-9 logrotate command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10 Sample /etc/logrotate.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12 Analyzing logfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14 Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17 Exercise 6: Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18 Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19 Unit 7. Character devices, PCMCIA, and USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1 Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2 Character devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3 Character device naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-4 Virtual character devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5 Serial devices, modems, and ISDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8 Serial terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10 Parallel and PS/2 ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-12 Sound cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13 PCMCIA devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15 lspci command output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17 USB devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-18 lsusb command output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20 Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-21
Contents
vii
Student Notebook
Exercise7: Character devices, PCMCIA, and USB . . . . . . . . . . . . . . . . . . . . . . . . .7-22 Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-23 Unit 8. Block devices, RAID, and LVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1 Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3 Block devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4 Traditional block device naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5 Dynamic device naming with udev. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6 Floppy disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-10 Hard disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-11 Monitoring hard disk health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-13 Hard disk partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-15 Partitioning tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-17 RAM disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-18 The loop device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-19 Logical volume management (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-21 Logical volume management (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-23 LVM implementation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-24 Physical volume commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-25 Volume group commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-26 Logical volume commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-27 Striping logical volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-28 Extending/reducing a volume group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-29 Extending/reducing a logical volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-30 LVM backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-31 Additional LVM considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-32 RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-34 RAID levels (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-36 RAID levels (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-38 Linux RAID support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-39 Linux software RAID implementation: mdadm . . . . . . . . . . . . . . . 8-40 mdadm modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-42 mdadm implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-44 Watching a running RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-46 Spare disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-48 Additional RAID considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-50 Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-52 Exercise 8: Block devices, LVM, and RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-53 Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-54 Unit 9. Filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1 Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3 What is a file? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4 What is a filesystem? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-6 The virtual filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7 Filesystems supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9 Filesystem example: ext2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10 Superblock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-11
viii Linux System Administration I Copyright IBM Corp. 2001, 2009
V5.2
Student Notebook
TOC
Inodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ext2fs summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other filesystem features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mounting a filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mounting filesystems at system startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mount options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unmounting filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking a filesystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ext2/ext3-specific information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ReiserFS-specific information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comparing filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SHMFS-specific information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quota concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quota implementation on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quota information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exercise 9: Filesystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9-12 9-14 9-15 9-17 9-19 9-20 9-21 9-23 9-25 9-26 9-28 9-30 9-32 9-33 9-34 9-36 9-37 9-38 9-40 9-41 9-42 9-43
Unit 10. Memory management and Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1 Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2 Linux memory management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-3 Example: Lightly loaded system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-5 Example: Heavily loaded system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-6 Creating paging space: Partition/LV/RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7 Creating paging space: File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-9 Useful memory-related commands/files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-10 procinfo command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-11 /proc/meminfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-13 free command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-15 top command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-18 vmstat command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-21 vmstat s command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-24 ps command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-25 Process memory: /proc/PID/status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-28 Process memory: /proc/PID/maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-31 Xen overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-33 Xen installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-34 Booting the Xen kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-35 Xen domain configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-36 Example Xen configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-37 Booting a guest domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-38 Xen domain management (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-39 Xen domain management (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-40
Contents
ix
Student Notebook
File system management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-41 Networking in Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-42 Virtual Machine Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-43 Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-44 Exercise 10: Memory management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-45 Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-46 Unit 11. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-1 Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-2 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-3 Cron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-4 User crontab example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-6 crontab command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-8 System crontab file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-9 anacron (RHEL/Fedora) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-10 /etc/anacrontab (RHEL/Fedora) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-12 at command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-13 batch command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-15 Controlling at Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-16 Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-17 Exercise 11: Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-18 Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11-19 Unit 12. Backup and restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-1 Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-3 Backup schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-4 Incremental versus differential backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-6 Sample monthly backup scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-7 Backup devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-8 Default backup tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-10 tar command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-11 GNU tar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-13 cpio command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-14 dump command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-15 dd command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-16 Other backup tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-17 Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-18 Exercise 12: Backup and restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-19 Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-20 Unit 13. User administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-1 Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-2 Security concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-3 User hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-4 Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-6 User private groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-8 Shadow password suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-10 Command line user tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-12
x Linux System Administration I Copyright IBM Corp. 2001, 2009
V5.2
Student Notebook
TOC
/etc/skel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Command line group tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /etc/passwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /etc/shadow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /etc/group and /etc/gshadow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /etc/issue and /etc/issue.net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message of the day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exercise 13: User administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13-13 13-14 13-15 13-16 13-17 13-19 13-20 13-21 13-22 13-23 13-24
Unit 14. User-level security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1 Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2 User-level security overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-3 Pluggable Authentication Modules (PAM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5 Authentication before PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-6 Authentication with PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-8 PAM configuration file example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-10 Common PAM modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-13 Principles of authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-14 File permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-16 Changing permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-18 umask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-19 Example: Creating a team directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-20 Root access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-21 su command . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-23 sudo command . . . . . . . . . . . . . . . . . . . . . . . . . . 14-24 Security logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-26 Useful commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-28 Additional commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-29 Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-30 Exercise 14: User-level security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-31 Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-32 Unit 15. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1 Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-2 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-3 Identifying the problem: Part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-5 Identifying the problem: Part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-7 Core dumps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-9 Fixing the problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-11 What is Rescue Mode? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-13 Use available rescue tools (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-15 Use available rescue tools (2 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-16 Use available rescue tools (3 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-17 chroot command . . . . . . . . . . . . . . . . . . . . . . . . . 15-18 Booting Rescue Mode: RHEL/Fedora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-20
Contents
xi
Student Notebook
Using Rescue Mode: RHEL/Fedora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-22 Booting Rescue Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-23 Using Rescue Mode: SUSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-25 Repair installed system: SUSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-26 Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-29 Exercise 15: Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-30 Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15-31 Appendix A. Checkpoint solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1 Appendix B. Certification information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1 Appendix C. Physical planning and maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . C-1 Appendix D. Policies and procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D-1 Appendix E. Kernel compilation and configuration . . . . . . . . . . . . . . . . . . . . . . . . . E-1 Appendix F. Linux on IBM servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . F-1 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X1 Glossary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X5 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X-13
xii
V5.2
Student Notebook
TMK
Trademarks
The reader should recognize that the following terms, which appear in the content of this training document, are official trademarks of IBM or other companies: IBM is a registered trademark of International Business Machines Corporation. The following are trademarks of International Business Machines Corporation in the United States, or other countries, or both: AIX Balance DB2 General Parallel File System iSeries MVS OS/2 POWER pSeries SP System p System z XT z/VM AS/400 BladeCenter Domino GPFS LoadLeveler Notes OS/390 POWER4 RS/6000 System i System p5 System z9 z9 400 AT Chipkill eServer i5/OS Lotus OpenPower OS/400 PowerPC S/390 System i5 System x Tivoli z/OS
VMware and the VMware "boxes" logo and design, Virtual SMP and VMotion are registered trademarks or trademarks (the "Marks") of VMware, Inc. in the United States and/or other jurisdictions. PS/2 is a trademark or registered trademark of Lenovo in the United States, other countries, or both. Adobe and PostScript are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. Intel, Intel Xeon, Itanium, Pentium and Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Microsoft, Windows and Windows NT are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries.
Trademarks
xiii
Student Notebook
AMD and AMD Opteron and combinations thereof, are trademarks of Advanced Micro Devices, Inc. Other company, product, or service names may be trademarks or service marks of others.
xiv
V5.2
Student Notebook
pref
Course description
Linux System Administration I: Implementation Duration: 4 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 administrators 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: Install Linux from a network install server Manage system startup and shutdown Select and use system administration tools when appropriate Configure and manage printers Use packaging tools to create, install, and de-install packages Configure and manage the X Window System Manage logging Manage character devices, Personal Computer Memory Card International Association (PCMCIA), and Universal Serial Bus (USB) Manage hard disks, partitions, Redundant Array of Independent Disks (RAID), and Logical Volume Management (LVM) Create and manage filesystems Perform memory management and Xen management
Course description
xv
Student Notebook
Use scheduling tools Create and restore backups Perform user administration Apply user-level security Troubleshoot Linux problems
Contents
Advanced Linux installation System startup and shutdown System administration tools Printers Packaging tools X Window system Logging Character devices, PCMCIA, and USB Managing hard disks, partitions, LVM, and RAID Filesystems Memory management and Xen management Scheduling Backup and restore User administration User-level security Troubleshooting Optional material Physical system management and planning Policies and procedures Kernel compilation
xvi
V5.2
Student Notebook
pref
Agenda
Day 1
Unit 1- Advanced Linux installation Exercise 1- Advanced Linux installation Unit 2- Startup and shutdown Exercise 2- Startup and shutdown Unit 3- System administration tools Exercise 3- System administration tools
Day 2
Unit 4- Package management Exercise 4- Packaging tools Unit 5- X Window system Exercise 5- X Window system Unit 6- Logging Exercise 6 - Logging
Day 3
Unit 7- Character devices, PCMCIA, and USBUnit 8- Block devices, RAID, and LVM Exercise 8- Block devices, RAID, and LVM Unit 9- Filesystems Exercise 9- Filesystems Unit 10 - Memory management and Xen Exercise 10 - Memory management and Xen
Day 4
Unit 11 - Scheduling Exercise 11 - Scheduling Unit 12 - Backup and restore Exercise 12 - Backup and restore Unit 13 - User administration Exercise 13 - User administration Unit 14 - User-level security Exercise 14 - User-level security Unit 15 - Troubleshooting Exercise 15 - Troubleshooting Wrap-up, optional exercises
Agenda
xvii
Student Notebook
Distribution naming conventions

This course deals with multiple distributions of the Linux operating system. The following acronyms will be used throughout the course. - Red Hat Enterprise Linux Entry Server RHEL: Applies to all versions of Red Hat Enterprise Linux RHEL5: Applies to Red Hat Enterprise Linux 5 rhel51s: Applies to Red Hat Enterprise Linux Server 5 - Fedora Linux Fedora: Applies to all versions of Fedora fedo8: Applies to Fedora Linux 8 - SUSE Linux Enterprise Server SLES: Applies to all versions of SUSE Linux Enterprise Server SLES10: Applies to SUSE Linux Enterprise Server 10 suse10sp1: Applies to SUSE Linux Enterprise Server Service Pack 1
xviii Linux System Administration I
V5.2
Student Notebook
pref
Certification information
Several professional certifications currently exist for Linux. This course, combined with other Linux courses, prepares you for all of them. For more information, refer to 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.
Certification information
xix
Student Notebook
xx
V5.2
Student Notebook
Uempty
Unit 1. Advanced Linux installation

What this unit is about
This unit teaches you how to perform advanced (non-CD) installations.
What you should be able to do

After completing this unit, you should be able to: Perform a network installation Discuss network install servers Discuss RHEL/Fedora kickstart installations Discuss SLES AutoYaST installations
How you will check your progress

Accountability: Checkpoint questions Machine exercises
References
Linux man pages SUSE Linux 10 Installation and Administration Guide RedHat Enterprise Linux V5 Administration Guide RedHat Enterprise Linux V5 Installation Guide
1-1
Student Notebook
Unit objectives
After completing this unit, you should be able to: Perform a network installation Discuss network install servers Discuss RHEL/Fedora Kickstart installations Discuss SLES AutoYaST installations
Copyright IBM Corporation 2009
Figure 1-1. Unit objectives
LX036.0
Notes:
1-2
V5.2
Student Notebook
Uempty
Installing Linux: Review

Documentation Hardware requirements System resources Installation resources Check for updated information
Figure 1-2. Installing Linux: Review
LX036.0
Notes: Introduction
Taking time to plan and prepare for the installation of any operating system is highly recommended. It provides you with the ability to have all the resources at hand for the installation, and avoid any delays that the lack of planning might impose.
Documentation
Novell provides both release notes and installation information on both the distribution media as well as their Web site. The Installation and Administration Manual is designed to guide you through the installation and administration of SUSE Linux Enterprise Server 10 on various platforms. The installation manual is in PDF format and available in several languages. To access this manual, place the first CD into an available PC and use an Acrobat reader to open the file located on the CD.
Copyright IBM Corp. 2001, 2009 Unit 1. Advanced Linux installation 1-3
Student Notebook
Red Hat provides both release notes and installation related manuals on CD1 of the distribution media. Red Hat also provides this information online. We strongly suggest you have these documents at hand and review them, before proceeding with an installation, even if you consider yourself a skilled Linux administrator. Each distribution may make significant changes that an impact your installation!
Hardware requirements
One thing that needs to be checked is to verify that the target systems hardware is supported. This includes both the system and I/O devices and adapters installed on the system. Occasionally, I/O devices and adapters will be released that are not included in the current distribution releases of the Linux operating system. We suggest you refer to the Web site for the distribution you will be installing to check for additional information on devices.
System resources
As you plan for an installation, you will need to gather system information. What type of disk will you will be installing to? Will you be using a network, and if so, what address will it use?
Installation resources
Once you have decided on the method of installation, make sure you have these resources on hand and that they have been tested. If installing via a network, make sure you have all relevant information (IP addresses, server configuration, network paths, and so forth). If you are installing from CD-ROM, verify the media is not corrupted (better to find this out in testing rather than when you are in the final stages of an installation). Do you have any customization scripts in place? Have you read the manuals? Always being prepared is the best key to success.
Check for updated information

Before starting the installation, always check with the distribution to verify no patches or fixes have been released since you received your media. SUSE Linux releases updates in the form of Service Packs (SP1, SP2, and so forth). Red Hat releases software in the form of updates (as in RHEL5 U1, which we are using in this course).
1-4
V5.2
Student Notebook
Uempty
Disk partitioning: Review

sda: The first sector of the disk contains the MBR and partition table
Master Boot Record (MBR) Partition table MS Windows

sda1: First primary partition holds a Microsoft Windows filesystem
Linux / Linux /home Linux swap
sda5: First logical partition holds a Linux filesystem that will be mounted as / sda6: Second logical partition holds a Linux filesystem that will be mounted as /home sda7: Third logical partition holds a Linux swap space
sda2: Second primary partition is an extended partition and holds three logical partitions
Figure 1-3. Disk partitioning: Review
LX036.0
Notes: Introduction
On an Intel-based computer (x86 compatible), a hard disk is split up using a partitioning scheme. The scheme dates back to the 8086 processor. Every hard disk in your computer consists of a large number of sectors of 512 bytes each. The first sector of the disk always contains two things1: - The Master Boot Record (MBR). This master boot record contains the bootstrap code of the system. - The Partition Table. This table contains the way the rest of the disk is divided into partitions. The rest of the disk can be split up into a maximum of four primary partitions2. Every partition can hold a separate filesystem, each with its own operating system on it. In
Actually, three: the first sector also contains a two-byte magic number to verify that this is a valid master boot record sector. The partition table itself is 64 bytes. To fully describe a partition, you need 16 bytes per partition, hence the limit of four partitions that can be described in the partition table.
2 1
1-5
Student Notebook
addition to that, one of the primary partitions can be used as an extended partition, which can contain an unlimited number of logical partitions3. (Linux limits the number of logical partitions to 59 on integrated development environment (IDE) disks and 11 on Small Computer System Interface (SCSI) disks4.) Every logical partition can hold a separate filesystem too. Most operating systems are not able to boot off a logical partition, just off a primary partition. Linux is an exception to this. The first IDE hard disk is called /dev/hda, the second /dev/hdb, and so on. The first primary partition on the first IDE drive is called /dev/hda1, the first logical partition is called /dev/hda5. Under the 2.4 kernel, most Linux distributions defined devices up to /dev/hda16, so if you wanted to create more than 12 logical partitions, you would need to create some extra /dev entries yourself using the mknod command. With the introduction of the 2.6 kernel, and devfs, Linux now creates device entries for only those devices found. SCSI disks are a little different in this respect. The first difference is that SCSI disks use /dev/sda instead of /dev/hda. The second difference is that SCSI disks can only hold eleven logical partitions. This has to do with the SCSI ID numbering, which reserves 16 IDs for all block devices on the disk, where /dev/sda is also considered a block device. Together with four primary partitions, this leaves a maximum number of eleven logical partitions. In newer distributions (that is, Fedora 8), all hard disks are referred to as dev/sda, including IDE disks.
3 If logical partitions are used, then these logical partitions are described in the extended partition itself, using a linked list. Linked lists have no inherent limitation in the number of entries they can contain. 4 This is because Linux only reserves 64 minor numbers for an IDE disk and 16 minor numbers for a SCSI disk. The disk itself uses one minor number, and each primary partition requires a minor number. That leaves 59 minor numbers for logical partitions on IDE disks, and 11 on SCSI disks.
1-6
V5.2
Student Notebook
Uempty
Network installations
Installations where packages to install are downloaded from the network Network protocols supported depends on distribution
Network File System (NFS) File Transfer Protocol (FTP) HyperText Transfer Protocol (HTTP) Server Message Block (SMB)
Requires a network install server Usually requires special network-enabled boot media
Preboot Execution Environment (PXE) boot requires no media
Figure 1-4. Network installations
LX036.0
Notes: Introduction
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 ten 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 Red Hat Package Manager software packages (RPMs) to be installed are downloaded from the network.
Network protocols
Various network protocols exist to retrieve the installation RPMs, and the protocols that are supported depend on your distribution. Support might be included for Network File
Student Notebook
System (NFS), File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), and Server Message Block (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. Finally, you will need some network-enabled boot media. This can be the first CD (or DVD) of your regular installation or a minimal install CD or DVD ISO image. If your system supports the Preboot Execution Environment (PXE), you can boot and install your distribution over the network without the need for physical boot media.
1-8
V5.2
Student Notebook
Uempty
Network install server: Overview

Should be a Linux/UNIX server Content of all relevant CDs copied to disk
Use a naming scheme that allows multiple versions/distributions to be exported
For example: /export/rhel51s, /export/fedo8, /export/suse10sp1, ... Method

NFS (Anonymous) FTP HTTP SMB
Figure 1-5. Network install server: Overview
LX036.0
Notes: Image server

A network install server is typically a Linux/UNIX server, although Windows 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. You can also configure a server to use FTP, HTTP, or SMB.
NFS
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.
Student Notebook
Anonymous FTP
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.
HTTP
If you decide to offer HTTP installs, you can simply create a symbolic link from your DocumentRoot directory to the directory where your CDs are copied into, as long as FollowSymLinks is set in your Web server configuration.
PXE boot
The PXE boot process allows the server to broadcast a boot menu to its network. Any BOOTP enabled machine can display the menu and talk to the server using Trivial File Transfer Protocol (TFTP) protocol. The client then enters the appropriate information to boot, install, or rescue from the network installation server.
1-10 Linux System Administration I
V5.2
Student Notebook
Uempty
Network install server: Configuration

Server fileset configuration
RHEL: Copy .discinfo, Server/ and images/ Fedora: Copy .discinfo, repodata/, Packages/ and images/ SUSE Linux: Copy CD 1 completely, and from all other CDs, copy SUSE/ and media*
Server configuration
Red Hat/Fedora
Manual
SUSE Linux
/sbin/yast2 instserver
Figure 1-6. Network install server: Configuration
LX036.0
Notes: Introduction
We mentioned on the previous visual that you should select a naming convention when setting up your installation server. You should always check the documentation and release notes for a distribution to verify if there is a specific naming convention you must follow as well, or your network installation may not function correctly.
Important files
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 Server/ and images/ directories. For a Fedora distribution, you need .discinfo, repodata/,
1-11
Student Notebook
Packages/, 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.
Server configuration
SUSE Linux Enterprise Server (SLES) provides a tool under Yet another Setup Tool (YaST) to configure your installation server. This menu-driven interface will configure a directory tree with the proper sub-directories and files so that a system running SLES can successfully be an installation server. In the case of Red Hat, you will need to configure the installation server manually.
V5.2
Student Notebook
Uempty
RHEL/Fedora kickstart installations

Fedora/RHEL method of automating installations File ks.cfg with three sections:
Install commands %packages section %pre, %post sections
File creation
Manually system-config-kickstart /root/anaconda-ks.cfg (created during installation)
Location
Boot floppy or NFS server
NFS also requires a Dynamic Host Configuration Protocol (DHCP) server Initiation:
linux ks=ks.cfg URL at syslinux boot: prompt
Figure 1-7. RHEL/Fedora kickstart installations
LX036.0
Notes: Introduction
Kickstart provides the ability to create a hands-off installation. This means that if the ks= option is passed to the installer, the install program will take input from the configuration file. The contents of the kickstart configuration file can contain all of the answers to questions posed by the Anaconda installer, plus post-install directives. If the configuration is missing information, the install process will prompt the installer for additional information.
File creation
The ks.cfg file is a flat text file. After a system has been installed, a kickstart file that configures the system to the way that it was installed is located in roots home directory in a file /root/anaconda-ks.cfg. To create a kickstart file from scratch, use the system-config-kickstart utility.
Student Notebook
Location
The kickstart file can be presented either on a diskette, or from a network source, such as an NFS server.
Initiation
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, and 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 component groups XML file provided by the distribution (comps-rhel5-server-core.xml in RHEL5, Fedora-8-comps.xml in Fedora), located in the repodata/ directory. 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 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. 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. Kickstart files can be created by hand, but Red Hat has also released a tool which might help you generate kickstart files: system-config-kickstart (formerly known as ksconfig). This tool is available on the distribution CDs in the system-config-kickstart RPM. As an added bonus, the RHEL/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.
V5.2
Student Notebook
Uempty
RHEL/Fedora kickstart example

# cat anaconda-ks.cfg # Kickstart file automatically generated by anaconda. install cdrom lang en_US.UTF-8 langsupport --default=en_US.UTF-8 en_US.UTF-8 keyboard us xconfig --card "Intel 815" --videoram 16384 --hsync 30-94 --vsync 48-120 --resolution 800x600 --depth 16 --startxonboot --defaultdesktop gnome network --device eth0 --bootproto static --ip 10.0.0.3 --netmask 255.255.255.0 --gateway 10.0.0.100 --hostname sys2 rootpw --iscrypted $1$Q1EsuwfB$aowfCXdJRUcpW/8h4JlOc. firewall --disabled selinux --enforcing authconfig --enableshadow --enablemd5 timezone America/Los_Angeles bootloader --location=mbr --append="rhgb quiet" # The following is the partition information you requested # Note that any partitions you deleted are not expressed # here so unless you clear all partitions first, this is # not guaranteed to work #clearpart --all --drives=had . . .
Figure 1-8. RHEL/Fedora kickstart example
LX036.0
Notes: Introduction
The visual shows a small portion of a kickstart configuration file The following is the complete example of the kickstart file that is shown in the visual above. Note the name is anaconda-ks.cfg. This file was created during the installation of RHEL51. Can you tell what software was selected for this installation? What timezone will system use?* [root@sys2 ~]# more anaconda-ks.cfg # Kickstart file automatically generated by anaconda. install cdrom lang en_US.UTF-8 langsupport --default=en_US.UTF-8 en_US.UTF-8 keyboard us
Student Notebook
xconfig --startxonboot --defaultdesktop gnome --startxonboot --defaultdesktop gnome network --device eth0 --bootproto static --ip 10.0.0.3 --netmask 255.255.255.0 --gateway 10.0.0.100 --hostname sys3 rootpw --iscrypted $1$Q1EsuwfB$aowfCXdJRUcpW/8h4JlOc. firewall --disabled selinux --enforcing authconfig --enableshadow --enablemd5 timezone America/Los_Angeles bootloader --location=mbr --append="rhgb quiet" # The following is the partition information you requested # Note that any partitions you deleted are not expressed # here so unless you clear all partitions first, this is # not guaranteed to work #clearpart --all --drives=hda #part /boot --fstype ext3 --size=100 --ondisk=hda #part pv.4 --size=0 --grow --ondisk=hda #volgroup VolGroup00 --pesize=32768 pv.4 #logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow #logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=512 --grow --maxsize=1024 %packages @ everything e2fsprogs grub kernel lvm2 kernel-devel
* The final part of the file shows that all software (everything) was selected for this installation. The timezone is set near the beginning of the file. This system is set to America/Los Angeles.
V5.2
Student Notebook
Uempty
SLES AutoYaST installations

SUSE Linux method of automating installs File ay.xml containing all installation information:
General settings for keyboard and so forth Partition settings Packages Pre- and post-install scripts
File creation:
yast autoyast
Location:
Store file on network server
Initiation:
install=nfs://10.0.0.1/export/sles10sp1 \ autoyast=nfs://10.0.0.1/autoyast/myprofile.xml
Figure 1-9. SLES AutoYaST installations
LX036.0
Notes: Introduction
SLES also supports autoinstallations. On the most recent distributions, this is done through AutoYaST. Earlier SLES distributions used other, more complicated and limiting ways of performing autoinstallations.
File creation
AutoYaST installations revolve around an XML-based file containing all the installation information. This file can technically be created by hand, but thats a huge task. It is far easier to use yast autoyast to create this file.
Location
This file is saved on a network server. You then need to boot the system from regular boot media.
Student Notebook
Initiation
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/sles10sp1 - 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/autoyast/myprofile.xml 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 RHEL and Fedora, it is possible to modify the syslinux.cfg file on the boot floppy to start the installation manually.
V5.2
Student Notebook
Uempty
AutoYaST example
<?xml version="1.0"?> <!DOCTYPE profile SYSTEM "/usr/share/autoinstall/dtd/profile.dtd"> <profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.c om/1.0/configns"> <bootloader> <activate config:type="boolean">false</activate> <global> <embed_stage1.5 config:type="boolean">true</embed_stage1.5> <gfxmenu>/boot/message</gfxmenu> <lines_cache_id>0</lines_cache_id> <prompt>1</prompt> <stage1_dev>/dev/hda7,/dev/hda</stage1_dev> <timeout config:type="integer">8</timeout> </global> <initrd_modules config:type="list"> <initrd_module> <module>piix</module> </initrd_module> <initrd_module> <module>processor</module> </initrd_module> <initrd_module> <module>thermal</module> . . .
Figure 1-10. AutoYaST example
LX036.0
Notes: Introduction
The visual shows a small portion of an AutoYaST XML-formatted configuration file. Note the tag format.
1-19
Student Notebook
Checkpoint
1. True / False: A network install server needs to be a Linux system. 2. Which of the following install methods does not require a network server?
a) b) c) d) NFS SMB FTP CD-ROM
3. What are some possible locations where a RHEL/Fedora kickstart or SLES AutoYaST file can be stored?
Figure 1-11. Checkpoint
LX036.0
Notes:
Write down your answers here:
1. 2. 3.
V5.2
Student Notebook
Uempty
Exercise 1: Advanced Linux installation
What you will do in this exercise: Install a Linux distribution onto your classroom system
Figure 1-12. Exercise 1: Advanced Linux installation
LX036.0
Notes:
1-21
Student Notebook
Unit summary
Having completed this unit, you should understand: Network install servers are convenient means of software distribution for doing both 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 network-enabled boot media, DVD/CD/USB key, and sometimes additional module disks as well. RHEL/Fedora kickstart and SLES AutoYaST install methods allow you to automate installations.
Figure 1-13. Unit summary
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Unit 2. Startup and shutdown

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

After completing this unit, you should be able to: Describe the Linux startup flow Configure autostarting services Boot Linux into single-user mode Perform a proper shutdown of a Linux system

Accountability: Checkpoint questions Exercise
References
Linux man pages SUSE Linux 10 Installation and Administration Guide Red Hat Enterprise Linux V5 Administration Guide Red Hat Enterprise Linux V5 Installation Guide http://www.gnu.org/software/grub GNU GRUB - GNU Project - Free Software Foundation (FSF) http://grub.enbug.org GRUB Wiki
2-1
Student Notebook
Unit objectives
After completing this unit, you should be able to: Describe the Linux startup flow Configure autostarting services Boot Linux in single-user mode Perform a proper shutdown of a Linux system
LX036.0
Notes:
2-2
V5.2
Student Notebook
Uempty
Linux startup flow

power on BIOS Hardware boot boot loader
Linux kernel and initrd Low level initialization of important hardware (disk, CPU, VGA adapter...) Usually GRUB
Full initialization of all hardware Runs boot scripts and starts system services
Software boot
init system ready

Figure 2-2. Linux startup flow
LX036.0
Notes: Introduction
This visual gives an overview of the Linux startup flow. In the subsequent visuals, details about each step will be covered.
2-3
Student Notebook
Basic Input/Output System

Checks memory and hardware (POST) Loads options from nonvolatile memory
Memory timings Order of boot devices
Checks for boot devices

Floppy disks CD-ROM Hard disks
Loads Master Boot Record from boot device and executes it
Figure 2-3. Basic Input/Output System
LX036.0
Notes: Introduction
Every Intel PC has a Basic Input/Output System (BIOS). This is a little program which is stored in an Electrical Erasable Programmable Read Only Memory (EEPROM), (sometimes also called non-volatile memory) on your motherboard. It is the first program that runs once the power is switched on. It performs a number of basic tasks: - Completes Power On Self Test (POST) to check memory and hardware. - Loads various options from non-volatile memory, for instance, memory timing parameters, interrupt request (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. - Checks for the availability of boot devices. - Loads the Master Boot Record from the first available boot device. The data from the first sector is read into memory and executed.
2-4
V5.2
Student Notebook
Uempty
Master Boot Record
Master Boot Record (MBR)
Size: 512 bytes (first sector of HD) Addressed by BIOS Content: - 446-byte program code (to boot an operating system) - 64-byte partition table with max. four entries - 2-byte "magic number" (0xAA55)
Figure 2-4. Master Boot Record
LX036.0
Notes: Master Boot Record

The Master Boot Record (MBR) is the first sector (512 bytes) of the boot device. It contains three things: - A 446-byte 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-byte magic number, which is used to check whether this is a valid MBR.
Bootloader
The role of the operating system boot loader is to locate, load, and execute the operating system kernel image. The most common boot loader is the Grand Unified Bootloader (GRUB). The Linux Loader (LILO) is rarely used these days.
2-5
Student Notebook
GRand Unified Bootloader

Program stored in MBR (first stage) and in /boot/grub (1.5th and second stage) Understands filesystem structure
No need to activate a configuration as with LILO
Configuration file is /boot/grub/menu.lst (linked to /boot/grub.conf) Installed in MBR with grub-install When system boots:
Selects predefined OS to boot or Uses command language to boot non-predefined OS Command language compatible with configuration file
GRand Unified Bootloader (GRUB) additional features:

MD5 encrypted passwords Hiding/Unhiding partitions
Figure 2-5. GRand Unified Bootloader
LX036.0
Notes: Introduction
GRand Unified Bootloader (GRUB), as Linux Loader (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, and so forth) is stored on disk, typically in /boot/grub. Several 1.5th stage files exist, each for a different filesystem. Note: 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.
2-6
V5.2
Student Notebook
Uempty
- 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. If a splashimage was included in the GRUB configuration, then the second stage displays the menu in a graphical mode with the splash image as background.
GRUB configuration file

The GRUB configuration file is typically stored in your /boot filesystem in a separate GRUB directory called menu.lst (linked to grub.conf). On a regularly booted Linux system, this file is thus referenced as /boot/grub/menu.lst. It contains all predefined operating systems and their options and peculiarities.
GRUB installation
To install GRUB, either use the shell script grub-install or start the grub program and use GRUB commands to install GRUB manually.
GRUB features
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 defining 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.1 - If configured properly, GRUB can be used to boot from the network. This requires the netboot package and setting up DHCP and TFTP servers. Network booting is outside the scope of this course.
1 The problem lies in Windows 9x itself: When a Windows system boots, it goes through the partition table and assigns a drive letter to every partition type it recognizes, starting with C:. Furthermore, Windows is only able to boot from the C:-drive. Thus, if you want multiple Windows 9x operating systems on your partition, you need to hide all partitions that are not in use. This is done by changing the partition type to something that Windows does not recognize. Note that Windows NT and its descendants allow you to select another drive assignment order, and thus allow you to have multiple operating systems on one disk.
2-7
Student Notebook
GRUB startup sequence

MBR
contains stage1
Stage 1
addresses stage1_5 (CHS)
Stage 1_5
filesystem driver, loads (hd0,3)/grub/stage2
Configuration: /boot/grub/menu.lst
Stage 2 loads for example, (hd0,3)/vmlinuz or Windows via "chainloading"
Figure 2-6. GRUB startup sequence
LX036.0
Notes: Introduction
The visual shows the GRUB startup sequence graphically. The system BIOS boots the system from the selected boot disk by reading and executing the contents of the Master Boot Record (MBR). For a system using GRUB, the MBR contains stage 1 of the GRUB boot loader. Stage 1 of the GRUB boot loader then loads the 1.5 stage to enable filesystem capabilities. This allows GRUB to reference file names such as /boot/grub/menu.lst, /boot/initrd, and so forth. Finally, stage 2 is loaded, providing a menu-driven interface to boot predefined operating systems or enter commands to boot a non-predefined operating system.
2-8
V5.2
Student Notebook
Uempty
/boot/grub/grub.conf or /boot/grub/menu.lst
#boot=/dev/hda default=0 timeout=5 title Red Hat Enterprise Linux ES (2.6.9-34.EL) root (hd0,0) kernel /vmlinuz-2.6.9-34.EL ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.9-34.EL.img
#boot=/dev/hda default=0 timeout=5 title Fedora Core (2.6.15-1.1955_FC5) root (hd0,0) kernel /vmlinuz-2.6.15-1.1955_FC5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.15-1.1955_FC5.img
default=0 timeout=8 title SUSE SLES 10 root (hd0,6) kernel /boot/vmlinuz root=/dev/hda7 selinux=0 resume=/dev/hda6 splash=silent showopts initrd /boot/initrd
Figure 2-7. /boot/grub/grub.conf or /boot/grub/menu.lst
LX036.0
Notes: GRUB configuration options

The GRUB configuration file, /boot/grub/menu.lst, is nothing more than a predefined series of commands that could just as well have been entered on the GRUB command line. Storing these commands in a file, though, makes booting far more convenient. The file starts with a few general configuration options: Table 1: /boot/grub/menu.lst general configuration options Option Description This specifies the default operating system to be started. default=0 Note: GRUB also allows you to specify the fallback parameter, which specifies the operating system to boot in case the default fails. Timeout before starting the default operating system, in seconds.
timeout=5
2-9
Student Notebook
When general options are all defined, specific operating systems need to be predefined. For this, the following options may be needed: Table 2: /boot/grub/menu.lst configuration options Option Description The title of the operating system, as it shows up in the GRUB title boot screen. The root partition of the filesystem. All files that are referenced later on are stored on this filesystem. Specifying root is not root required, but you will have to identify the root partition every time you mention a file instead, as is done with the SuSE stanza. The kernel image that is to be loaded, and all options that kernel need to be passed to the kernel. initrd An initial root disk that needs to be loaded. Unhide the partition specified (that is, change its type so that unhide Windows systems will recognize it). Hide the partition specified (that is, change its type so that hide Windows systems will not recognize it). The root of the operating system is the partition specified, but rootnoverify 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. To boot this operating system, invoke the chainloader, which chainloader +1 needs to load the first sector of the specified root partition. Note: Different distributions have made extensions to GRUB, which allow for instance graphics to be used.
V5.2
Student Notebook
Uempty
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
Inspecting /boot/System.map-2.6.16-rc1-git3-7-default Loaded 21547 symbols from /boot/System.map-2.6.16-rc1-git3-7-default. Symbols match kernel version 2.6.16. No module symbols loaded - kernel modules not enabled. klogd 1.4.1, log source = ksyslog started. <5>Linux version 2.6.16-rc1-git3-7-default (geeko@buildhost) (gcc version 4.1.0 20060123 (prerelease) (SUSE Linux)) #1 Mon Jan 30 21:52:12 UTC 2006 <6>BIOS-provided physical RAM map: <4> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) <4> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) <4> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) <4> BIOS-e820: 0000000000100000 - 0000000017ee06c0 (usable) <4> BIOS-e820: 0000000017ee06c0 - 0000000017ee66c0 (ACPI data) <4> BIOS-e820: 0000000017ee66c0 - 0000000017eee700 (ACPI NVS) <4> BIOS-e820: 0000000017eee700 - 0000000018000000 (reserved) <4> BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) <4> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) <4> BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) <5>0MB HIGHMEM available. <5>382MB LOWMEM available. <6>found SMP MP-table at 0009fe00 <7>On node 0 totalpages: 98016
Figure 2-8. Starting the kernel
LX036.0
Notes: Introduction
When the user selects a Linux operating system in the boot loader, then the boot loader will load the Linux kernel.
Compressed versus uncompressed kernel images

A kernel image is either non-compressed (vmlinux), or compressed (vmlinuz) and is normally located in the /boot directory. The naming convention for a kernel image that is compressed is that the kernel image file name will have the letter z. Uncompressed kernel images will have the letter x. Consider the following selected contents of the /boot/grub/menu.lst file # cat /boot/grub/menu.lst ... title Red Hat Enterprise Linux Server-base(2.6.18-92.el5)
Copyright IBM Corp. 2001, 2009 Unit 2. Startup and shutdown 2-11
Student Notebook
root (hd0,0) kernel /vmlinuz-2.6.18-92.el5 ro roo/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.18-92.el5.img ... This reference to a compressed kernel image /vmlinuz-2.6.18-92.el5. Due to potential space constraints, the Linux kernel can be compressed. If a compressed kernel image is used, an uncompress program is attached to it. Actually, it looks like a self-decompressing ZIP file in DOS.
Loading the kernel image

The boot loader loads a specified kernel image in memory and starts the kernel executing. At this point, the kernel initializes system hardware which has built-in support. 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. Next, the kernel locates the initrd (initial RAM disk), decompresses it, and loads all required kernel modules (device drivers) stored in the initial RAM disk. We will discuss the initrd in more detail on the next visual. 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. Note: While booting, the kernel generates a lot of messages that will scroll off the screen very fast. Since no filesystem is available on which to store these messages, they vanish. If you wish to retrieve these messages later however, you can run the dmesg command to see them.
V5.2
Student Notebook
Uempty
Initial RAM disk

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 which consists of a small gzip-compressed ext2 filesystem image The initrd contains a linuxrc script that loads the modules from the RAM disk and mounts the actual root filesystem
Linux kernel
initrd
linuxrc
no initrd Kernel modules
Mount actual root fs

Figure 2-9. Initial RAM Disk
LX036.0
Notes: Introduction
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.
2-13
Student Notebook
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: - 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.
V5.2
Student Notebook
Uempty
init
init is started by the kernel after the root filesystem is mounted init reads configuration file /etc/inittab Decides on default runlevel if no runlevel is given Runlevels have different meaning:
0: System halt S: Single-user mode (no scripts run) (SUSE) 1: Single-user mode (some scripts run) 2: Local multiuser without network 3: Full multiuser with network 4: Not used 5: Full multiuser with network and xdm (GUI) 6: System 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
Figure 2-10. init
LX036.0
Notes:
init process The init process started by the kernel reads its configuration file /etc/inittab to: Identify the first script to run during system startup Identify the default run level if no runlevel is given at the boot prompt Determine which scripts to be run at the various run levels Determine how to handle certain key sequences Determine how to handle a power failure
Runlevels
There are seven (eight for SUSE) 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 following run levels apply to Red Hat, Fedora, and SUSE: - 0 - System halt
Student Notebook
- S - Single-user mode (no scripts run) (SUSE) - 1 - Single-user mode (some scripts run) - 2 - Local multiuser without network - 3 - Full multiuser with network - 4 - Not used - 5 - Full multiuser with network and xdm (GUI) - 6 - System reboot The runlevels are defined in /etc/inittab. For example: # cat /etc/inittab . . . # System initialization. si::sysinit:/etc/rc.d/rc.sysinit l0:0:wait:/etc/rc.d/rc l1:1:wait:/etc/rc.d/rc l2:2:wait:/etc/rc.d/rc l3:3:wait:/etc/rc.d/rc l4:4:wait:/etc/rc.d/rc l5:5:wait:/etc/rc.d/rc l6:6:wait:/etc/rc.d/rc . . . 0 1 2 3 4 5 6
Each run level has a set of scripts associated with it in the directory structure /etc/init.d/rc<X>.d (SUSE) or /etc/rc<X>.d (Red Hat, Fedora), where X is the run level. In the example, runlevel 3 would cause the script /etc/rc.d/rc to execute scripts in the /etc/rc.d/rc.3 directory structure.
Default runlevel
The default runlevel is specified in the /etc/inittab file. The entry id: identifies the default runlevel. For example: # grep id /etc/inittab id:5:initdefault: The default runlevel for the system in the example will be runlevel 5.
Run-level determination
The current system run level can be determined by using either of the following commands: # who -r run-level 5 Jun 29 09:29
last=S
V5.2
Student Notebook
Uempty
# runlevel N 5
Switching runlevels
Switching runlevels can be accomplished by using either the init or telinit commands. For example, to change the runlevel of the system to runlevel 1: # N # # 5 runlevel 5 init 1 runlevel 1
In the example, by using the runlevel command, you can identify the current runlevel state before and after the init command was issued.
2-17
Student Notebook
/etc/inittab (RHEL/Fedora/SLES)
RHEL, Fedora
# Default runlevel id:3:initdefault: # System initialization. si::sysinit:/etc/rc.d/rc.sysinit l0:0:wait:/etc/rc.d/rc l1:1:wait:/etc/rc.d/rc l2:2:wait:/etc/rc.d/rc l3:3:wait:/etc/rc.d/rc l4:4:wait:/etc/rc.d/rc l5:5:wait:/etc/rc.d/rc l6:6:wait:/etc/rc.d/rc 0 1 2 3 4 5 6
SLES
# Default runlevel id:3:initdefault: # System initialization. si::bootwait:/etc/init.d/boot l0:0:wait:/etc/init.d/rc 0 l1:1:wait:/etc/init.d/rc 1 l2:2:wait:/etc/init.d/rc 2 l3:3:wait:/etc/init.d/rc 3 #l4:4:wait:/etc/init.d/rc 4 l5:5:wait:/etc/init.d/rc 5 l6:6:wait:/etc/init.d/rc 6 # Trap CTRL-ALT-DELETE ca::ctrlaltdel:/sbin/shutdown -r t4 now # Run gettys in standard runlevels 1:2345:respawn:/sbin/mingetty -noclear tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6
The default runlevel is 3 Always run /etc/rc.d/rc.sysinit (RHEL) or /etc/init.d/boot (SLES) Run /etc/rc.d/rc (RHEL) or /etc/init.d/rc (SLES) with the runlevel as parameter
# Trap CTRL-ALT-DELETE ca::ctrlaltdel:/sbin/shutdown -t3 -r now # Run gettys in standard runlevels 1:2345:respawn:/sbin/mingetty tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6 # Run xdm in runlevel 5 x:5:respawn:/etc/X11/prefdm nodaemon
Trap the three-finger salute CTRL-ALT-DELETE 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
Figure 2-11. /etc/inittab (RHEL/Fedora/SLES)
LX036.0
Notes: Introduction
The visual shows the most important lines of the /etc/inittab file. Because there are minor differences in RHEL/Fedora and SLES /etc/inittab files, they are shown side by side.
Default runlevel
As mentioned earlier, the entry id: identifies the default runlevel unless it was specified during the boot process. In the example shown in the visual, the default runlevel is 3.
V5.2
Student Notebook
Uempty
System initialization
The second entry directs init to always run the /etc/rc.d/rc.sysinit (RHEL/Fedora) or /etc/init.d/boot (SLES) script. This script does a number of important low-level tasks, such as: - Activating swap spaces - Setting the hostname - Checking the root filesystem for errors, and remounting it read-write - Turning on quota support - Loading important kernel modules - Checking all other filesystems and mounting them - Deleting various lockfiles which may have been left over from a crash - Enabling the clock
Defined runlevels
The next 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 a parameter. We will look at this script in the next visual.
Key sequence trap

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.
Terminal gettys
Finally, six gettys are started on tty1 through tty6. This means that there are 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.
prefdm
The last command, which is only run in runlevel 5, starts the prefdm command, which in turn starts xdm, gdm or kdm. These programs present a graphical login screen. This is unique to RHEL/Fedora: SUSE starts this through a regular init script (covered in the next few visuals). Note: 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.
Student Notebook
- 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.
V5.2
Student Notebook
Uempty
Starting services (System V init style)

init
/etc/rc.d/rc 3 (RHEL/Fedora) /etc/init.d/rc 3 (SLES) /etc/rc.d/rc3.d/K* stop /etc/inittab /etc/rc.d/rc3.d/S* start
(Symlinks to the actual start/stop script)

# ls -l /etc/rc.d/rc3.d lrwxrwxrwx 1 root root 24 ../init.d/NetworkManager lrwxrwxrwx 1 root root 14 lrwxrwxrwx 1 root root 19 ../init.d/saslauthd . . . lrwxrwxrwx 1 root root 15 lrwxrwxrwx 1 root root 15 . . . Mar 15 10:47 K02NetworkManager -> Mar 15 11:45 K05innd -> ../init.d/innd Mar 15 10:45 K05saslauthd ->
Mar 15 10:48 K15httpd -> ../init.d/httpd Mar 15 11:45 K16rarpd -> ../init.d/rarpd
Figure 2-12. Starting services (System V init style)
LX036.0
Notes: Introduction
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>.d2 - 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.3 - Then, it makes a list of all scripts that start with an S, sorts it, and executes them with the start parameter.
This directory is a symlink to /etc/init.d/rc<runlevel>.d in SLES Obviously, kill scripts are not relevant when booting straight into a runlevel. It is possible, however, to change runlevels in a live system by running the command init <new runlevel>. In that case, it might be necessary to stop services, for instance when switching from a multiuser to a single-user runlevel.
3 2
2-21
Student Notebook
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.4 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 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. For example, when entering run level 2 (Full multiuser without network) two scripts that are executed on a Red Hat installation are: - K15httpd - kills http related processes - S90crond - starts the cron process Note: The actual script is actually a symbolic link to a script located in the /etc/init.d/rc<X>.d directory. Relating to the example discussed above: - /etc/rc2.d/K15httpd is a symbolic link to /etc/init.d/httpd - If the calling script name starts with a letter K, the script will take actions to stop or terminate processes related to the process subsystem - If the calling script name starts with a letter S, the script will take actions to start processes related to the process subsystem - The number after the K or S determines the order in which the script will run 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 SLES. Other Linux distributions may use other init styles. However, 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.
Depends on the distribution used.
V5.2
Student Notebook
Uempty
Configuring services per runlevel

Use chkconfig to create the appropriate K- and S- links for each service
# chkconfig --list ... acpid 0:off 1:off atd 0:off 1:off ... # chkconfig acpid on # chkconfig --list ... acpid 0:off 1:off atd 0:off 1:off ...
2:off 2:on
3:off 3:on
4:off 4:off
5:off 5:on
6:off 6:off
2:on 2:on
3:on 3:on
4:off 4:off
5:on 5:on
6:off 6:off
Figure 2-13. Configuring services per runlevel
LX036.0
Notes: Introduction
The system runlevel determines what processes to be active at any given time. As the system enters a runlevel, init will start or stop processes defined by symbolic links to the associated runlevel rc directory structure. However, managing these scripts by hand is really tedious5. Thats why several tools exist for this: - chkconfig command - system-config-services (RHEL/Fedora) - yast (SLES)
In some UNIX variants, you are actually required to do this.
2-23
Student Notebook
chkconfig command
chkconfig provides a simple command-line tool for maintaining the /etc/rc[0-6].d directory hierarchy by relieving system administrators of the task of directly manipulating the numerous symbolic links in those directories. chkconfig has five distinct functions: adding new services for management, removing services from management, listing the current startup information for services, changing the startup information for services, and checking the startup state of a particular service. chkconfig --list [name] chkconfig --add name chkconfig --del name chkconfig [--level levels] name <on|off|reset> chkconfig [--level levels] name The visual above shows various operational examples of the chkconfig command in use. Note: The chkconfig command only maintains the links for services it does not start or stop them.
V5.2
Student Notebook
Uempty
Starting and stopping services manually

Scripts in init.d directory can be used to start/stop services manually
On RHEL/Fedora, the service command calls this script On SLES, rc service is a symlink to the init.d script
Default options: start, stop, status, restart Other options may also be available
RHEL/Fedora # service atd restart Stopping atd: Starting atd: [ OK ] [ OK ]
SLES # rcatd restart Shutting down service at daemon Starting service at daemon
done done
Figure 2-14. Starting and stopping services manually
LX036.0
Notes: Introduction
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 pathname6, 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 SLES system, a symbolic link with the name rc<service> is automatically created. This links to the init.d script.
6
The init.d directory is not in your $PATH, and for good reason: The scripts sometimes have the same name as the daemon itself.
2-25
Student Notebook
For example, to restart the atd daemon: # service atd restart (RHEL/Fedora) # rcatd restart (SLES)
V5.2
Student Notebook
Uempty
Booting Linux in single-user mode

Single-user mode
No networking (so no incoming hackers) No services being started No root password required (RHEL/Fedora)
Very useful for system maintenance To start from GRUB: Add single to the kernel line of the corresponding menu entry
GRUB
[Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB list the possible completion of a device/filename. ESC at any time cancels. ENTER at any time accepts your change.]
grub append: ro root=/dev/VolGroup00/LogVol00 single
Figure 2-15. Booting Linux in single-user mode
LX036.0
Notes: Introduction
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 RHEL/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.
2-27
Student Notebook
Entering single-user mode with GRUB

To enter single-user mode on a system configured to use the GRUB boot loader, interrupt the boot process by hitting the spacebar. Once interrupted, use the A key to append the option single. The example shown in the visual shows adding single after the kernel options: GRUB [Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB list the possible completion of a device/filename. ESC at any time cancels. ENTER at any time accepts your change.] grub append: ro root=/dev/VolGroup00/LogVol00 rhgb quiet single
Exiting single-user mode

Once you have completed the system maintenance activity in single-user mode, exit single-user mode by using one of the following commands: # init <runlevel> # shutdown -r now Note: The safest course of action is to do a full reboot of the system using the shutdown command. This will cause the system to go through the normal boot sequence and execute the required scripts.
V5.2
Student Notebook
Uempty
Shutting down a Linux system

Do NOT switch power off to shut down Use shutdown command or Ctrl-Alt-Delete Only works from a text console
Warns users Stops all running processes Unmounts filesystems Does an orderly shutdown Reboots if necessary
Example:
To reboot: shutdown -r now, reboot, or init 6 To halt: shutdown -h now, halt, init 0, or poweroff
Some display managers allow a user to perform a shutdown as well
Figure 2-16. Shutting down a Linux system
LX036.0
Notes: Introduction
If you need to shut down a Linux system, don't just pull the plug, but ensure that somehow the shutdown command runs. In fact, we've 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.
2-29
Student Notebook
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)?
LX036.0
Notes:
1.
2.
V5.2
Student Notebook
Uempty
Exercise 2: Startup and shutdown
What you will do in this exercise: Choose between a graphical and a text-based login screen by changing the runlevel of a system Boot a Linux system in single-user mode Use runlevel editors
Figure 2-18. Exercise 2: Startup and Shutdown
LX036.0
Notes:
2-31
Student Notebook
Unit summary
Having completed this unit, you should understand: The Linux startup flow is as follows:
When power is switched on, the BIOS is loaded BIOS loads MBR and executes it MBR contains a boot loader (LILO or GRUB), which loads the Linux kernel and starts it The 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 directly The first process started is init init 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
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Unit 3. System administration tools

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

After completing this unit, you should be able to: Discuss the main characteristics of system administration tools List some distribution-specific administration tools List some general-purpose administration tools Describe a print queuing system Configure a printer

References
Linux man pages SUSE Linux 10 Installation and Administration Guide Red Hat Enterprise Linux V5 Administration Guide http://www.webmin.com Webmin http://www.tldp.org The Linux Documentation Project
3-1
Student Notebook
Unit objectives
After completing this unit, you should be able to: Discuss the main characteristics of system administration tools List some distribution-specific administration tools List some general-purpose administration tools Describe a print queuing system Configure a printer
LX036.0
Notes:
3-2
V5.2
Student Notebook
Uempty
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-based X-based Web-based
To decide on a tool to use, consider:

Type of interface required Distribution-specific of generic? Only base system configuration or application configuration too? Can the tool be extended easily?
Does the perfect tool exist yet?
Figure 3-2. System administration tools
LX036.0
Notes: Introduction
System administration tools provide the system administrator with the means to easily perform tasks/operations on the system. Without the use of tools, system administration tasks would require a number of manual steps such as: - Editing configuration files - Starting/stopping services - Running commands Note: Without such tools, the chances of missing a crucial step are increased, and therefore the use of such tools are highly recommended. For example, adding a user to the system requires a number of steps: - Adding the user name (useradd command) - Adding the user to various groups (useradd or usermod command) - Setting the users password (passwd command)
Copyright IBM Corp. 2001, 2009 Unit 3. System administration tools 3-3
Student Notebook
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 Transmission Control Protocol (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.
System administration tool availability

The landscape of system administration tools is constantly changing. There is a number of reasons for this: - Writing a system administration tool is a good project for graduate students. - Currently, there is no authoritative configuration frameworks on the market which allow and encourage 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. Note: 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. Also, 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.
3-4 Linux System Administration I Copyright IBM Corp. 2001, 2009
V5.2
Student Notebook
Uempty
RHEL/Fedora setup
Menu-based front end for various tools that are part of the text-based installation
Figure 3-3. RHEL/Fedora setup
LX036.0
Notes: Introduction
The command setup is Red Hats/Fedoras text mode menu system that allows you to start the various text mode configuration programs. The following table shows the tools available with version 1.18.1 of the setup tool: Table 3: setup tool commands Menu Option Description Configures authentication services. This menu option calls the text menu command: /usr/share/authconfig/authconfig-tui.py Authentication configuration An alternative command is the command line interface command: /usr/sbin/authconfig
3-5
Student Notebook
Table 3: setup tool commands Menu Option Description Configures the network firewall (implemented with iptables). This menu option calls the text menu command: Firewall /usr/bin/system-config-securitylevel-tui configuration An alternative command is the command line interface command: /sbin/iptables Configures the system keyboard selection. This menu option calls the text menu command: /usr/bin/system-config-keyboard --text This menu selection configures the network. It calls the text menu command:
Keyboard configuration Network configuration
/usr/sbin/netconfig This menu selection configures the network and calls Printer configuration the text menu command: /usr/sbin/system-config-printer-tui Configures runlevel services. This menu selection calls the text menu command: System services /usr/sbin/ntsysv Configures the systems timezone setting. This menu Timezone selection calls the text menu command: configuration /usr/sbin/timeconfig Configure the systems X window display settings. This menu selection calls the text menu command: X configuration /usr/bin/system-config-display Note: All these tools can also be started directly from the command line.
3-6
V5.2
Student Notebook
Uempty
RHEL/Fedora system-config-*
system-config-network system-config-time system-config-soundcard
Figure 3-4. RHEL/Fedora system-config-*
LX036.0
Notes: Introduction
Both Red Hat and Fedora distributions provide a set of Graphical User Interface (GUI) tools to be used for various system administration tasks. Each tool is a separate program and starts with system-config. For example, the visual shows screen shots of the tools system-config-time, system-config-network, and system-config-sound. The following tools exist in RHEL and Fedora: Table 4: system-config tools Tool Used for Configuration of system authentication system-config-authentication resources system-config-boot Boot loader configuration Local time, timezone and time server system-config-date configuration
3-7
Student Notebook
Table 4: system-config tools Tool system-config-display system-config-httpd system-config-keyboard system-config-kickstart system-config-language system-config-lvm system-config-mouse system-config-netboot system-config-network system-config-nfs system-config-packages
Used for Graphical adapter, monitor, detection and configuration Web sever configuration Local keyboard configuration Kickstart configuration Local language configuration Logical Volume Management configuration Local mouse configuration Network boot/installation utility Network settings configuration NFS server configuration RPM Package management (RHEL only)
Note: Fedora uses yum for package management. system-config-printer Printer configuration system-config-rootpassword Change the root password system-config-samba SMB server configuration system-config-securitylevel iptables firewall configuration system-config-services System V services configuration system-config-soundcard Soundcard detection and configuration system-config-time Same as system-config-date system-config-users User and group management Note: Tools must be run in an X-based environment. In addition, there is no front-end (like setup) to integrate these tools. Instead, they are integrated in the K Desktop Environment (KDE) and GNOME Start button menus.
3-8
V5.2
Student Notebook
Uempty
SUSE YaST
Figure 3-5. SUSE YaST
LX036.0
Notes: Introduction
SUSE has provided Yet another Setup Tool (YaST) as a GUI interface/text menu tool to be used for various system administration tasks. It is comprised of a number of configuration modules that enable to system administrator to manage a particular aspect of the system. Configuration modules are grouped into areas of administration. For example, the visual shows an icon on the left hand navigation window named Software. By clicking on the Software icon, the right hand contents pane will be populated with control modules related to software administration activities, including Online update, Software management, System update, and so forth.
Starting YaST
YaST can be started either in a GUI interface or text menu mode.
Student Notebook
Webmin
http://www.webmin.com Open Source initiative to create an independent configuration framework Berkeley Software Distribution (BSD) Open Source License Modules to configure specific items
Modules 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 default
May need to install yourself
Figure 3-6. Webmin
LX036.0
Notes: Introduction
Webmin is a Web-based interface for system administration for UNIX/Linux. It is designed from the ground up 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 large number of administration modules, though. Webmin is licensed according to the BSD Open Source license, but modules might be licensed with other licenses, such as the GPL.
V5.2
Student Notebook
Uempty
Webmin rpm installation

Download webmin-version.rpm from http://www.webmin.com Install using the rpm command:
# rpm -ivh webmin-version.rpm package: ##################################################
Start Web browser and connect to port 10000

Log in with root password
Figure 3-7. Webmin rpm installation
LX036.0
Notes: Installation
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. Once downloaded, install the RPM file using: rpm -ivh webmin-version.rpm
Accessing Webmin
Accessing Webmin is done by launching a Web browser such as Netscape, Konqueror, Galeon, Mozilla, Firefox, Opera and even Internet Explorer. Connect to the server, port 10000. You need to login with a username and password, and you can then use any of the available modules to configure your system.
3-11
Student Notebook
Webmin screenshot
Figure 3-8. Webmin screenshot
LX036.0
Notes: Introduction
This is an example screenshot of Webmin.
V5.2
Student Notebook
Uempty
Users, printer queues, printers
Queue bulk
Queue color
Figure 3-9. Users, printer queues, printers
LX036.0
Notes: Introduction
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 quotas are implemented
Student Notebook
Common printing subsystems

BSD
Traditional BSD style printing subsystem (lpr/lpd) RFC 1179
AT&T
Traditional AT&T style printing subsystem Not often found on Linux; used in AIX
LPRng
Printing subsystem downward compatible with BSD Used in slightly older Linux distributions
Common UNIX printing system (CUPS)

Completely new, modular implementation Based on IPP (Internet draft) Used in the newest Linux distributions, including Fedora/RHEL and SUSE Expected to be the standard in the future on all UNIX
Figure 3-10. Common printing subsystems
LX036.0
Notes: Introduction
There have been a number of different printing subsystem that have been utilized in the UNIX/Linux world. The visual shows the common printing subsystems that have been used. Information relating to printing on Linux can be found at the following Web site: - http://www.linuxprinting.org
BSD
The Berkeley Software Distribution (BSD) 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.
V5.2
Student Notebook
Uempty
AT&T
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 line printer requester, next generation (LPRng) and common UNIX printing system (CUPS) will support the AT&T user interface commands to submit jobs.
LPRng
LPRng 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 RHEL/Fedora.
CUPS
CUPS is a completely new, modular implementation of a printing subsystem. It is one of the first printing subsystems that support the new Internet Printing Protocol (IPP) standard, which is in the process of being accepted by the Internet Engineering Task Force (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, line printer daemon (LPD). CUPS is currently being utilized as the default printing system in most Linux distributions.
3-15
Student Notebook
Common UNIX printing system (CUPS)

Completely rewritten implementation of UNIX printing system Supports various frontends:
Commands Network (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
Figure 3-11. Common UNIX printing system (CUPS)
LX036.0
Notes: Introduction
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 frontends
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 application programming interface (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.
V5.2
Student Notebook
Uempty
CUPS backends
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.
Printer classes
CUPS includes the notion of printer classes: pools of identical printers which handle jobs between them to achieve load balancing.
Color models
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.
More detailed information

For more detail information on CUPS, refer to the following Web site: - http://www.cups.org
3-17
Student Notebook
CUPS overview
Configuration Tools: lpadmin, browser, system-config-printer, yast, and kdeprint
Configuration files
classes.conf client.conf cupsd.conf printers.conf
cupsd (Scheduler)
CUPS-API
BSD commands (lpr, ...) System V commands (lp, ...)
Printer filter
Backends kdeprint
Figure 3-12. CUPS overview
LX036.0
Notes: Introduction
The visual shows a block overview of CUPS. It is comprised of the following components: - Frontends (commands, network submission using LPD and IPP, and C API) - Backends for local ports (parallel, serial, and USB) and network protocols (LPD, IPP, SMB, NCP, and JETDIRECT) - CUPS daemons (cupsd, cups-lpd) - Configuration files - Configuration tools
V5.2
Student Notebook
Uempty
CUPS daemons
CUPS is comprised potentially of the following daemons: Table 5: CUPS daemons Daemon Description Implements the CUPS scheduler based on the cupsd Internet Printing Protocol (IPP) V1.1 Waits for D-BUS calls when a console user configures a local printer that could not be autodetected. Using cups-config-daemon the information gathered from the user, it then configures the printer with the correct driver. Mini-server that supports legacy client systems that cups-lpd use the LPD protocol. The following chart shows each distribution and the daemons it provides: Table 6: CUPS daemons by distribution Daemon SUSE RHEL Fedora Y Y Y cupsd N Y Y cups-config-daemon Y Y N cups-lpd
Configuration files
The following configuration files are used by cupsd: - /etc/cups/cupsd.conf: Contains directives controlling how the cupsd scheduler works. Here is a sample entry from the file showing the default printer named lab-laser: # cat /etc/cups/cupsd.conf . . . <Location /printers/lab-laser> Order Deny,Allow Deny From All Allow From 127.0.0.1 AuthType None </Location> Browsing On BrowseProtocols cups BrowseOrder Deny,Allow BrowseAllow from @LOCAL Listen 127.0.0.1:631 . . . - /etc/cups/classes.conf: Configuration file generated automatically by cupsd when a printer is added or deleted from a class. We will discuss this more on the next visual.
Student Notebook
- /etc/cups/client.conf: Configuration file for client systems to printer to CUPS server. Requires the installation of cupsys-client package. - /etc/cups/printers.conf: Contains configuration parameters for printers configured on the system. Here is a sample entry from the file showing the default printer named lab-laser: # cat /etc/cups/printers.conf . . . <DefaultPrinter lab-laser> DeviceURI hp:/par/HP_LaserJet_6MP?device=/dev/parport0 Location Laser Printer located in the lab Info Laser Printer located in the lab State Idle Accepting Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 </Printer> . . .
Configuration tools
There are a number of tools that can be used to configure CUPS. Some of the tools available are: - lpadmin: Command line tool to configure printers and class queues - Web browser: Connection via a Web browser to the CUPS administration interface available on port 631 - system-config-printer: Text/GUI-based tool to configure printers on RHEL/Fedora - yast: Text/GUI-based tool that has a configuration module for configuring printers on SLES - kdeprint: GUI-based tool to configure printers
V5.2
Student Notebook
Uempty
CUPS configuration with lpadmin

lpadmin allows you to configure CUPS from a command line
# lpadmin -p lab-laser -E -v parallel:/dev/parport0 \ -D "Laser printer located in lab"
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
Figure 3-13. CUPS configuration with lpadmin
LX036.0
Notes: Introduction
The first of the five 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 Uniform Resource Identifier (URI). Some examples of URIs are: - file:/dev/lp0 - http://hostname:631/ipp/port1 - lpd://hostname/queue - smb://hostname/sharename
3-21
Student Notebook
CUPS configuration with a browser

Use URL http://localhost:631
Figure 3-14. CUPS configuration with a browser
LX036.0
Notes: Introduction
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: On a SLES system, the following command must be issued prior to using this interface: SLES # lppasswd -g sys -a root
Local host access only

By default, cupsd only allows connections from localhost (127.0.0.1). Note: It is possible to add an Allow from <IPADDR> directive in the /etc/cups/cups.conf file to allow specific IP addresses to utilize this CUPS administration interface.
V5.2
Student Notebook
Uempty
CUPS configuration with system-config-printer

system-config-printer: Standard printer configuration tool with RHEL/Fedora
Figure 3-15. CUPS configuration with system-config-printer
LX036.0
Notes: Introduction
The third way of configuring CUPS is through the use of the system-config-printer command found on RHEL/Fedora-based systems. This command is provided in both a text- and GUI-based menu tool. The visual shows the four key screens when using the tool to create a printer. The screen-shot in the upper left hand corner shows what the GUI-based tool looks like when no printers have been defined. Clicking the New button will cause the screen-shot in the lower left hand corner to appear. In this window, you would find a dialog-box to enter the name of the printer queue and another to enter a short description of the printer. By clicking the Forward button, the screen-shot in the upper right hand corner will appear. Here you will define the queue type and make a device selection.
3-23
Student Notebook
Finally, after clicking the Forward button again, you will be presented with the opportunity to print a test page to the printer queue. After that decision point, you will see the final screen-shot shown in the lower right hand corner, which shows the newly added printer queue and its status.
V5.2
Student Notebook
Uempty
CUPS configuration with yast

yast: Text/GUI based tool that has a configuration module for printers on SLES
Figure 3-16. CUPS configuration with yast
LX036.0
Notes: Introduction
The next way of configuring CUPS is through the use of the yast command found on SLES-based systems. This command is provided in both a text- and GUI-based menu tool. The visual shows the results of navigating through the printer configuration module and adding a printer queue called lab-laser.
3-25
Student Notebook
CUPS configuration with kprinter

kprinter: Standard printer dialog of all KDE applications Can also be used to add and manage printers
Figure 3-17. CUPS configuration with kprinter
LX036.0
Notes: Introduction
The final way of configuring CUPS is through its built-in API. An API allows an application programmer to build his or her 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.
V5.2
Student Notebook
Uempty
Checkpoint
1. The RHEL/Fedora _________ tool provides a menu-based interface for various tools used during a text-based installation. 2. True / False RHEL/Fedora provide separate tools that start with system-config to administrate the system with a GUI interface. 3. SUSE provides a tool called _____________ as a GUI interface/text menu tool to be used for various system administration tasks. 4. What is the default port number to connect with the Webmin administration tool using a Web browser?
LX036.0
Notes:
1. 2. 3. 4.
3-27
Student Notebook
Exercise 3: System administration tools
What you will do in this exercise: Utilize various system administration tools found on the distribution installed on your system.
Figure 3-19. Exercise 3: System administration tools
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Unit summary
Having completed this unit, you should understand: 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. Configuration of a print queue can be easy.
LX036.0
Notes:
3-29
Student Notebook
V5.2
Student Notebook
Uempty
Unit 4. Package management

This unit teaches you how to use the most common packaging tool on a Linux system, the Red Hat/RPM Package Manager (RPM).

After completing this unit, you should be able to: Describe the basic principles of RPM Describe the RPM build process Use the rpm command or available graphical interface tool to: - Install software packages on the system - Remove software packages on the system - Update software packages on the system - Query software packages on the system - Create simple SPEC files - Keep your system up to date

References
Linux distribution man and info pages SUSE Linux 10 Installation and Administration Guide Red Hat Enterprise Linux V5 Administration Guide http://www.redhat.com/docs/books/max-rpm/ max-rpm.pdf Maximum RPM http://fedora.redhat.com/docs/drafts/rpm-guide-en RPM Guide http://www.rpm.org The RPM Web site
Copyright IBM Corp. 2001, 2009 Unit 4. Package management 4-1
Student Notebook
Unit objectives
After completing this unit, you should be able to: Describe the basic principles of RPM Describe the RPM build process Use the rpm command or available graphical interface tool to:
Install software packages on the system Remove software packages on the system Update software packages on the system Query software packages on the system Create simple SPEC files Keep your system up to date
LX036.0
Notes:
4-2
V5.2
Student Notebook
Uempty
Software management
Historically difficult task when there are:
Numerous software vendors Different types of archive format Dependency issues Numerous tools (or lack thereof)
In the Linux community:

Simplified by the wide acceptance of the RPM Package Manager (RPM)
Figure 4-2. Software management
LX036.0
Notes: Introduction
Software maintenance on a system has historically been a difficult task due to: Numerous software vendors Different types of archive format Dependency issues Numerous tools or the lack there of
Over time software vendors (including those that provide operating systems) have used a number of open and proprietary archive distribution types (cpio, tar, bff, cab, and so forth) to distribute their products. The ability to check for software dependencies was either non-existent or limited in features. Finally, each archive would be installed using a variety of commands or techniques, and few, if any, were consistent with each other. The task of software maintenance on Linux based systems has been simplified by the widespread use of the RPM Package Manager (RPM) system.
Student Notebook
RPM Package Manager

Command line software management system Allows for the following software operations:
Installation Removal Updating Querying Validation
Components:
Software archives RPM-related commands Database files: /var/lib/rpm
Figure 4-3. RPM Package Manager
LX036.0
Notes: Introduction
The RPM Package Manager1 or RPM, is a robust command line software management system that solves a lot of problems that a system administrator or distributor of software typically faces, such as: - Management of source files - Management of the build process - A distribution method and format for binary files, including pre- and postinstall scripts.
1 This tool used to be called the Red Hat Package Manager, but Red Hat changed its name to emphasis that other distributions use it too. The new official name is RPM Package Manager, and yes, thats a self-referencing acronym (SRA), just like GNU.
4-4
V5.2
Student Notebook
Uempty
RPM features
The RPM Package Manager provides the following features: Installation Removal Updating Querying Validation
RPM components
RPM is comprised of three separate components: - Software archives or packages - RPM-related commands - Database files
4-5
Student Notebook
Software archives
Software archives known as RPMs RPMs contain:
Program files Configuration data Dependency information Data files Documentation
Naming convention
name version release . architecture . rpm Example: grub-0.95-3.5.i386.rpm
Figure 4-4. Software archives
LX036.0
Notes: Introduction
RPM Package Manager software archives or packages (a.k.a. RPMs) are compressed archives that contain the following: - Program files - Configuration data - Dependency information - Data files - Documentation Note: The Red Hat document Maximum RPM (http://www.redhat.com/docs/books/max-rpm/max-rpm.pdf) is a great resource on defining the different parts of a RPM archive.
4-6
V5.2
Student Notebook
Uempty
Naming convention
The naming convention for software packages is comprised of four fields: - Software Name: Software name - Version: Open source version number - Release: Developer internal patch/release number - Architecture: System architecture The filename for RPM packages end with the .rpm suffix.
Architecture types
Architecture types are: - ppc: PowerPC - ppc64: PowerPC 64-bit - s390: S390 - i386, i486, i586, i686: x86 compatible - ia64: IA-64 - alpha: Digital Alpha - noarch: Non architectural dependent
Example
For example, the file grub-0.95-3.5.i386.rpm breaks down to: - Software Name: grub - Version: 0.95 - Release: 3.5 - Architecture: i386
4-7
Student Notebook
RPM-related commands
rpm rpmbuild rpm2cpio rpmqpack (SLES) yast2 (SLES) system-config-packages (Red Hat/Fedora) system-install-packages (Red Hat/Fedora)
Figure 4-5. RPM-related commands
LX036.0
Notes: Introduction
The following RPM-related commands are available on Red Hat, Fedora, and SUSE: - rpm: Command with numerous options to perform software maintenance - rpmbuild: Command to build a RPM package - rpm2cpio: Command that converts rpm package files to cpio archive format In addition, the following RPM-related commands are available for SUSE: - rpmqpack: Command to check for installed packages - yast2: Tool with configuration modules to perform software maintenance from a GUI or menu interface Finally, the following RPM related commands are available for Red Hat/Fedora: - system-config-packages: GUI to perform software maintenance - system-install-packages: Tool to install a specific RPM with GUI output
4-8
V5.2
Student Notebook
Uempty
RPM database files

The RPM commands rely on database files stored in /var/lib/rpm Database files can be initialized if lost or corrupted (difficult to repopulate the database files)
Figure 4-6. RPM database files
LX036.0
Notes: Introduction
RPM Package Manager relies on database files that are stored in the /var/lib/rpm directory. As software package are installed, updated, and removed, these database files are updated. For Red Hat, Fedora, and SUSE, the database filenames are: Basenames Conflictname Dirnames Filemd5s Group Installtid Name Packages Providename Provideversion
Unit 4. Package management 4-9
Student Notebook
Pubkeys Requirename Requireversion Sha1header Sigmd5 Triggername
In addition, Red Hat/Fedora includes additional databases such as: - __db.001 - __db.002 - __db.003 Note: The database files themselves are in RPM format. They cannot be read directly. You have access to the contents through the use of the rpm command.
Corrupted or missing database files

If the database files are corrupted or lost, the software maintenance actions will fail. Note: While it is possible to initialize the database files using the --initdb option, it is difficult to repopulate the database files with what is currently installed. It is recommended to backup the entire contents of the /var/lib/rpm directory. SUSE Linux creates a nightly backup of the RPM Packages database file and places it in the directory /var/adm/backup/rpmdb. The backup file is stored in gzip format. For example: # ls /var/adm/backup/rpmdb . . . Packages-20060404.gz . . .
V5.2
Student Notebook
Uempty
RPM installing, freshening, and upgrading

Installs, freshens or upgrades an RPM
Freshen: Only install if an older RPM was installed Upgrade: Always install, but uninstall older RPM first
Basic syntax:
rpm -i package-filename.rpm rpm -U package-filename.rpm rpm -F package-filename.rpm (install) (upgrade) (freshen)
Useful options:
-v be verbose -h print 50 hash marks during installation
# rpm -ihv package-10.2-67.i386.rpm package: ##################################################
Figure 4-7. RPM installing, freshening, and upgrading
LX036.0
Notes: Introduction
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 always installs an RPM, even when a previous version was not installed. (It acts 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 are actually installed.
RPM syntax
The basic syntax for installing, freshening, and upgrading is respectively: # rpm -i package-filename.rpm
Student Notebook
# rpm -U package-filename.rpm # rpm -F package-filename.rpm
Note that there is a difference between the package name and the package filename. The RPM file which contains the package foo is generally 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 can 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.
V5.2
Student Notebook
Uempty
RPM uninstalling
For uninstalling an RPM use the -e option
# rpm -e kdelibs3 error: removing these packages would break dependencies: kdelibs3 >= 3.1 is needed by kdebase3-3.1.1-63 libDCOP.so.4 is needed by kdelibs3-cups-3.1.1-13 ...
Options: --nodeps
(ignore any dependency breaks)
Figure 4-8. RPM uninstalling
LX036.0
Notes: Introduction
Uninstalling (removal of) a software package from the system can be accomplished by using the -e option of the rpm command and the package name (not the package filename). Before removing the package, the rpm command checks the RPM database files for packages that may be dependent on the package to be removed. If a dependency is found, the rpm command will error out with a message similar to the example shown in the visual.
Ignore dependencies
The --nodeps option of the rpm command will cause the removal of a software package with no dependency checking.
4-13
Student Notebook
RPM querying
Queries the contents of an installed RPM Basic syntax:
rpm -q package-name
Options:
-a -f <file> -p <package-file> -i -l -s -d -c Query all installed packages Query package which owns file Query package-file Display package information Display package files Display state of all files Display documentation files Display configuration files
Figure 4-9. RPM querying
LX036.0
Notes: Introduction
RPM querying is the process of retrieving information about installed packages. The basic syntax is rpm -q package-name, but that only displays the package name. It's the options that make querying interesting: Table 7: rpm -q commonly used options Option Function Queries all packages which are installed on the -a system. -f <file> Queries which package contains <file>. -p <package-file> Queries the (not yet installed) <package-file>. Displays all package information: name, version, release, install date, group, size, -i summary, description, build information and so forth.
V5.2
Student Notebook
Uempty
Table 7: rpm -q commonly used options Option Function -l Lists all files in the package. Displays the state of each file in the package. -s The state is either normal, not installed, or replaced. Displays all files that are listed as -d documentation. Displays all files that are listed as configuration -c files.
Query examples
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
4-15
Student Notebook
RPM verification
Verifies the actual files with the original RPM
Size MD5 checksum Permissions, type Owner Group Modification time Symbolic link Device S 5 M U G T L D
# rpm -V kdelibs3 .M...... /opt/kde3/kpac_dhcp_helper .......T /opt/kde3/share/mimelnk/application/x-applix.desktop
a dot (.) means test passed

Figure 4-10. RPM verification
LX036.0
Notes: Introduction
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: Table 8: Verification Checks Check Description File size. This checks whether the size of the file has S changed. MD5 checksum. This is a very hard-to-fool checksum which 5 checks whether the contents of a file have changed. Mode. Are permissions, switch user ID (SUID) and switch M group ID (SGID) bits, and the filetype still the same? U User. Is the owner of the file still the same?
V5.2
Student Notebook
Uempty
Table 8: Verification Checks Check Description G Group. Is the group of the file still the same? File modification time. This checks whether the file T modification timestamp (mtime) has changed. Symbolic link. This verifies whether a certain symlink has L changed. Device. This verifies whether the major and minor numbers D of a device are still intact. If a file checks out okay, there can be no output. If there is a discrepancy, however, the name of the involved file can be listed, prepended by the discrepancy information. The output line then looks 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 might not only change a file on disk but can also modify the corresponding entry in /var/lib/rpm.
4-17
Student Notebook
RPM signatures
RPMs can be signed by the distributor To verify signature:
Obtain public key of distributor
CD-ROM Internet
Add public key to keyring using gpg --import (RPM v3) or rpm --import (RPM v4) Verify package with rpm checksig
rhel/fedora# rpm --import /mnt/cdrom/RPM-GPG-KEY sles# gpg --import /mnt/cdrom/pubring.gpg # rpm --checksig passwd-0.64.1-1.i386.rpm passwd-0.64.1-1.i386 md5 gpg OK
Note: You can list the installed keys with gpg --list-keys (RPM v3) or rpm -qa gpg-pubkey* (RPM v4)
Figure 4-11. RPM signatures
LX036.0
Notes: Introduction
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: Some distributions (for instance, SUSE), perform this step automatically while installing.
V5.2
Student Notebook
Uempty
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.
4-19
Student Notebook
RPM philosophy
developer application.tar.gz distributor application.tar.gz patches SPEC file
sample config files

application.src.rpm
application.sparc.rpm
rpmbuild bb on sparc
application.i386.rpm
rpmbuild -bb on i386
application.s390.rpm
rpmbuild bb on s390
Note: RPM v4 uses rpmbuild instead of rpm for building RPMs
Figure 4-12. RPM philosophy
LX036.0
Notes: Introduction
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 can also typically find patches and sample configuration files from the distributor, and, most importantly, a specification (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.
V5.2
Student Notebook
Uempty
RPM v4 rpmbuild command

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. With a correctly configured SPEC file, the only thing required to compile a package is the rpmbuild -bb (build binary) command on the target architecture. The binary RPM can then be distributed to all users of the distribution on that architecture. When a developer develops a new version of its software, the only thing the distributor theoretically needs to do is rerun the rpmbuild -bb command, and a new version can be distributed.
4-21
Student Notebook
Creating RPMs
RPM creation process is governed by a SPEC file, which contains all information required to create source and binary RPMs on all architectures
Preamble Prep Setup Build Install Install script Verify script Clean script File list Changelog Information about the package Preparation commands for the build process Commands to configure the software Commands to build the software Commands to install the software Scripts to be executed before or after the package is installed/uninstalled Additional script to verify installation Additional script to clean up after build List of all files that make up the binary RPM List of changes to the SPEC file
Used to create both the source and binary RPM

SPEC file normally part of the source RPM
Figure 4-13. Creating RPMs
LX036.0
Notes: Introduction
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).
V5.2
Student Notebook
Uempty
- 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. - 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.
4-23
Student Notebook
Example scenario: Hello, world!

# tar -ztvf hello-1.2.tar.gz hello-1.2/hello.c hello-1.2/Makefile hello-1.2/README
hello-1.2/hello.c:
#include <stdio.h> main() { printf("Hello, World!\n"); }
hello-1.2/README:
(c) IBM Copyright 2004 This 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 make To install, simply type make install
hello-1.2/Makefile:
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
Figure 4-14. Example Scenario: Hello, world!
LX036.0
Notes: Introduction
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, youve searched around the Internet and found such a program. The source file is called hello-1.2.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: 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
V5.2
Student Notebook
Uempty
hello.spec preamble section

# # SPEC file for hello world program # Summary: Hello, World program Name: hello Version: 1.2 Release: 1 License: GPL Group: Applications/Useless Source: hello-1.2.tar.gz Distribution: Useless Linux 1.2 Vendor: IBM Learning Services Packager: Ray P. Morgan <rpm@qlx.ibm.com> BuildRoot: /var/tmp/hello-1.2 %description This program prints the text "Hello, World!" on your screen. This is an excellent way to start your day - some people even consider it better than getting a random fortune cookie every morning!
Figure 4-15. hello.spec preamble section
LX036.0
Notes: Introduction
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.
4-25
Student Notebook
hello.spec prep, build, install, and files section

%prep %setup %build make %install make install DESTDIR=${RPM_BUILD_ROOT} %files %doc README /usr/bin/hello %changelog * Mon Sep 05 2005 - version 1.2 - John Doe <jdoe@ites.ibm.com> - Made compatible with FedoC4/RHEL/SLES9 * Tue Mar 09 2004 - version 1.1 - John Doe <jdoe@ites.ibm.com> - Made to work under RPM v4 * Tue Jul 20 1999 - version 1.0 - John Doe <jdoe@ites.ibm.com> - Initial release
Figure 4-16. hello.spec prep, build, install, and files section
LX036.0
Notes: Introduction
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 can typically execute commands to unpack the source package. If the source package is a simple .tar.gz file, you dont 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 comes with a Makefile, which performs all necessary commands for you. - In the install phase, the commands required to install the program in its proper place are executed. Note that were installing our package relative to ${BUILDROOT}. This prevents conflicts with existing packages on our system.
V5.2
Student Notebook
Uempty
The files section contains the files that need to be stored in the binary RPM. Some of these files may be preceded by a special identifier, such as %doc. This means that the file is a documentation file which needs to be relocated to the documentation directory, usually /usr/share/doc/<packagename>. The changelog section is not required but can be very useful. It contains a list of changes made to the SPEC file.
4-27
Student Notebook
RPM build process

RPM needs a special directory structure for building packages: /usr/src/redhat (RHEL, Fedora) or /usr/src/packages (SLES) 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.2-1.i386.rpm Wrote /usr/src/redhat/SRPMS/hello.1.2-1.src.rpm
Figure 4-17. RPM build process
LX036.0
Notes: Introduction
In order to finally run the build process, you need to put all source files (hello-1.0.tar.gz) in /usr/src/redhat/SOURCES (on a Red Hat or Fedora system) or /usr/src/packages/SOURCES (on a SLES system) and the SPEC file in /usr/src/{redhat|packages}/SPECS. You can then run the rpmbuild -b command, which can execute the build process. The letter after the b determines when the build process stops: Table 9: rpmbuild -b common options Command Description rpmbuild -bp Will only execute the %prep stage rpmbuild -bc Will execute %prep and %build rpmbuild -bi Will execute %prep, %build, and %install Will execute %prep, %build, and %install and create a rpmbuild -bb binary RPM
V5.2
Student Notebook
Uempty
Table 9: rpmbuild -b common options Command Description rpmbuild -bs Will create a source RPM rpmbuild -ba Will create a binary and source RPM Will do a list check. The %files section is macro rpmbuild -bl expanded, and checks are made to verify the files exist Note: RPM version 3 and earlier used rpm instead of rpmbuild as the command to build RPMs. The options are the same.
4-29
Student Notebook
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.2.i386.rpm Name : hello Relocations: (not relocateable) .... # rpm -qlp hello-1.2.i386.rpm /usr/bin/hello # rpm -ivh hello-1.2.i386.rpm hello ################################################## # hello Hello, World! # rpm -e hello
Figure 4-18. After RPM build process
LX036.0
Notes: Introduction
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.
V5.2
Student Notebook
Uempty
Integrated package management
system-config-packages
yast (install and remove software)
system-install-packages
Figure 4-19. Integrated package management
LX036.0
Notes: Introduction
Each distribution comes with its own tools for integrated package management. Shown in the visual are system-config-packages (RHEL/Fedora) and yast (SUSE). Other tools also exist, notably gnorpm (from the GNOME project) and kpackage (from the KDE project). system-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 system-config-packages, this is done with the -t option. For yast, this is integrated in one of its menus.
system-config-packages
This is the same screen that appears during the base installation. You can navigate and select individual or groups of RPMs to install.
Student Notebook
It is possible to use system-config-packages from a local directory or over the network using a directory tree (requires the file .discinfo). In addition, it is possible to load from an ISO image stored on the local system (mount -o loop isoimage.iso /mount_point). For example, to use system-config-packages to load from a directory tree mounted on the /nfsserver mountpoint: # mkdir /mnt/nfserver # mount 9.47.87.220:/export/linux/rhel4 /nfsserver # system-config-packages --tree=/nfsserver To load from an ISO image: # mkdir /isoimage # mount -o loop isoimagefilename.iso /isoimage # system-config-packages --isodir=/isoimage
system-install-packages
If you know the exact name of an RPM, you can install via this method (though you must enter the exact name, as shown in the visual above).
yast/yast2
In the upper left hand corner is the Filter method pull-down selection button. It allows you to filter the software by selections, package groups, or by a search function. Once the filter is set, the packages are displayed with a check mark if they are currently installed. If no check mark is displayed, clicking the check box next to the package name will schedule it for installation. Selecting the name of the package name will provide you with a description, technical data, dependencies, and version information. Note: If the package is displayed in red, this indicates that the package available on the installation source is at a lower version than the currently installed package. To select an action for a package, right click the check box next to the package name. Actions for installed packages are: Keep, Delete, Update, Auto-update, Auto-delete. Actions for packages that are not installed are: Install, Dont install, Taboo - never install, Auto-install. The selection of installation source media impacts how and where the system will look for software packages to install. Note: Selecting the Auto Check button enables yast2 to resolve package dependency issues.
V5.2
Student Notebook
Uempty
Keeping up-to-date (Fedora)

Use yum to keep up-to-date or install additional software from http://fedora.redhat.com or mirrors
Mirrors can be added to /etc/yum.conf
yum performs dependency checking automatically Syntax:

yum yum yum yum install package1 [package2] ... update [package1] [package2] ... check-update remove package1 [package2]
Figure 4-20. Keeping up-to-date (Fedora)
LX036.0
Notes: Introduction
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 installing them using rpm -F. When managing multiple systems, this quickly become tedious, so distributors have created additional programs to do this quickly. Fedoras method of keeping your system up-to-date is Yellowdog Updater, Modified (yum) . Its 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.
4-33
Student Notebook
Depending on the command you supply to yum, it installs additional software, upgrades existing packages, removes packages, or just gives you a list of packages for which upgrades are available. For other available commands, see the manual page of yum.
V5.2
Student Notebook
Uempty
Keeping up-to-date (Red Hat)

Red Hat Network (RHN)
Free and commercial subscriptions available Create and manage account and systems on http://rhn.redhat.com Register individual systems with rhn_register Use up2date (RHEL4) or pup (RHEL5) to keep systems current, or use Web interface at http://rhn.redhat.com (requires rhnsd daemon running on system)
Figure 4-21. Keeping up-to-date (Red Hat)
LX036.0
Notes: Introduction
Red Hats 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 rhn_register. From that point on, you can update your systems in two ways: - By running the up2date (RHEL4) or pup (RHEL5) utility on the system itself. This checks 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 Red Hat Network Service Daemon (rhnsd) on each system.
4-35
Student Notebook
Keeping up-to-date (SUSE Linux)

YaST Online Update (you): Program that downloads/installs patches from any SUSE mirror
Figure 4-22. Keeping up-to-date (SUSE Linux)
LX036.0
Notes: Introduction
SLES uses a less advanced technique than Red Hat for keeping up to date. On a SLES system, you will find the YaST Online Update (you) program. This program can connect to any SLES 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.
V5.2
Student Notebook
Uempty
Checkpoint
1. Which basic modes of operation does rpm have? _________________________________________ 2. Which command can I use to verify that the permissions of /etc/sendmail.cf are still correct? _________________________________________ 3. From the list provided, check all software maintenance operations that the rpm command provides:
___ Installation of a RPM package ___ Installation of a tar ball archive ___ Removal of seldom used packages ___ Updating a package ___ Verification of package installation
LX036.0
Notes:
1. 2. 3.
4-37
Student Notebook
Exercise 4: Packaging tools
What you will do in this exercise: Install, upgrade, and deinstall packages Query packages Verify the authenticity of packages Create simple packages
Figure 4-24. Exercise 4: Packaging tools
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Unit summary
Having completed this unit, you should understand: 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.
LX036.0
Notes:
4-39
Student Notebook
V5.2
Student Notebook
Uempty
Unit 5. X Window system

The unit teaches you how to use and configure the X Window system.

After completing this unit, you should be able to: Describe the basic architecture of the X Window system Configure Xorg Start and stop X Describe the function of the window manager Use X over a network

References
Linux man pages The X.org Foundation, http://x.org/ SUSE Linux 10 Administration Guide Red Hat Enterprise Linux V5 Administration Guide
5-1
Student Notebook
Unit objectives
After completing this unit, you should be able to: Describe the basic architecture of the X Window system Configure X.org Start and stop X Describe the function of the window manager Use X over a network
LX036.0
Notes:
5-2
V5.2
Student Notebook
Uempty
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
Figure 5-2. X window system
LX036.0
Notes: Introduction
The X Window System, X for short, is the GUI of Linux. It is implemented as a separate program that runs in user space, and it uses a client/server architecture. The X Window system, more commonly referred to as simply X (but never as Windows), is the set of device drivers and libraries that puts a graphical interface on most UNIX/UNIX-like systems. It was developed during the 1980s primarily for high-end, research-oriented hardware running in networked environments - but times have changed. X Window system servers run on computers with bitmap displays. The server distributes user input to and accepts output requests from various client programs through a variety of different interprocess communication channels. Although the most common case is for the client programs to be running on the same machine as the server, clients can be run transparently from other machines (including machines with different architectures and operating systems) as well.
Copyright IBM Corp. 2001, 2009 Unit 5. X Window system 5-3
Student Notebook
What X.org does is provide a client/server interface between the display hardware (those physical things like the mouse, keyboard, and video displays) and the desktop environment (this is typically called a window manager as it deals with how X is displayed that is, the overall appearance). All of this, makes X.org platform-independent, network-transparent, and extensible. In short, X.org is an open source X11-based desktop infrastructure. IN THE BEGINNING... In its original incarnation, UNIX, child of the console generation, lacked anything remotely resembling a graphical user interface. When personal computers arrived on the scene, they too followed the text-oriented approach with products like the Apple II. In the 1980s, the introduction of the Apple Macintosh made everyone aware of the need for graphical interfaces on desktop computers. Around the same time, Microsoft began marketing its GUI-based OS, Windows. Both Microsoft Windows and the Macintosh failed to separate the duties of the OS and the windowing environment - the two were molded together. In 1984, not long after the introduction of the Macintosh, the X Window System was born, and UNIX got its GUI. X took a fundamentally different approach to GUI design and implementation. From the beginning, X was designed to be used in a networked environment, and as such, was designed with a client/server model in mind. As a result, an X server makes no assumptions about its client's rendering hardware. This created obvious advantages (making remote computing feasible, for instance), some difficulties (putting security issues on the front burner), and some not-so-obvious drawbacks that would become more important as hardware capable of rendering 3D graphics became widespread. And of course, the networked computers that X was originally designed to run on in 1984 were high-end (and extremely expensive) scientific workstations - definitely not the kind of machines the average user was likely to have lying around the house. Sometime in 1989 or 1990, a German student named Thomas Roell began porting the source code for the X server provided in the X Version 11 Release 4 (X11R4) distribution to work with a graphics card he had installed in a 33 MHz Intel 386-based PC (with no floating point unit, mind you - this is old and slow hardware). He eventually released his X server, which he called X386.1.1. It caught the eye of some X developers at MIT, the X Consortium, and the Dell UNIX team in Austin, Texas. Dell brought Roell over to work on drivers for some graphics cards on a multiprocessor system that was to run a licensed version of UNIX System V Release 4 (SVR4) for Intel systems. While he was at Dell, Roell worked with Stephen Gildea of the X Consortium and Mark Snitily of Snitily Graphics Consulting Service (SGCS). Together, they worked to take Roell's next X server and make it the reference implementation for PC-based X Window systems. When X11R5 was released on August 29, 1991, Roell and the X Consortium gave PC-based UNIX its first official X implementation. And just in time too, as Linux had been born a few weeks earlier.
5-4
V5.2
Student Notebook
Uempty
X client/server architecture
The X Station
X server
Window manager Host-1 Host-z
Client-App 1
Client-App n
Client-App z
Figure 5-3. X client/server architecture
LX036.0
Notes: Introduction
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
Copyright IBM Corp. 2001, 2009 Unit 5. X Window system 5-5
Student Notebook
- 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 - 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.
5-6
V5.2
Student Notebook
Uempty
Examples of X stations
Hardware X stations
X server program stored in ROM chip
UNIX/Linux
X server implemented as a separate program that uses the entire graphical screen to display X clients UNIX/Linux can run the X clients and X server program on the same system (stand-alone solution)
MS-Windows
X server implemented as a separate program that uses the Windows GUI to display X clients
For example, Hummingbird eXceed, and others Xnest

X server implemented as an X client
Figure 5-4. Examples of X stations
LX036.0
Notes: Introduction
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 stand-alone solution.
1
A special file (type s) in a UNIX/Linux filesystem which makes TCP/IP-like communications between two processes possible. Because these sockets are limited to the local filesystem, they are generally more secure than TCP/IP connections. Furthermore, their overhead is slightly less, thus increasing performance.
5-7
Student Notebook
- 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.
5-8
V5.2
Student Notebook
Uempty
X servers in Linux
Open Source
X.org (xorg.freedesktop.org) Included in virtually all Linux distributions
Commercial
Xi graphics: http://www.xig.com
Figure 5-5. X servers in Linux
LX036.0
Notes: Introduction
The X server that is most often used with Linux is X.org, 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.x.org. Commercial X servers are also available for Linux. One example is Accelerated-X from Xi Graphics Inc. The advantage of these X servers is that they may have better support for certain specialty graphics adapters.
5-9
Student Notebook
X.org configuration
Can only be done as root You have to configure X.org for your
Graphical adapter and monitor Mouse Keyboard
Stored in /etc/X11/xorg.conf Configuration aids to create this file

Xorg -configure system-config-display SaX2, YaST Integrated in X.org Fedora/RHEL tool SUSE tools
Figure 5-6. X.org configuration
LX036.0
Notes: Introduction
On every system which runs the X.org X server, a configuration file has to be created. This file contains the hardware characteristics of the system running the server: graphical adapter type, monitor type, 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 the config file may damage your monitor! Don't say you weren't warned! 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 does 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 youve got an LCD panel, use one of these descriptions.
V5.2
Student Notebook
Uempty
Previously, 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.
5-11
Student Notebook
Starting X
To start X.org and your favorite window manager, use startx
Starts X.org on a free virtual display (usually number 7) Starts your favorite window manager To start a second X session, use startx -- :1
$ startx ...
Figure 5-7. Starting X
LX036.0
Notes: Introduction
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, Xorg 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 its 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.
V5.2
Student Notebook
Uempty
Since Linux has a large number of virtual terminals, there is nothing keeping you from starting a second X session on another virtual terminal. This is accomplished by starting an X server on display :1. When you start X via startx, you need to make sure that startx understands that this is an option not for itself, but for X, so the full startup line becomes startx -- :1. Once you have started multiple X sessions, you can toggle between them with Ctrl-Alt-F7 and Ctrl-Alt-F8.
5-13
Student Notebook
Stopping X
Use menu screens from your window manager
Stops processes then stops X server Usually saves current desktop layout
If nothing works, use Ctrl-Alt-Backspace

Stops X Server directly, and other processes lose connection and die Can be disabled in X server configuration file
Figure 5-8. Stopping X
LX036.0
Notes: Introduction
X can be stopped in two ways: - The proper way, by using the appropriate button from your window manager. This gracefully stops all applications, and exits X. - The quick and dirty way, by pressing Ctrl-Alt-Backspace. This first stops the X server, and then all applications ungracefully die because their connection is lost. Ctrl-Alt-Backspace can be disabled in /etc/X11/xorg.conf.
V5.2
Student Notebook
Uempty
Session managers
Manage X-sessions
Start an X server Offer a graphical login Authenticate a user Start the user's window mgr Wait until user logs out Restart X server Offer a graphical login screen for the next user And so forth
Different session managers:

xdm kdm gdm
Started from init in runlevel 5 (Fedora/RHEL) or as a regular System V service (SLES)
Figure 5-9. Session managers
LX036.0
Notes: Introduction
A session manager is a program that manages X sessions. This means that it starts Xorg and display a graphical login prompt. If a user tries to log in, the session manager authenticates this user and starts the users favorite window manager. When the user logs out, the session manager restarts Xorg 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 (Fedora/RHEL) or with a regular System V service script in /etc/init.d (SLES).
5-15
Student Notebook
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 applications Whole session Session chooser
Figure 5-10. X networked
LX036.0
Notes: Introduction
All connections between the different X components (server, window manager, and 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 running on a remote system. This is useful if you have disk- or dataless clients, that is, clients that do not have any disk
V5.2
Student Notebook
Uempty
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.
5-17
Student Notebook
X applications networked
xeyes
Xorg
Window Mgr
Application Host (hostname host)
TCP/IP Network
X Station (hostname xstation)
Figure 5-11. X applications networked
LX036.0
Notes: Introduction
The visual shows the first level of networking X-applications. Both the Xorg 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).
V5.2
Student Notebook
Uempty
Applications over TCP/IP

On the host (where X clients run):
host$ xterm -display xstation:0.0 or: host$ export DISPLAY=xstation:0.0 host$ xterm
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 xstation$ xauth extract xauthfile xstation:0.0 host$ xauth merge xauthfile xhost: Allows all connections from a given host xstation$ xhost +host
Figure 5-12. Applications over TCP/IP
LX036.0
Notes: Introduction
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 to determine the X server to contact if no -display option is given. 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 contact2, and displaynumber the screen to use.3
2 3
One system might be running multiple servers, although this is rare. One X server may handle multiple screens simultaneously on so-called dual-headed systems.
5-19
Student Notebook
You can imagine that it is not desirable that the whole Internet can redirect the graphical output of their commands to your screen. Therefore, doing this is by default disabled but can be enabled. The first, safest method is by using the xauth mechanism. This works roughly as follows: - When your X server is started, the startup scripts ensure that a random number, called the authorization record is generated. These records are stored in the $HOME/.Xauthority file. - Any client who wants to connect to the X server needs to present this authorization record. If no or an invalid authorization is presented, then access is disabled. - Since normally all applications are started by the same person who started the X server, they all use the same .Xauthority file and present the right record. - A client on a remote host obviously cannot access the .Xauthority file directly, so the authorization record needs to be transferred manually to that other host. This is a two-part process. First, on the host where the X server is running, you need to extract the correct record from the .Xauthority file and store it in a file. This is done with the following command: xauth extract xauthfile client:0.0 This means that the authorization record to connect to client:0.0 needs to be stored in the file xauthfile. You then transfer the file to the other system (using FTP, secure copy (SCP), remote file copy (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 now uses this authorization record to connect to the X server. 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. 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
V5.2
Student Notebook
Uempty
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 Note: rsh and ssh are both covered in the course LX07, Linux Network Administration I.
5-21
Student Notebook
Secure shell
Secure shell (SSH) is the descendant of rsh and rlogin, which are non-encrypted programs for remote shell logins OpenSSH is the most common free version of SSH and is available for virtually all UNIX-like operating systems Because the SSH protocol encrypts everything it sends and receives, it can be used to secure otherwise insecure protocols
From the command line, use the -X option with ssh

xstation$ ssh -p 8400 -l user -X -v 10.0.0.N
Figure 5-13. Secure shell
LX036.0
Notes: Introduction
Secure shell (SSH) transmits authority records over the network with security. If you are worried someone might be snooping your connection, use ssh, the kind of secure shell which can do X Forwarding over encrypted connections. To set up X forwarding as a default, write the following in your local /etc/sshd_config file: ForwardX11 yes The ssh server at the remote end automatically sets the DISPLAY variable to point to its end of the X forwarding tunnel. The remote tunnel end gets its one cookie and the remote ssh server generates it and puts it into the ~/.Xauthority file. At this point, X authorization using ssh is fully automatic. X over SSH solves some classic networking problems, such as tunnelling through firewalls and NAT. SSH also will handle compression for low-bandwidth links.
V5.2
Student Notebook
Uempty
X sessions networked
xeyes
Window Mgr
Xorg
Host
TCP/IP Network
X Station
Figure 5-14. X sessions networked
LX036.0
Notes: Introduction
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 Xorg server is running locally.
5-23
Student Notebook
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>
Figure 5-15. X sessions over TCP/IP
LX036.0
Notes: Introduction
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.
V5.2
Student Notebook
Uempty
For kdm, there are again two things you need to do: - You need to edit /etc/X11/kdm/Xaccess (RHEL/Fedora) or /opt/kde3/share/config/kdm/Xaccess (SLES) 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/X11/kdm/kdmrc (RHEL/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 (RHEL/Fedora) or /etc/opt/gnome/gdm/gdm.conf (SLES) to enable xdmcp direct and indirect requests. When you're done setting up your display manager, you need to restart it. This is done, for instance, 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
5-25
Student Notebook
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>
Figure 5-16. Chooser sessions
LX036.0
Notes: Introduction
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. You 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 shows 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
V5.2
Student Notebook
Uempty
Checkpoint
1. What is the function of X.org? ______________________________________________ What is the function of a window manager? ______________________________________________ How do you run an individual X application over a network?
______________________________________________ ______________________________________________
2.
3.
LX036.0
Notes:
1.
2.
3.
5-27
Student Notebook
Exercise 5: X window system
What you will do in this exercise: Configure X.org Run X applications Run applications over a network Run X sessions over a network
Figure 5-18. Exercise 5: X window system
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Unit summary
Having completed this unit, you should understand: The X Window system is the graphical user interface for Linux (and other UNIX-based systems) You should use the proper tool to configure X.org You can start and stop X with startx and Crtl-Alt-BackSpace Window managers make the GUI user friendly You can use X over a network safely with ssh
LX036.0
Notes:
5-29
Student Notebook
V5.2
Student Notebook
Uempty
Unit 6. Logging
This unit teaches you how to use logging.

After completing this unit, you should be able to: Describe logging concepts Configure the syslog daemon Use the logger program Use the logrotate program

Accountability: Checkpoint questions Exercises
References
Linux man pages SUSE Linux 10 Administration Guide RedHat Enterprise Linux V5 Administration Guide World Wide Web resources: http://www2.linuxjournal.com/article/4036 The System Logging daemons, syslogd and klog http://docs.mandragor.org/files/Operating_systems/Linux/The_Linux_ Administrators_Security_Guide_en/logging/ Log files and other forms of monitoring

Unit 6. Logging
6-1
Student Notebook
Unit objectives
After completing this unit, you should be able to: Describe logging concepts Configure the syslog daemon Use the logger program Use the logrotate program
LX036.0
Notes:
6-2
V5.2
Student Notebook
Uempty
Logging concepts
Various daemons generate log information All log items are sent to the syslog daemon
Tagged with facility and priority Through UDP/IP or UNIX socket
syslogd decides what to do, based on /etc/syslog.conf

kernel
klogd
/etc/syslog.conf cron
user
syslogd
/var/log/{warn,messages}
lpr To tty, wall, etc.

Figure 6-2. Logging concepts
LX036.0
Notes: Introduction
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 them to another host or displaying things on the console.

Unit 6. Logging
6-3
Student Notebook
Logging daemons
Because of these limitations, most daemons (but not all!) make use of a facility called the syslog daemon. The concept is very simple: - Every daemon that wants something to be logged creates the log message. It then tags this message with a facility (where it comes 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 syslogd daemon. It is then handled as normal syslog input. The klogd daemon is usually started and stopped together with the syslogd daemon.
6-4
V5.2
Student Notebook
Uempty
Facilities and priorities

Each log item is tagged with a facility and a priority Facility identifies the source
auth cron kern lpr ... panic crit warm info debug ...
Priority identifies the importance
For a complete list, see man syslog.conf
Figure 6-3. Facilities and priorities
LX036.0
Notes: Introduction
Rules in /etc/syslog.conf are a single line which consists of two parts. The first is a selector, which specifies the set of messages on which the rule is to act. The second is an action, which specifies what is to be done with messages that match the selector. The selector is further divided into a facility and a priority.
Facilities
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)
Unit 6. Logging
6-5
Student Notebook
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)
Priorities
The priority defines the importance of the message. The following priorities are defined: emerg (wake the whole staff; break out the emergency handbooks) panic (same as emerg; should no longer be used) alert (alert the sysadmin) crit (something is failing) err (something is going wrong, but it's probably not very serious) error (same as err; should no longer be used) warning (something might go wrong) warn (same as warning; should no longer be used) notice (something to keep an eye on) info (general information) debug (debugging information; should normally be discarded)
The priority is only an indication of the seriousness of the message. If you have a Linux server with two applications on it (example: a mission-critical Dynamic Host Configuration Protocol (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.
6-6
V5.2
Student Notebook
Uempty
/etc/syslog.conf
RHEL/Fedora example:
kern.warn *.info;mail.none;authpriv.none;cron.none
mail.*
/dev/tty10 /var/log/messages
/var/log/mail
authpriv.* cron.* *.emerg *.emerg
/var/log/secure
/var/log/cron * @sysadmin.acme.com
SLES Example:
filter f_authpriv { facility(authpriv); }; destination authpriv { file("/var/log/secure" fsync(yes)); };
log { source(src); filter(f_authpriv); destination(authpriv); };
Figure 6-4. /etc/syslog.conf
LX036.0
Notes: Introduction
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 might be specified on one line, as long as they are separated by a semicolon and do not contain any spaces. In addition to that, the wildcard * can be used, which matches all facilities or priorities.

Unit 6. Logging
6-7
Student Notebook
/etc/syslog.conf fields
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. - 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.
Working with remote systems

When sending the message to another system, the selection criteria from that /etc/syslog.conf file are applied too. 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.
6-8
V5.2
Student Notebook
Uempty
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/messages Feb 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 2006 ... host logger: Kernel panic! Please log off NOW!
Figure 6-5. logger command
LX036.0
Notes: Introduction
Logging is usually built-in into the daemon. But, you might also want to do some logging ourselves, especially if we are writing complex scripts. That's what the logger command is for.
Operation
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. Refer to 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.
Unit 6. Logging
6-9
Student Notebook
logrotate command
logrotate automatically "rotates" logs:
Copies the current log to archive log Can compress archive log Can mail archive log Cleans the current log Deletes old archive logs Usually run from cron
Criteria for rotation:

Time Size
Config file: /etc/logrotate.conf
Figure 6-6. logrotate command
LX036.0
Notes: Introduction
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 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.
Clean up log files

logrotate is designed to ease administration of systems that generate large numbers of log files. It allows automatic rotation, compression, removal, and mailing of log files. Each log file may be handled daily, weekly, monthly, or when it grows too large.
V5.2
Student Notebook
Uempty
The logrotate command is normally run from cron. It 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: - 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. - Compress the archive log file so that it uses less space on your filesystem. - Mail the logfile to someone. - Clean the current log. - Delete old archive logs, ensuring that only a limited amount of archive logs are being saved. 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).

Unit 6. Logging
6-11
Student Notebook
Sample /etc/logrotate.conf
# cat /etc/logrotate.conf # Global options (may be overwritten by local options) weekly rotate 4 errors root create # Include several config files in the given directory include /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 }
Figure 6-7. Sample /etc/logrotate.conf
LX036.0
Notes: Introduction
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.
V5.2
Student Notebook
Uempty
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.

Unit 6. Logging
6-13
Student Notebook
Analyzing logfiles
Analyze logfiles regularly
Preferably through a cron job, every day
Possible strategies:
Read through whole logfile Search for interesting things (positive search) Discard uninteresting things (negative search) Use automated tools for analysis
Automated tools
Simple: grep, grep -v, logcheck, logdigest Intermediate: logwatch, logsurfer Advanced: swatch
Automated tools typically send e-mail with results

Do not work if your e-mail subsystem is broken or disabled
Figure 6-8. Analyzing logfiles
LX036.0
Notes: Introduction
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 vis 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.
V5.2
Student Notebook
Uempty
- 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 analyzed and all non-interesting items are filtered out. This, in theory, leaves you with only the interesting items to look at. (This will not immediately work correctly. 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 does not present results twice. - logdigest is based on logcheck, and works generally the same. All configuration files are in /etc/logdigest. It is available on SLES, 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 can be difficult 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 can make it difficult to figure out where to make a change to get a certain thing to be reported or not. logwatch is installed on a RHEL/Fedora 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 SLES 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: youll 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.

Unit 6. Logging
6-15
Student Notebook
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 cell phone automatically. Depending on your distributions, one or more of these tools might already be installed by default or might need to be installed separately. A last note: most automated tools submit their results by e-mail and dont submit a report if theres 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 this last scenario, especially if you use these tools to monitor a large number of systems that do not all send in a report every day.
V5.2
Student Notebook
Uempty
Checkpoint
1. The ______________ receives all logging requests and forwards it to the right destination, depending on priority and facility. What does the logger command do? ______________________________________________ The logrotate command
a) b) c) Creates new log files Rotates the log files Deletes log files
2.
3.
LX036.0
Notes:
1. 2. 3.

Unit 6. Logging
6-17
Student Notebook
Exercise 6: Logging
What you will do in this exercise: Work with the syslogd daemon Modify the /etc/syslog.conf configuration file Work with the logger command Work with the logrotate command Analyze various logfiles
Figure 6-10. Exercise 6: Logging
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Unit summary
Having completed this unit, you should be able to understand: 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.
LX036.0
Notes:

Unit 6. Logging
6-19
Student Notebook
V5.2
Student Notebook
Uempty
Unit 7. Character devices, PCMCIA, and USB

This unit describes character devices and the workings of the Personal Computer Memory Card International Association (PCMCIA) and Universal Serial Bus (USB) subsystems.

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

Accountability: Checkpoint Exercise
References
Linux man pages SUSE Linux 10 Administration Guide RedHat Enterprise Linux V4 Administration Guide http://www.pcmcia.org/ The Personal Computer Memory Card International Association http://www.usb.org/home The USB Implementers Forum, Inc.
7-1
Student Notebook
Unit objectives
After completing this unit, you should be able to: Describe the main characteristic of a character device Configure serial, parallel, and PS/2 ports Configure a sound card Describe the PCMCIA subsystem Describe the USB subsystem
LX036.0
Notes:
7-2
V5.2
Student Notebook
Uempty
Character devices
A character device is any device which does not allow random access (seeks) Examples:
Console (keyboard, mouse) Serial terminals Printers Sound card Random number generator Null device
Figure 7-2. Character devices
LX036.0
Notes: Introduction
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 doesnt: 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
Copyright IBM Corp. 2001, 2009 Unit 7. Character devices, PCMCIA, and USB 7-3
Student Notebook
Character device naming

All character devices have a representation in /dev
# ls -l /dev crw------- 1 crw------- 1 crw------- 1 crw-rw-rw- 1 crw------- 1 crw-r--r-- 1 crw--w---- 1 crw-rw---- 1 crw-rw---- 1 crw-rw-rw- 1 root root root root root root root root root root root root lp root root root root uucp root root 5, 1 14, 3 6, 0 1, 3 10, 1 1, 8 4, 0 4,64 1, 9 1, 5 Oct Oct Oct Oct Oct Oct Oct Oct Oct Oct 18 18 18 18 18 18 18 18 18 18 2002 2002 2002 2002 2002 2002 2002 2002 2002 2002 /dev/console /dev/dsp /dev/lp0 /dev/null /dev/psaux /dev/random /dev/tty0 /dev/ttyS0 /dev/urandom /dev/zero
Figure 7-3. Character device naming
LX036.0
Notes: Introduction
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. The fifth and sixth columns represent the MAJOR and MINOR device number. This is the way user-space programs refer to hardware devices that they wish to use. A list of the major/minor device numbers can also be found in the kernel tree as Documentation/devices.txt.
7-4
V5.2
Student Notebook
Uempty
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
Example: Creating a empty file (32 MB)

# dd if=/dev/zero of=/tmp/swapfile bs=1M count=32
Figure 7-4. Virtual character devices
LX036.0
Notes: Introduction
On any Linux system, there are four virtual character devices. These devices have a representation in /dev but dont have matching hardware. These devices are: Table 10: Virtual character devices Device Description Used as the bit bucket, to discard unwanted output of a command or script. Example: /dev/null $ find / 2> /dev/null
7-5
Student Notebook
Table 10: Virtual character devices Device Description Used as an infinite supply of binary zeroes: If you do a cat /dev/zero, the output will be all ASCII character 0s. Unfortunately, this is an undisplayable character, so you need to do hexdump -v /dev/zero to see anything at all. /dev/zero /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 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 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/random
7-6
V5.2
Student Notebook
Uempty
Table 10: Virtual character devices Device Description 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 /dev/urandom 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 pseudo-random numbers (based on the earlier random numbers) as soon as the entropy pool is empty.
7-7
Student Notebook
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.
Figure 7-5. Serial devices, modems, and ISDN
LX036.0
Notes: Introduction
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 Internet Service Provider (ISP), or that others can dial-in to your system, typically using the Point-to-Point Protocol (PPP). (This is covered in course 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.
7-8
V5.2
Student Notebook
Uempty
Certain devices create other serial ports too. There are two devices where this is particularly true: - Internal modems. These modems have an ISA or Peripheral Component Interconnect (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. - Integrated Services Digital Network (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 programs1. The first four serial devices on a system are by default configured by the Linux kernel, which detects the Universal Asynchronous Receiver/Transmitter (UART) type and sets IRQ and I/O parameters correctly. If you have more than four serial devices, you can set their UART type and 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 youve got an external ISDN modem.
The only difference is that these modems generally require the use of the AT&E command to set the MSN (Multiple Subscriber Number).
7-9
Student Notebook
Serial terminals
Serial terminals are connected to the system via a serial cable to the serial port Serial terminals:
Hardware, for instance IBM 3151 PC 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 vt102 mo: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.
Figure 7-6. Serial terminals
LX036.0
Notes: Introduction
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 they allow you to have a console attached to the system over a long distance, without requiring a network. Also, 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 to 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.
V5.2
Student Notebook
Uempty
mgetty automatically configures a modem for dial-in. If youre 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.
7-11
Student Notebook
Parallel and PS/2 ports

/dev/lp0, /dev/lp1: LPT1 and LPT2 parallel ports /dev/psaux: PS/2 port (used for mice and keyboards)
Figure 7-7. Parallel and PS/2 ports
LX036.0
Notes: Introduction
The parallel and PS/2 ports are represented as follows: - /dev/lp0 and /dev/lp1 represent LPT1 and LPT2, respectively. - /dev/psaux represents the PS/2 port used for your mouse.
V5.2
Student Notebook
Uempty
Sound cards
When a sound card has been detected and configured, the kernel activates the /dev/dsp interface. Uses Advanced Linux Sound Architecture (ALSA)
Standard Linux sound device drivers Modular device driver Support for older OSS API
Auto-detected and configured during installation

Can be reconfigured through distribution tools
Figure 7-8. Sound cards
LX036.0
Notes: Introduction
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 into 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 led 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 (SLES), or system-config-soundcard (RHEL/Fedora).
7-13
Student Notebook
OSS
OSS/Linux is a commercial implementation of the Linux sound drivers that are packaged with the Linux kernel. OSS/Linux is 100% compatible with the freeware drivers (now known as OSS/Free). OSS/Linux is aimed at the commercial Linux market and new Linux users who require products which are stable and easy to use and come with technical support.
ALSA
The Advanced Linux Sound Architecture (ALSA) sound driver was originally written as a replacement for the Linux kernel sound for Gravis UltraSound (GUS) cards. As this GUS replacement proved to be a success, the author started the ALSA project for a generic driver for several sound chips, with fully modularized design. ALSA is compatible with the OSS/Free and OSS/Linux sound drivers but has its own interface that is even better than the OSS drivers. A list of features can be found at the main page of the ALSA project: http://www.alsa-project.org.
V5.2
Student Notebook
Uempty
PCMCIA devices
PCMCIA (aka CardBus) devices are detected and activated by the kernel automatically
Kernels since 2.6.13-rc1 do not require the cardmgr daemon anymore
To list all available devices use the cardctl (PCMCIA) and lsusb (USB) commands
# lsusb Bus 002 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000 # cardctl status Socket 0: 5V 16-bit PC Card function 0: [ready] Socket 1: no card
Figure 7-9. PCMCIA devices
LX036.0
Notes:: Introduction
Personal Computer Memory Card International Association (PCMCIA) devices (also known CardBus)2 are detected by modern 2.4 kernels automatically. If the kernel has support for the particular device, then it is configured and activated automatically. With 2.4 kernels, PCMCIA devices require the presence of the cardmgr daemon, which uses configuration data in /etc/pcmcia (particularly the *.opts files) to configure a device properly (this might change in the future). 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. Kernels since 2.6.13-rc1 do not require the cardmgr daemon anymore. The PCMCIA bus acts almost as any other bus with full /sbin/hotplug support. Old style cardmgr setups should still work if the kernel is configured correctly. However, be aware that the ioctl for PCMCIA will be removed in the near future. The change to /sbin/hotplug
2
Technically, all 16-bit cards are PCMCIA devices, and 32-bit cards are CardBus cards. From the outside, CardBus cards can be recognized by eight little notches on the top of the connector, while a PCMCIA card is flat.
7-15
Student Notebook
capability means that the normal /etc/init.d/pcmcia script is not required any more and in fact only hurts as it starts cardmgr. To use the new pcmciautils, it is a requirement that cardmgr is not started. 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 network interfaces, unmount filesystems, and so forth, before removing the hot-pluggable device which implements this network interface or filesystem.
V5.2
Student Notebook
Uempty
lspci command output

# lspci 00:00.0 00:01.0 00:1e.0 00:1f.0 00:1f.1 00:1f.3 00:1f.5 01:00.0 Host bridge: Intel 82855PM Processor to I/O Controller PCI bridge: Intel 82855PM Processor to AGP Controller PCI bridge: Intel 82801 Mobile PCI Bridge ISA bridge: Intel 82801DBM LPC Interface Bridge IDE interface: Intel 82801DBM IDE Controller SMBus: Intel 82801DB/DBL/DBM SMBus Controller Multimedia audio controller: Intel 82801DB/DBL/DBM AC'97 Audio Controller VGA compatible controller: ATI Technologies Inc M10 NT [FireGL Mobility T2]
>>>>>>>> Plug in a PCI Modem card here <<<<<<<<
# lspci 00:00.0 00:01.0 00:1e.0 00:1f.0 00:1f.1 00:1f.3 00:1f.5 01:00.0 00:1f.6
Host bridge: Intel 82855PM Processor to I/O Controller PCI bridge: Intel 82855PM Processor to AGP Controller PCI bridge: Intel 82801 Mobile PCI Bridge ISA bridge: Intel 82801DBM LPC Interface Bridge IDE interface: Intel 82801DBM IDE Controller SMBus: Intel 82801DB/DBL/DBM SMBus Controller Multimedia audio controller: Intel 82801DB/DBL/DBM AC'97 Audio Controller VGA compatible controller: ATI Technologies Inc M10 NT [FireGL Mobility T2] Modem: Intel 82801DB/DBL/DBM AC'97 Modem Controller
Figure 7-10. lspci command output
LX036.0
This output of the lspci command is shown above, both before a device is plugged in and after.
7-17
Student Notebook
USB devices
USB devices are (usually) detected and activated by the kernel automatically
High-speed USB 2.0 is an external bus that supports data rates up to 480Mbps
Devices include (but not limited to):

- Mass storage devices - Music players - Mice - Touchpads - Joysticks - Compact flash memory - Printers - Keyboards - Graphic tablets
Depending upon the hardware, it may be auto-detected and auto-mounted

Figure 7-11. USB devices
LX036.0
Also referred to as high-speed USB, USB 2.0 is an external bus that supports data rates up to 480 Mbps. USB 2.0 is an extension of USB 1.1. USB 2.0 is fully compatible with USB 1.1 and uses the same cables and connectors. Newer kernels (including 2.6.x ones) have updates which seem to resolve the worst problems reported. The driver version string should be no older than June 2003. Linux provides USB support for devices conforming to the USB Human Interface Device class, which includes USB keyboards, USB mice and touchpads, USB joysticks, and USB graphics tablets. These devices are supported such that they can appear as normal keyboards, mice, and joysticks. This means that applications do not need to be changed to use the new kernel capabilities. In addition, the devices can also appear on a new event interface, which allows customized applications to take advantage of the additional capabilities offered by USB devices.
V5.2
Student Notebook
Uempty
Another popular USB peripheral is a USB printer. These devices usually conform to the printer class defined by the USB Implementers Forum, and Linux USB supports the printer class. Some manufacturers have produced printers that require special escape codes to enable the USB port; however this is normally fairly easy to configure in Linux using the normal printer tools (such as LPD and CUPS). Although there is no official USB parallel port class, Linux USB supports a wide range of parallel adapters because many of them conform to the USB printer class driver. Linux USB also supports a large range of serial devices, including ConnectTech Whiteheat, the Handsprind Visor, the range of Keyspan devices, Belkin and Peracom single port converters, some of the Digi Accelport converters, and the Empeg car MP3 player. Some serial devices are not yet supported because of a lack of technical information from the manufacturers. Linux also supports the USB mass storage class, used by a wide range of conventional storage devices (such as floppy disks and the Iomega Zip disks), and also used for emerging standards such as Compact Flash, Smartmedia and the Sony Memory Stick. Some manufacturers have used the mass storage device class to make digital cameras appear as normal disks, allowing the full range of Linux file utilities to be used for image manipulation. 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 includes one of the modules usb-uhci.o and usb-ohci.o, depending on the type of USB controller you have.
7-19
Student Notebook
lsusb command output

# lsusb Bus 005 Bus 004 Bus 003 Bus 002 Bus 001
Device Device Device Device Device
001: 001: 001: 001: 001:
ID ID ID ID ID
0000:0000 0000:0000 0000:0000 0000:0000 0000:0000
>>>>>>>> Plug in a USB Mouse here <<<<<<<<
# lsusb Bus 005 Bus 004 Bus 003 Bus 003 Bus 002 Bus 001
Device Device Device Device Device Device
001: 001: 002: 001: 001: 001:
ID ID ID ID ID ID
0000:0000 0000:0000 046d:c50e Logitech Cordless Mouse Receiver 0000:0000 0000:0000 0000:0000
Figure 7-12. lsusb command output
LX036.0
This output of the lsusb command is shown above, both before a device is plugged in and after. Some devices, depending upon how smart they are, may automatically mount. In this example, a mass storage device is plugged into a USB port. During the next moment, the USB device is discovered and mounted, after which the df command is run and shows: # df Filesystem /dev/hda5 /dev/hda3 /dev/shm /dev/sda1 1K-blocks 19840892 93327 1037732 999552 Used 17745864 17921 0 30720 Available 1070888 70587 1037732 968832 Use% 95% 21% 0% 4% Mounted on / /boot /dev/shm /media/CRUZER-1GB
V5.2
Student Notebook
Uempty
Checkpoint
1. 2. True / False: A character device allows random seeks. What is the difference between /dev/random and /dev/urandom?
_____________________________________________
3.
PCMICA and USB devices are detected automatically by the _____________.
LX036.0
Notes:
Write down your answers here: 1.
2.
3.
7-21
Student Notebook
Exercise 7: Character devices, PCMCIA, and USB
What you will do in this exercise: Nothing! Take a break and get ready for the next unit.
Figure 7-14. Exercise7: Character devices, PCMCIA, and USB
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Unit summary
Having completed this unit, you should be able to understand: 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. Kernels since 2.6.13-rc1 do not require the cardmgr daemon for PCMCIA, USB, and other hot-pluggable devices
LX036.0
Notes:
7-23
Student Notebook
V5.2
Student Notebook
Uempty
Unit 8. 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: Logical Volume Management (LVM) and Redundant Array of Independent Disks (RAID).

After completing this unit, you should be able to: Name the most important characteristic of a block device List various block devices List the device naming scheme for Integrated Drive Electronics (IDE) and Small Computer System Interface (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

References
Linux man pages SUSE Linux 10 Administration Guide RedHat Enterprise Linux V5 Administration Guide Persistent device names for Linux 2.6 Hannes Reinecke, Linux-Kongress 2004
8-1
Student Notebook
World Wide Web resources: http://www.ibm.com/linux/ Linux at IBM http://lwn.net/Articles/31185/ Driver porting: Device model overview http://librenix.com/?inode=475 Using the Linux /proc filesystem http://www.lanana.org/ The Linux Assigned Names And Numbers Authority
http://developer.apple.com/technotes/tn/tn1062.html
Apple Developer Connection: Technical Note TN 1062

http://www-128.ibm.com/developerworks/library/pa-spec2.html
IBM: Standards and specs: Open Firmware

http://linuxdevices.com/articles/AT4389927951.html
Overview of Device Drivers and Loadable Kernel Modules

http://linuxdevices.com/articles/AT4389927951.html
Migrating device drivers to Linux kernel 2.6
8-2
V5.2
Student Notebook
Uempty
Unit objectives
After completing this unit, you should be able to: 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
LX036.0
Notes:
8-3
Student Notebook
Block devices
A block device is any device which allows random access ("seeks") and which is divided into "blocks" of a given size.
block
1 2 3 4 5 6 7 8
512
byte
4096
Typical block devices:

Hard disks (and partitions) Floppy disks Virtual block devices (RAID and LVM)
Figure 8-2. Block devices
LX036.0
Notes: Introduction
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. Also, 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 youll see in this discussion, it can also be used for LVM and/or RAID.
8-4
V5.2
Student Notebook
Uempty
Traditional block device naming

All block devices have a special file representation in /dev
# ls -l /dev total 1 brw-rw---- 1 brw-r----- 1 brw-r----- 1 brw-r----- 1 brw-r----- 1 brw-rw---- 1 brw-r----- 1 brw-r---- 1 . . .
root root root root root root root root
floppy 2, 0 Apr 4 03:37 fd0 disk 3, 0 Apr 4 03:37 sda disk 3, 1 Apr 4 03:37 sda1 disk 3, 2 Apr 4 03:37 sda2 disk 3, 3 Apr 4 03:37 sda3 disk 22, 0 Apr 4 03:37 sdc disk 7, 0 Apr 4 03:37 loop0 disk 9, 0 Apr 4 03:37 md0
fd0, fd1, ...: floppy disk (max 8) hda, hdb, ...: IDE hard disk (max 8) sda, sdb, ...: SCSI hard disk (max 128)
Figure 8-3. Traditional block device naming
LX036.0
Notes: Introduction
The device directory (/dev) contains special files that are used to manage system devices. There are two primary types of files located in the /dev directory. The first is a block device. An example of this would be a disk (sda) or tape (st) device. The second type of device is a character device. An example of such would be a terminal (tty) device. Each device is assigned a major and minor device number. The major device number identifies the type of device, that is, all SCSI disk devices (of the same model type) would have the same number as would all the keyboards. The minor device number identifies a specific device, that is, the keyboard attached to the workstation. While there is a /dev directory in other UNIX-like operating systems, they are not all created the same. Also, the Linux 2.6 kernel treats this directory different than previous versions of Linux.
8-5
Student Notebook
Dynamic device naming with udev

udev traditionally stored in /dev directory on Linux
Node (file) for every possible type of device, regardless of whether it actually exists in the system The /dev directory can take up a lot of space
udev introduces a new way of creating device nodes

Compares the information made available by sysfs with data provided by the user in the form of rules
udev rule driven

/etc/udev/udev.rules
Identify device path and serial number

udevinfo command udevinfo a p ùdevinfo q path n /dev/hda`
Figure 8-4. Dynamic device naming with udev

.
LX036.0
Notes: Introduction
On typical Linux-based systems, the /dev directory is used to store file-like device nodes which refer to certain devices in the system. Each node points to a part of the system (a device), which might or might not exist. Userspace applications can use these device nodes to interface with the systems hardware. The original /dev directories were just populated with every device that might possibly appear in the system (as an example, even though your system may only have three disk drives, you would still have entries in the /dev directory to handle potential disk devices). The /dev directory was typically very large because of this.
8-6
V5.2
Student Notebook
Uempty
udev
Userspace Devfs (udev) is the new way of managing the /dev directory and is designed to clear up some issues with previous /dev implementations and provide a robust path forward. In order to create and name /dev device nodes corresponding to devices that are present in the system, udev relies on matching information provided by SYSFS with rules provided by the user. This documentation aims to detail the process of rule-writing, one of the only udev-related tasks that must (optionally) be performed by the user.
udev rules
Depending on the distribution, udev will follow rules defined in a text file. In the case of SLES 10, this is handled by the file /etc/udev/udev.rules (RHEL uses files in a sub-directory /etc/udev/rules.d/, where you enter multiple files to be read, as is the case with rc.d startup scripts). It is not absolutely necessary for the user to create rules. If a device is connected, the appropriate device node is created. However, the rules introduce the possibility of changing the names for the nodes. This offers the convenience of replacing a cryptic device name with a name that is easy to remember and also of having consistent device names where two devices of the same type have been connected. We will take a look at default values with the next visual.
udevinfo command
The file system /sys stores small files with hardware information in a directory tree. Each file generally is only given one item of information, such as the device name, the vendor, or the serial number. Each of these files can be used as the value of a key. To use several SYSFS keys in one rule, however, you can only use files in the same directory. The udevinfo command can be a useful tool here. You just have to change directory to a subdirectory of /sys that refers to the relevant device and is given a file dev. These directories are all located under /sys/block or /sys/class. If a device node already exists for the device, udevinfo can again reduce the amount of work you have to do. The command udevinfo -q path -n /dev/hda outputs /block/hda. This means that the directory you are looking for is /sys/block/hda. Now call udevinfo with the following syntax: udevinfo -a -p /sys/block/hda. The two commands can also be combined, for example: udevinfo -a -p ùdevinfo -q path -n /dev/hda`. The following is an example of the output:
sys2:~ # udevinfo -a -p ùdevinfo -q path -n /dev/hda` udevinfo starts with the device the node belongs to and then walks up the device chain, to print for every device found, all possibly useful attributes in the udev key format.
8-7
Student Notebook
Only attributes within one device section may be used together in one rule, to match the device for which the node will be created. looking at device '/block/hda': KERNEL=="hda" SUBSYSTEM=="block" SYSFS{stat}==" 20824 9456 4637124 0 1071988 5104484" SYSFS{size}=="58633344" SYSFS{removable}=="0" SYSFS{range}=="64" SYSFS{dev}=="3:0" looking at device '/devices/pci0000:00/0000:00:1f.1/ide0/0.0': ID=="0.0" BUS=="ide" DRIVER=="ide-disk" SYSFS{modalias}=="ide:m-disk" SYSFS{drivename}=="hda" SYSFS{media}=="disk" looking at device '/devices/pci0000:00/0000:00:1f.1/ide0': ID=="ide0" BUS=="" DRIVER=="" looking at device '/devices/pci0000:00/0000:00:1f.1': ID=="0000:00:1f.1" BUS=="pci" DRIVER=="PIIX_IDE" SYSFS{modalias}=="pci:v00008086d0000244Bsv00001014sd000001C6bc01sc01i80" SYSFS{local_cpus}=="1" SYSFS{irq}=="0" SYSFS{class}=="0x010180" SYSFS{subsystem_device}=="0x01c6" SYSFS{subsystem_vendor}=="0x1014" SYSFS{device}=="0x244b" SYSFS{vendor}=="0x8086" looking at device '/devices/pci0000:00': ID=="pci0000:00" BUS=="" DRIVER=="" 681755 467300 1161902 563892 13828784
8-8
V5.2
Student Notebook
Uempty
udev rules
The /sbin/udev.get_ persistent_device_name.sh wrapper can be used directly in the udev rules. Here is an example for SCSI, which can also be generalized to USB or IDE (write it as one line): BUS=scsi, PROGRAM=/sbin/udev.get_persistent_device_name.sh, NAME=%k, SYMLINK=%c{1+} When the system boots and this rule is followed, any device that is on a SCSI bus will be assigned per the program udev.get_persistent_device_name.sh. If you change a NAME value in the next line, the name will be set to your new value. Please note, in the case of disk drives, it is still suggested that disks keep the traditional name (sda, sdb, and so forth)
8-9
Student Notebook
Floppy disks
Floppy disks may need to be initialized first with correct size information (low level format) with the fdformat command # fdformat -n /dev/fd0h1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... done
Note: To format a floppy disk with a different capacity, use another device file (for example /dev/fd0u2880)
Figure 8-5. Floppy disks
LX036.0
Notes: Introduction
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 (write requests are not carried out immediately). However, if a user ejects a disk without first unmounting it (unmounting a disk will cause all data to be written to disk), the data not yet written to disk will be lost. So you always need to unmount a floppy disk and wait for the disk light to go off before ejecting.1
1
Some other architectures, such as the Sun Sparc, have a software eject, where the disk can only be ejected by running the eject command. This command only works if the disk is not mounted.
V5.2
Student Notebook
Uempty
Hard disks
Most common device for persistent storage Two common types: IDE and SCSI Integrated Drive Electronics (IDE)
Max two disks (master/slave) on one bus Max two buses on adapter Max two adapters in system Also supports CD-ROM (ATAPI) Device naming /dev/hda, hdb, ..., hdh 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 bus Generally more expensive than IDE Also supports CD-ROM, tapes, zip drives, ... Device naming /dev/sda, ..., sdz, sdaa, ..., sddx
Small Computer System Interface (SCSI)
Figure 8-6. Hard disks
LX036.0
Notes: Introduction
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
8-11
Student Notebook
- The master on the second bus on the first adapter is hdc - and so forth. 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 AT Attachment Packet Interface (ATAPI) standard.
SCSI devices
SCSI is a technology which is technically superior to IDE but generally more expensive. It has various subtypes, each of which has its 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. Thus, the first drive detected becomes sda, the second device becomes sdb, and so forth.2 In most cases, 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. Information on your SCSI devices can be obtained from the /proc/scsi directory, and with the command scsi_info device.
This causes a problem if new disks are inserted with IDs lower than the existing drives. Suppose youve got one SCSI bus with two disks connected to it. The disks use ID 3 and 6, respectively, and are named sda (device with ID 3) and sdb (device with ID 6). If you were to add a disk with ID 5, then this new disk becomes sdb, and the disk with ID 6 becomes hdc. This might lead to boot problems, particularly when the disk partitions need to be fsck-ed and mounted, and their names (/dev/hdb1, for instance) are hard-coded in /etc/fstab, instead of using ext2 filesystem labels.
V5.2
Student Notebook
Uempty
Monitoring hard disk health

Self Monitoring And Reporting Technology (SMART)
Technology included in most modern IDE/SCSI disks Reports various disk parameters (errors, temperature, various counts, ...) to OS
smartctl: Tool for accessing SMART data

smartctl -a /dev/sda reports all /dev/sda parameters smartctl -X /dev/sda initializes long self-test man smartctl for more options
smartd: Monitoring daemon

Monitors attributes every 30 minutes Reports changes to syslog Newer versions can send mail too if attributes change (use /etc/smartd.conf for configuration)
Figure 8-7. Monitoring hard disk health
LX036.0
Notes: Introduction
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 Self Monitoring and Reporting Technology (SMART). 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.
Copyright IBM Corp. 2001, 2009 Unit 8. Block devices, RAID, and LVM 8-13
Student Notebook
- 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.
V5.2
Student Notebook
Uempty
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 record partition table Windows
Linux / Linux /home
Linux swap
Figure 8-8. Hard disk partitions
sda: The first sector of the disk contains the MBR and Partition Table sda1: First primary partition holds a Windows filesystem sda2: Second primary partition is an extended partition and holds three logical partitions sda5: First logical partition holds a Linux filesystem that will be mounted as / sda6: Second logical partition holds a Linux filesystem that will be mounted as /home sda7: Third logical partition holds a Linux swap space
LX036.0
Notes: Introduction
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 four 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...
8-15
Student Notebook
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 and four for the primary partitions, which leaves 11 for the logical partitions.
V5.2
Student Notebook
Uempty
Partitioning tools
fdisk
Virtually every PC OS comes with a tool fdisk to create partitions for that OS
Linux, Windows, and so forth parted
GPLed Linux program, available at www.gnu.org Can create/resize/move/delete partitions
GParted, QTParted
GUI utilities that use GNU Parted Can create/resize/move/delete partitions
Disk Druid and others

Partitioning program integrated in Linux install program
Figure 8-9. Partitioning tools
LX036.0
Notes: Introduction
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.
8-17
Student Notebook
RAM disks
A RAM disk is a block device created in memory
Automatically created when used Size is compiled into the kernel (16 Mb) Disappears 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
Figure 8-10. RAM disks
LX036.0
Notes: Introduction
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. Also, since they are stored in memory, their contents vanish when you shut down your system. RAM disks occupy memory and keeps doing that until you shut down your system or deallocate the RAM disk by hand with the freeramdisk command. Unfortunately, this command is not included by default in all distributions.
V5.2
Student Notebook
Uempty
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
Use losetup to initially set up the loop device Can then mount and umount 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
Figure 8-11. The loop device
LX036.0
Notes: Introduction
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 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.
8-19
Student Notebook
losetup command
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.
V5.2
Student Notebook
Uempty
Logical volume management (1 of 2)

Traditional disk partitioning scheme has several disadvantages:
Virtually impossible to resize or move a partition Partition 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) PEs 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
Figure 8-12. Logical volume management (1 of 2)
LX036.0
Notes: Introduction
Logical Volume Management (LVM) is a technique to overcome some limitations that are imposed on the system with the traditional partitioning scheme: - It is virtually impossible to re-size 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: a. 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 (PV). b. Each physical volume is split into physical extents (PEs) of identical size. The default size of a PE is 4 MB, but this can be changed when the VG is defined.
Student Notebook
c. 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 one or more PEs, its size will always be a multiple of 4 MB.
Physical extent (PE)

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).
V5.2
Student Notebook
Uempty
Logical volume management (2 of 2)
physical volume (hard disk or partition)
PE PE PE
PE PE PE
PE PE PE
PE PE PE
PE PE PE
PE PE PE
logical volume
volume group
Figure 8-13. Logical volume management (2 of 2)
LX036.0
Notes: Introduction
The visual shows a volume group that consists of two physical volumes. In this case, whole disks are used as physical volumes, but you 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.
8-23
Student Notebook
LVM implementation overview

Add hard disks and/or create partitions (type 0x8e) on existing hard disks Initialize physical volumes (disks or partitions)
# pvcreate /dev/sda3 # pvcreate /dev/sdb
Create volume group vg00 with physical volumes # vgcreate vg00 /dev/sda3 /dev/sdb Create logical volume lv00 in volume group
# lvcreate -L 50M -n lv00 vg00
Can now use /dev/vg00/lv00 as block device

Figure 8-14. LVM implementation overview
LX036.0
Notes: Introduction
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.
V5.2
Student Notebook
Uempty
Physical volume commands

pvcreate <pv>
Initializes a physical volume by putting an (empty) volume group descriptor area at the start of the PV
VGDA ( Volume Group Descriptor Area)
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
Figure 8-15. Physical volume commands
LX036.0
Notes: Introduction
When you implement a volume management strategy on your system, you will have a number of commands available to manage the disc devices. As an example, here are some commands you will use: Table 11: Important physical volume commands Command Description Initializes a physical volume. Among other things, this means that a volume group descriptor area (VGDA) is added at the start of the PV. pvcreate This VGDA later contains LVM information, such as the size of the physical extents. Allows you to move all PEs on a PV to another PV within the same pvmove volume group. This is useful if you want to take that PV out of the volume group. pvdisplay Allows you to view information about a PV.
Student Notebook
Volume group commands

vgcreate [-s <pe size>] <vg name> <pv> [<pv>...]
Create a volume group
Volume Group (VG)
Physical Volume (PV) Physical Volume (PV) Physical Volume (PV)
vgdisplay [<vg>]
Display information about a volume group
vgremove <vg>
Delete a volume group
Figure 8-16. Volume group commands
LX036.0
Notes: Introduction
Several commands are available to let you work with volume groups. The following are a sample of some of these commands: Table 12: Important volume group commands Command Description Allows you to create a new volume group. As part of the command, vgcreate you need to specify the PE size that is going to be used in this volume group. vgdisplay Displays information about a volume group. Changes attributes of a volume group. The most important change is to deactivate a volume group with the vgchange -a n vg_name vgchange command. This needs to be done before either vgexport or vgremove can be executed. vgremove Deletes a volume group.
V5.2
Student Notebook
Uempty
Logical volume commands

lvcreate -L <size> [-n <lv name>] <vg> [<pv>...]
Create a logical volume in a volume group
Logical Volume (LV) LV LV LV
Volume Group (VG)

Physical Volume (PV) Physical Volume (PV) Physical Volume (PV)
lvdisplay <lv> [<lv>...]

Display information about a logical volume
lvremove <lv> [<lv>...]

Remove a logical volume
Figure 8-17. Logical volume commands
LX036.0
Notes: Introduction
There are several commands that let you manage logical volumes. The following are some examples of these commands: Table 13: Important logical volume commands Command Description Creates a logical volume of the specified size, with an optional name, lvcreate in a certain volume group. You can also specify the physical volumes to be used. lvdisplay Displays information about a logical volume. lvremove Removes a logical volume
8-27
Student Notebook
Striping logical volumes

A logical volume may be striped across two or more physical volumes during creation For large data transfers, this increases performance
# lvcreate -L 300M -i 2 -I 8 -n mystripedlv vg00
(hard disk or partition)
physical volume
PE PE PE
PE PE PE
PE PE PE
PE PE PE
PE PE PE
PE PE PE
volume group
/dev/vg00/mystripedlv
Figure 8-18. Striping logical volumes
LX036.0
Notes: Introduction
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.
V5.2
Student Notebook
Uempty
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/sdb6 # vgreduce vg00 /dev/sda5 ERROR: can't reduce volume group "vg00" by used physical volume "/dev/sda5" # pvmove /dev/sda5 /dev/sdb6 # vgreduce vg00 /dev/sda5
Figure 8-19. Extending/reducing a volume group
LX036.0
Notes: Introduction
After a while, you 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 can take place while the system is running: You dont 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.
8-29
Student Notebook
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/mylv lvextend -- rounding relative size up to physical extent boundary lvextend -- extending logical volume "/dev/vg00/mylv" to 380 MB lvextend -- doing automatic backup of volume group "system" lvextend -- logical volume "/dev/vg00/mylv" successfully extended # lvreduce -l -12 /dev/system/mystripedlv ...
Figure 8-20. Extending/reducing a logical volume
LX036.0
Notes: Introduction
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.
V5.2
Student Notebook
Uempty
LVM backup and recovery

It is very important to save the LVM metadata stored in the VGDA for recovering reasons.
1. vgcfgbackup 2. vgcfgrestore -n vg_name PV
VGDA VGDA VGDA
/etc/lvm/backup/vg_name.conf
VGDA
VGDA
VGDA
Figure 8-21. LVM backup and recovery
LX036.0
Notes: Introduction
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/lvm/backup/vg_name.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 thats another topic.
8-31
Student Notebook
Additional LVM considerations

Linux LVM implementation has "snapshot" capability
Can be useful for fast backups
If LVM-based filesystems are listed in /etc/fstab, then LVM support needs to be included in the initial root disk (initrd) Mirroring is handled outside of the LVM structure LVM uses the device mapper kernel device driver LVM snapshots are read/write by default
Figure 8-22. Additional LVM considerations
LX036.0
Notes: Introduction
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.
V5.2
Student Notebook
Uempty
Kernel information
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 modules is included in the initial root disk (initrd).
Mirroring
You can mirror the disk drives that contain the LVM structure. However, this is done outside of LVM itself (unlike other LVM implementations, such as AIX).
LVM2 snapshots
In LVM2, snapshots are read/write by default. Read/write snapshots work like read-only snapshots, with the additional feature that if data is written to the snapshot, that block is marked in the exception table as used and never gets copied from the original volume. LVM1 has read-only snapshots. Read-only snapshots work by creating an exception table, which is used to keep track of which blocks have been changed. If a block is to be changed on the origin, it is first copied to the snapshot, marked as copied in the exception table, and then the new data is written to the original volume. The read/write default of LVM2 opens up many new possibilities that were not possible with LVM1's read-only snapshots. One example is to snapshot a volume, mount the snapshot, and try an experimental program that change files on that volume. If you don't like what it did, you can unmount the snapshot, remove it, and mount the original filesystem in its place.
8-33
Student Notebook
RAID
Redundant Array of Independent Disks Typical PC hard disks, compared to expensive mainframequality hard disks, are:
Slower Less reliable Smaller But less expensive
RAID uses multiple hard disks in an array to create a logical device that is:
Faster More reliable Or larger And still relatively inexpensive
Figure 8-23. RAID
LX036.0
Notes: Introduction
Redundant Array of Inexpensive Disks (RAID) 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 devices used on mainframes but were also less expensive. Thus, people started packing a large number of these hard drives together with some additional control software (usually implemented on a dedicated hardware chip). Once combined, they could be used as if it were one logical device that was either faster, more reliable, or larger than the individual disks. This new combination was still less expensive than buying one mainframe-quality disk that would do the same.
V5.2
Student Notebook
Uempty
It is important to note that the three features (speed, reliability, and 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.
8-35
Student Notebook
RAID levels (1 of 2)
RAID-linear
1 2 3 4 5 6 7 8 9 10
RAID-0: striping
1 3 5 7 9 2 4 6 8 10
RAID-1: mirroring
1 2 3 4 5 1 2 3 4 5
RAID-4: striping with parity disk

1 3 5 7 9 2 4 6 8 10 p p p p p
RAID-5: striping with parity

1 3 p 7 9 2 p 5 8 p p 4 6 p 10
Figure 8-24. RAID levels (1 of 2)
LX036.0
Notes: Introduction
In the RAID standards, several different levels have been defined. All these levels have different ways of storing the data on disk and thus exhibits different characteristics.
RAID linear
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 leads to a doubled
V5.2
Student Notebook
Uempty
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 can 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 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
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 costs a lot of disk space, but means that you can sustain multiple disk crashes without losing your data.
RAID 4
RAID-4 also offers redundancy, 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
RAID-5 is similar to RAID-4 in that it calculates the parity of two disk blocks and stores this in a third disk block. It also stripes the data onto the disks. The difference between RAID-4 and RAID-5 is that RAID-4 stores all parity information on the same disk. This disk then quickly becomes a bottleneck unless this disk is significantly faster than the others. With RAID-5, the parity information is striped too, leading to better performance. Several other RAID levels exist, but these are not implemented in Linux, and not widely used anyway.
4 The author of this course uses a RAID-0 array for storing the /export filesystem of a network install server. If a disk fails, the data on it can simply be restored from the distribution CDs. 5 The parity in this case is calculated by XORing the data on disk 1 with the data on disk 2. If one of the three elements (disk1, disk2, parity) should fail, then that element can be calculated based on the other two.
8-37
Student Notebook
RAID levels (2 of 2)
RAID levels have different characteristics
RAID-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
Equal
Equal
No
3 GB
Can be used if disks are not equal
Fast
Fast
No
3 GB
Fast
Somewhat slower Slow
Yes
1 GB
Can sustain N-1 disk crash(s)
Somewhat faster Somewhat faster
Yes
2 GB
Can sustain one disk crash Parity disk is bottleneck Can sustain one disk crash CPU intensive
Somewhat faster
Yes
2 GB
(*) Performance compared to a single disk, for data transfers greater than block size
Figure 8-25. RAID levels (2 of 2)
LX036.0
Notes: Introduction
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 may or may not be suited for your circumstances.
V5.2
Student Notebook
Uempty
Linux RAID support

Software RAID
Implemented in Linux kernel Needs mdadm package Uses disk partitions to create RAID devices Logical device name: /dev/mdn
Hardware RAID
Implemented in special adapter cards Adapter needs to be supported by Linux kernel Generally specific software needed to configure adapter correctly (might not be available under Linux) RAID devices show up as regular SCSI disk
Figure 8-26. Linux RAID support
LX036.0
Notes: Introduction
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 mdadm package, which is usually supplied as part of your distribution. For software RAID, the only thing you need is more than one (IDE and/or SCSI) hard disk. In fact, you can even test it by using multiple partitions on one single disk, but that negates any benefit you might want to gain from RAID. Hardware RAID is typically implemented in special adapter cards, which look like SCSI controllers (in fact, they usually are) but contain some special RAID chipsets. Most of these controllers are supported by Linux. In fact, Linux just detects a single large disk instead of multiple, smaller ones. Configuring these adapter cards might require special software, but once the cards are configured, no additional software is needed.
Student Notebook
Linux software RAID implementation: mdadm

Linux multiple devices (MD) admin tool Handles all configuration, monitoring, and maintenance tasks Common syntax for every RAID management command No configuration file
Figure 8-27. Linux software RAID implementation: mdadm
LX036.0
Notes: Introduction
RAID devices are virtual devices created from two or more real block devices. This allows multiple devices (typically disk drives or partitions thereof) to be combined into a single device to hold (for example) a single filesystem. Some RAID levels include redundancy and so can survive some degree of device failure. Linux software RAID devices are implemented through the multiple devices (MDs) device driver. The classic raidtools are the standard software RAID management tool for Linux, so using mdadm is not a must. Multiple devices admin (mdadm) is an extremely useful tool for running RAID systems. It can be used as a replacement for the raidtools, or as a supplement. The main differences between mdadm and raidtools are: - mdadm can diagnose, monitor and gather detailed information about your arrays
V5.2
Student Notebook
Uempty
- mdadm is a single centralized program and not a collection of disperse programs, so there's a common syntax for every RAID management command - mdadm can perform almost all of its functions without having a configuration file and does not use one by default - Also, if a configuration file is needed, mdadm helps with management of its contents
8-41
Student Notebook
mdadm modes
mdadm major modes of operation:
Assemble Build Create Manage Misc Follow or Monitor
Figure 8-28. mdadm modes
LX036.0
Notes: Modes of operation

When using mdadm, you will be operating in one of the following modes: Table 14: mdadm modes Mode Description Assemble the parts of a previously created array into an active array. Components can be explicitly given or can be searched for. mdadm Assemble checks that the components do form a bona fide array, and can, on request, fiddle superblock information so as to assemble a faulty array. Build Build a legacy array without per-device superblocks. Create Create a new array with per-device superblocks. This is for doing things to specific components of an array, such as Manage adding new spares and removing faulty devices.
V5.2
Student Notebook
Uempty
Table 14: mdadm modes Mode Description This mode allows operations on independent devices such as Misc examining MD superblocks, erasing old superblocks, and stopping active arrays. Monitor one or more md devices and act on any state changes. This Follow or is only meaningful for RAID 1, 4, 5, 6 or multipath arrays as only these Monitor have interesting state. RAID 0 or linear never have missing, spare, or failed drives, so there is nothing to monitor.
8-43
Student Notebook
mdadm implementation
Create # mdadm --create -v /dev/md0 -l \ linear -n 2 /dev/sda6 /dev/sda7 Manage # mdadm --detail /dev/md0 Misc # cat /proc/mdstat
Figure 8-29. mdadm implementation
LX036.0
Notes: Introduction
The following tables identify command arguments to use within the various modes of mdadm. Table 15: mdadm - create (build) mode Option Description Set RAID level. When used with --create, options are: linear, -l, --level raid0, 0, stripe, RAID1, 1, mirror, RAID4, 4, RAID5, 5, RAID6, 6, multipath, mp.
V5.2
Student Notebook
Uempty
Table 15: mdadm - create (build) mode Option Description Specify the number of active devices in the array. This, plus the number of spare devices (see below) must equal the number of component- devices (including missing devices) that are listed -n, --raid-devices on the command line. Setting a value of 1 is probably a mistake and so requires that - force be specified first. A value of 1 will then be allowed for linear, multipath, raid0 and raid1. It is never allowed for RAID4 or RAID5. Specify the number of spare (eXtra) devices in the initial array. -x, Spares can also be added and removed later. The number of --spare-devices component devices listed on the command line must equal the number of RAID devices plus the number of spare devices. Table 16: mdadm - manage mode Option Description -a, --add Hotadd listed devices. -r, --remove Remove listed devices. They must not be active. -f, --fail, Mark listed devices as faulty. --set-faulty Table 17: mdadm - misc mode Option Description -R, --run Start a partially built array. -S, --stop Deactivate array, releasing all resources.
8-45
Student Notebook
Watching a running RAID

To see the current state of your RAID view /proc/mdstat
# cat /proc/mdstat Personalities:[linear] [raid5] read_ahead 1024 sectors md0: active raid5 sda1[2] sdb1[1] sdd1[3] sde1[0] 633849 blocks level 5, 32k chunk, algorithm 2 [4/4] unused devices: <none>
[UUUU]
U means all devices are up F means a device has failed Very Important
For better understanding, use: watch

n1 d cat /proc/ mdstat
Figure 8-30. Watching a running RAID
LX036.0
Notes: Introduction
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 has failed. You should investigate this and possibly replace the device as soon as possible.
Operation
If you want to simulate a failing RAID device, you can use the command raidsetfaulty. Don't' forget, you can open a new terminal and run the following command: # watch cat /proc/mdstat
V5.2
Student Notebook
Uempty
You may also simulate a failed disk using mdadm: # # # # # mdadm mdadm mdadm mdadm mdadm --manage --set-faulty /dev/md0 /dev/sda7 /dev/md0 --remove /dev/sda7 /dev/md0 --add /dev/sda7 --stop /dev/md0 --run /dev/md0
8-47
Student Notebook
Spare disks
To make RAID1/RAID5 more failsafe in case of a disk failure, use spare disks!
# cat /etc/raidtab ... nr-spare-disks 1 device /dev/sdd1 spare-disk 0 ...
spare disk
The spare disk takes over...
Remove a failed disk with raidhotremove Add a new disk to the array with raidhotadd
Figure 8-31. Spare disks
LX036.0
Notes: Introduction
To make a RAID-1 or RAID-5 configuration more failsafe, 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.
Benefits of spare disks

You might 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.
V5.2
Student Notebook
Uempty
Array management
If a disk in a RAID array fails, you 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 takes the place of the spare disk (if you configured spare disks), and the former spare disk remains production disk.
8-49
Student Notebook
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 RAID4 and RAID5 needs a lot of CPU time Do not use RAID-linear or RAID0 for swap space
The Linux kernel can stripe across swap spaces more efficiently
Figure 8-32. Additional RAID considerations
LX036.0
Notes: Introduction
There are a few things to note when using RAID: Always put your RAID partitions on different disks, or you can 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 increases your performance and reliability.
Boot partition
With RHEL and Fedora, 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).
V5.2
Student Notebook
Uempty
Performance considerations
Software RAID4 and RAID5 need a lot of CPU time to perform the parity calculations. For maximum reliability, RAID4 and RAID5 allow 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 automatically starts 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. Do not use RAID-linear or RAID0 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 RAID1, RAID4, or RAID5 can be used to increase the reliability of your swap subsystem.
8-51
Student Notebook
Checkpoint
1. True/False: RAID volumes can be used as physical volumes in an LVM setup. Mirroring is offered by RAID level:
a. b. c. d. e. Linear Zero One Four Five
2.
3.
What command is used to create a RAM disk? ______________________________________________
LX036.0
Notes:
1. 2. 3.
V5.2
Student Notebook
Uempty
Exercise 8: Block devices, LVM, and RAID
What you will do in this exercise: Create and manipulate LVM resources Use RAM disk resources Configure RAID devices
Figure 8-34. Exercise 8: Block devices, LVM, and RAID
LX036.0
Notes:
8-53
Student Notebook
Unit summary
Having completed this unit, you should understand: 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.
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Unit 9. Filesystems
This unit teaches you what filesystems are and how to handle them.

After completing this unit, you should be able to: 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

References
Linux man pages SUSE Linux 10 Administration Guide RedHat Enterprise Linux V5 Administration Guide
World Wide Web resources:
http://learnlinux.tsf.org.za/courses/build/internals/ch08s05.html http://e2fsprogs.sourceforge.net/ext2.html http://www.atnf.csiro.au/people/rgooch/linux/docs/vfs.txt http://www.linuxgazette.com/issue55/florido.html http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/ http://www.coda.cs.cmu.edu/doc/talks/linuxvfs/ http://www.linuxplanet.com/linuxplanet/reports/4136/1/ http://www.linuxplanet.com/linuxplanet/tutorials/2926/4/

Unit 9. Filesystems
9-1
Student Notebook
http://www-106.ibm.com/developerworks/linux/library/l-fs9.html http://www.penguin.cz/~mhi/fs/Filesystems-HOWTO/Filesystems-HO WTO.html http://www.cse.unsw.edu.au/~neilb/oss/linux-commentary/vfs.html http://www.redhat.com/support/wpapers/redhat/ext3/why.html http://www.science.unitn.it/~fiorella/guidelinux/tlk/node97.html
9-2
V5.2
Student Notebook
Uempty
Unit objectives
After completing this unit, you should be able to: 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
LX036.0
Notes:

Unit 9. Filesystems
9-3
Student Notebook
What is a file?
Consecutive number of bytes
No internal structure by default (applications define their own structure)
Stored and referenced in a filesystem

Can have multiple references (names)
Special files exist

Block, Character -> Device Pipes, Sockets -> Interprocess communication
Figure 9-2. What is a file?
LX036.0
Notes: Introduction
A UNIX file is a consecutive number of bytes with no internal structure. Applications 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).
Special files
The two standard file types you will deal with under Linux are data and special files. Special files perform a variety of roles: Devices In Linux, devices can be accessed via special files. A device special file does not use any space on the filesystem. It is only an access point to the device driver. Two types of special files exist: character and block special files. The former allows I/O operations in character mode while the latter requires data to be written in block mode
V5.2
Student Notebook
Uempty
via the buffer cache functions. When an I/O request is made on a special file, it is forwarded to a (pseudo) device driver. A special file is referenced by a major number, which identifies the device type, and a minor number, which identifies the unit. Interprocess communication A pipe is a mechanism for interprocess communication; data written to the pipe by one process can be read by another process. The data is handled in a first-in, first-out (FIFO) order. The pipe has no name; it is created for one use and both ends must be inherited from the single process which created the pipe. A FIFO special file is similar to a pipe, but instead of being an anonymous, temporary connection, a FIFO has a name or names like any other file. Processes open the FIFO by name in order to communicate through it

Unit 9. Filesystems
9-5
Student Notebook
What is a filesystem?
Place to store files and refer to them Hierarchical structure through use of directories A filesystem can be stored on any block device
Floppy disk Hard disk Partition RAID, LVM volume File (for use with a loop device) RAM disk
/ /bin /dev /etc /lib /sbin /usr /var
Figure 9-3. What is a filesystem?
LX036.0
Notes: Introduction
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.
9-6
V5.2
Student Notebook
Uempty
The virtual filesystem

User Processes vi, ls, mv, rm, file, strings, cat, touch ...
System Call Interface open() read() write() close()...
VFS Abstraction Layer

ext2 reiserfs minix ext3 ...
Buffer Cache Device Drivers
I/O Request Hardware

Figure 9-4. The virtual filesystem
LX036.0
Notes: Introduction
Linux supports a large number of filesystems. All these filesystems have their own way of storing data and metadata on disk. 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 virtual filesystem switch (VFS) abstraction layer.
Process flow
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.

Unit 9. Filesystems
9-7
Student Notebook
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 always presents a default set of permissions to the user. These permissions can be set when the filesystem is mounted but cannot be changed.
9-8
V5.2
Student Notebook
Uempty
Filesystems supported
Traditional: ext2 Second generation: ext3, ReiserFS, IBM JFS, xfs FAT-12, FAT-16, FAT-32, VFAT, NTFS (read-only) CD-ROM (ISO 9660) UMSDOS (UNIX-like FS on MS-DOS) NFS (Network File System) SMBFS (Windows share), NCPFS (Novell Netware share) /proc (for kernel and process information) SHMFS (Shared Memory Filesystem)
Figure 9-5. Filesystems supported
LX036.0
Notes: Introduction
Linux supports a wealth of filesystems. Its traditional filesystem is ext2, the second extended filesystem. Today, ext2 has been replaced in most instances by second and third generation filesystems. These include ext3, ReiserFS, IBMs JFS, and XFS. All have distinct advantages over ext2. The major distributions are diverging at this level. RHEL, Fedora, and SLES10 use ext3 as the default filesystem type. Filesystems from other operating systems are also supported.

Unit 9. Filesystems
9-9
Student Notebook
Filesystem example: ext2

Partition divided into blocks of 1024, 2048 or 4096 bytes
Blocksize depends on size of filesystem and expected usage
Blocks can have different usage:

Superblock Index node (inode) block Indirect block (double, triple) Data block
ID
Figure 9-6. Filesystem example: ext2
LX036.0
Notes: Introduction
Most filesystems used on a Linux system share the same structures typical to a UNIX filesystem. When creating (formatting) the filesystem in the disk partition, the partition is split up in blocks of 1024 bytes each (default). Each block is given a specific function: - Superblock - Inode block - Indirect block - Data block Note: It is not possible to combine functions in a block.
V5.2
Student Notebook
Uempty
Superblock
First block of filesystem, several copies (at 8193, 16385, ...) Contains general info on filesystem
Last mounted time/place Block size Pointers to free inodes Pointers to free blocks Pointer to root of filesystem
ID
Figure 9-7. Superblock
LX036.0
Notes: Introduction
The first block of the filesystem (block 1) is the superblock1. It is a very important block, since it contains information about the rest of the filesystem. Copies of this data are therefore kept (approximately on block 8193, 16385, and so on). Should block 1 become corrupt, then mount attempts 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.
Block 1 is the second block in the partition. The first block of the partition, block 0, is never used for the filesystem since this block might contain a boot loader.

Unit 9. Filesystems
9-11
Student Notebook
Inodes
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 File Type File Size File Permissions Time Stamps:
create time access time modification time
Link Counter Additional Flags:

(ACL, EXT2,_FLAGS)
Pointers to Block Data
ID
Figure 9-8. Inodes
LX036.0
Notes: Introduction
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, creation time (ctime), last accessed time (atime) and last modified time (mtime). It also contains information about the data blocks where the file resides. This structure is a little complicated but very efficient.
Structure
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.
V5.2
Student Notebook
Uempty
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 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 1 K blocks are used.

Unit 9. Filesystems
9-13
Student Notebook
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 Multiple file names may point to the same inode! (Or files may have multiple names)
Inode 3694 Type: d Data: 6417 Size: 1024 User: 0 Group: 0 Directory Data 6417
Name . .. xyz abc Inode 2317 3694 8391 8391
Inode 8391 Type: f Data: 9041 Size: 21 User: 0 Group: 0 Link: 2
Data 9041 File data xyz
Regular File
ID
Figure 9-9. Data blocks
LX036.0
Notes: Introduction
The data blocks finally contain the data the end user would refer to as a file. A file might be of a special type: a directory. In this case, the data block contains the file names in that directory and the number of the corresponding inode. This leads to a very interesting concept: a file can have multiple names, even in multiple directories, as long as the directories are on the same filesystem.
V5.2
Student Notebook
Uempty
Ext2fs summary
The most important components of a filesystem are the inodes and the data blocks The filesystem is full if:
No more inodes are available No more data blocks are available
So tune your filesystem according to the number of bytes per file:

Blocksize (1024, 2048, or 4096 possible) Bytes-per-inode (4096 default)
Figure 9-10. Ext2fs summary
LX036.0
Notes: In review
It is not important to know the exact internal structure of the ext2fs filesystem. What is important to know is that there are two main 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, or 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
Unit 9. Filesystems
9-15
Student Notebook
small files, decrease this value since you will probably want one or two inodes per data block. In general, it is easier to explain to the users why a filesystem is full if there are no more data blocks left than it is to explain that a filesystem is full because you ran out of inodes. And since an inode is smaller than a data block, you should usually overestimate the number of inodes, just to be sure. The default values of mke2fs also do this.
V5.2
Student Notebook
Uempty
Other filesystem features

Filesystems can have other features that can be useful: Access Control Lists (ACL)
Allow more extended permissions, not just rwxrwxrwx Not yet supported by VFS abstraction layer
Journaling
Keeps a journal of operations that are going to take place and operations that were successfully committed Should make recovery from a crash faster Slight performance decrease
Extended file attributes

Examples: immutable, auto compression, undeletable
Labels
Allow mounting based on label instead of device name
Performance optimizations
Figure 9-11. Other filesystem features
LX036.0
Notes: Introduction
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 (ACLs): 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 possible, for instance, to define that a certain group is able to execute a program with the SUID bit set and that another group is able to execute it, but without the SUID bit. - 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.

Unit 9. Filesystems
9-17
Student Notebook
This of course leads to a performance decrease but yields one important benefit: When the system crashes, you don't have to do an fsck of the whole disk to look for inconsistencies but just need to look at the journal and retrieve all transactions that were started but not finished. Only the disk areas that were involved in those transactions need to be searched. An fsck on a crashed journaled filesystem typically only takes 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, 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 servers, 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 that 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.
V5.2
Student Notebook
Uempty
Creating a filesystem
Creating a filesystem is done with an mkfs variant
mke2fs, mke2fs -j mkreiserfs mkjfs
Typical options:
- b blocksize sets blocksize - i bytes-per-inode sets number of inodes - c checks disk for bad blocks
Example: # mke2fs -b 1024 -i 4096 -c /dev/sda6 ... Writing inode tables: done Writing superblocks and filesystem accounting info: done ...
Figure 9-12. Creating a filesystem
LX036.0
Notes: Introduction
Once we have decided which block device we are going to use, and the type of filesystem we want, we 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 3
mke2fs is used to create an ext2 filesystem. mke2fs -j creates an ext3 filesystem. 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.

Unit 9. Filesystems
9-19
Student Notebook
Mounting a filesystem
Using the mount command:
Supply device name Supply mount point (empty directory)
# mount -t ext3 /dev/sda6 /mnt/extra # mount -o nodev,noexec /dev/system/mylv /usr/local/proj1
Optional: Supply filesystem type Optional: Supply other options Optional: Use different superblock To show mounted filesystems, use mount without arguments
Figure 9-13. Mounting a filesystem
LX036.0
Notes: Introduction
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@sys2 /root]# mount /dev/sda2 on / type ext3 (rw) /dev/sda6 on /mountpoint type ext3 (rw) /dev/cdrom on /mnt/cdrom type iso9660 (ro) none on /proc type proc (rw) [root@sys2 /root]# _
V5.2
Student Notebook
Uempty
Mounting filesystems at system startup

Add to /etc/fstab:
/dev/sda1 /dev/sda5 /dev/cdrom /dev/fd0 /dev/sda6 /boot / /mnt/cdrom /mnt/floppy /mnt/extra ext3 ext3 iso9660 msdos ext3 defaults defaults noauto,ro,user noauto,user defaults 1 1 0 0 0 2 1 0 0 0
Alternative notation, using ext2/ext3 filesystem labels (used by RHEL/Fedora)

LABEL=/boot LABEL=/ /dev/cdrom /dev/fd0 LABEL=extra /boot / /mnt/cdrom /mnt/floppy /mnt/extra ext3 ext3 iso9660 msdos ext3 defaults defaults noauto,ro,user noauto,user defaults 1 1 0 0 0 2 1 0 0 0
Figure 9-14. Mounting filesystems at system startup
LX036.0
Notes:
If filesystems need to be mounted automatically at system restart or if you need to create shortcuts for fast mounting of common filesystems, add them to /etc/fstab. This file contains lines for each filesystem to be mounted. Every line consists of six fields: - The block device which contains the filesystem. Recent kernels also allow a label to be specified here, instead of the device. This is the label that is stored in the ext2/ext3 superblock. The kernel searches all ext2/ext3 filesystems for the filesystem holding this label and mounts 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

Unit 9. Filesystems
9-21
Student Notebook
RHEL/Fedora has made these modifications and uses filesystem labels by default. SLES does not support filesystem labels at all. - The mountpoint at which the filesystem needs to be mounted. - The type of the filesystem. Recent kernels also allow the auto type, which indicates that the kernel itself should try to figure out the filesystem type. This is useful for removable media, in particular floppy disks. - The options. - A dump indicator (see man fstab). - A sequence indicator for fsck (see man fstab).
V5.2
Student Notebook
Uempty
Mount options
Various options can be used when mounting a filesystem:
auto: Mount filesystem automatically when booting noauto: Do not mount fs automatically user: Users are allowed to mount this filesystem owner: Same as user but user must be owner of device ro: Read-only rw: Read-Write
For more options, see man mount
Figure 9-15. Mount options
LX036.0
Notes: Introduction
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.
Unit 9. Filesystems
9-23
Student Notebook
- 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. - 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.
V5.2
Student Notebook
Uempty
Unmounting filesystems
Filesystem may not be in use: Check with fuser Open files Programs being executed Active directories
# fuser -v /usr USER /usr root PID Kernel ACCESS COMMAND mount /usr
Use the umount command with either:

The device name The mount point Or both
# umount /dev/cdrom # umount /mnt/cdrom
Figure 9-16. Unmounting filesystems
LX036.0
Notes: Introduction
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 you can unmount all filesystems of a given type: umount -t msdos -a

Unit 9. Filesystems
9-25
Student Notebook
Checking a filesystem
Checking a filesystem is done automatically when the system boots
If a filesystem is cleanly unmounted, no further checks are done Minor errors repaired automatically Major errors drop you in a shell; allows you to do a more thorough check manually
fsck -y /dev/sda1 Can start filesystem checks manually as well with fsck
Only on filesystems that are mounted read-only or not mounted at all
Figure 9-17. Checking a filesystem
LX036.0
Notes: Introduction
It is of the utmost importance that the internal structure of a filesystem is at a consistent state at all times. The Linux kernel is designed 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. If 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.
V5.2
Student Notebook
Uempty
Implementation
Although the implementation details may change, the general behavior of all these fsck programs is always the same: - When the fsck program detects that the filesystem was unmounted cleanly, then no further checks are performed.4 - If the filesystem was not clean, the consistency will be checked. On a non-journaled filesystem, this basically means that the whole filesystem needs to be scanned, while a journaled filesystem only needs to scan the filesystem areas which are listed as possibly dirty here. - If minor errors are detected, then these are usually corrected automatically. - If major errors are detected, then the system drops you into a shell and you need to fix these errors manually. This is typically done with the fsck -y command. Filesystem checks can also be started by hand. This can only be done on filesystems that are not mounted at all, or are mounted read-only.
4 Cleanly unmounted means that the filesystem was properly unmounted. This allows the kernel first to bring the filesystem in a consistent state, where all cached write actions are actually written out. As the last action, the kernel writes the clean bit to the superblock.

Unit 9. Filesystems
9-27
Student Notebook
ext2/ext3-specific information
ext3 adds journaling to ext2 using a special, hidden .journal file of arbitrary size (recommended: 10 MB)
Thus, downwards compatible with ext2 For new ext3 filesystems, use mke2fs -j For converting ext2 to ext3, use tune2fs -j
Useful ext2/ext3 commands:

tune2fs tunes an ext2 filesystem debugfs debugs an ext2 filesystem chattr changes ext2 extended attributes of a file
Immutable Compressed Undeletable And so forth (see man chattr for details)
e2label changes filesystem label of an ext2 filesystem resize2fs can increase the size of a mounted filesystem and decrease the size of an unmounted filesystem (RHEL5) ext2online can increase the size of a mounted ext3 filesystem (SLES10)
Figure 9-18. ext2/ext3-specific information
LX036.0
Notes: ext3 filesystem management

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.
V5.2
Student Notebook
Uempty
ext3 filesystem commands

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. - 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/ext3 filesystem. Increasing size can be done on a mounted filesystem (RHEL5); decreasing size requires the filesystem to be unmounted. - ext20nline: Increase the size of a mounted ext3 filesystem. Does not decrease the size (SLES10)

Unit 9. Filesystems
9-29
Student Notebook
ReiserFS-specific information
Filesystem for Linux only, created by Hans Reiser 32 MB journal by default (minimum 2 MB)
Thus, do not use ReiserFS for small filesystems Journal may be in the filesystem itself or on a separate partition
Uses balanced trees instead of linear directory lists

Extremely useful for directories which contain 1000+ files
Useful commands:
debugreiserfs debugs a ReiserFS filesystem resize_reiserfs resizes a ReiserFS filesystem
Extending can be done on a mounted filesystem Reducing can only be done on an unmounted filesystem
reiserfsck runs a filesystem check on a ReiserFS
Due to legal issues, no longer used as the default filesystem type in modern distributions.
Figure 9-19. ReiserFS-specific information
LX036.0
Notes: Introduction
ReiserFS is a filesystem that was designed specifically for Linux by Hans Reiser. Two features stand out, compared to ext2: - Journal structure - Balanced tree design
Journal structure
ReiserFS uses a 32 MB journal by default. (Its minimum size is 513 blocks of 4 KB 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.
V5.2
Student Notebook
Uempty
Balanced tree design

ReiserFS uses its balanced trees to streamline the process of finding the files and retrieving their security (and other) metadata. For extremely small files, the entire file's data can actually be stored physically near the file's metadata so that both can be retrieved together with little or no movement of the disk seek mechanism. If an application needs to open many small files rapidly, this approach significantly improves performance.
Reiserfs filesystem commands

Some useful commands for ReiserFS are: - debugreiserfs: Debugs a ReiserFS filesystem. - resize_reiserfs: Resizes a ReiserFS filesystem. - reiserfsck: Runs a filesystem check on a ReiserFS.

Unit 9. Filesystems
9-31
Student Notebook
Comparing filesystems
Journaled Filesystems used by Linux:
ext2 ext3 yes (10 MB default) jfs yes (auto resized) yes reiser yes (32 MB default) yes xfs
Journal
no
yes
resizeable
yes, but yes, but only only when when unmounted unmounted File: 2 TB FS: 16 TB inodes (completely block oriented) File: 2 TB FS: 16 TB inodes (completely block oriented)
yes, but only when mounted File: 2 TB FS: 8 EB inodes (allocated in a b-tree)
maximum size
File: 4 PB FS: 32 PB inodes (allocated in a b-tree)
File: 16 TB FS: 1 EB
type
b-Tree
Figure 9-20. Comparing filesystems
LX036.0
Notes: Introduction
The visual shows a quick comparison of the filesystems found on various Linux distributions. 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 megabyte is 1024 kilobyte, or 220 bytes. A gigabyte is 1024 megabyte, or 230 bytes. A terabyte is 1024 gigabyte, or 240 bytes. A petabyte is 1024 terabyte, or 250 bytes. An exabyte is 1024 petabyte, or 260 bytes. A zettabyte is 1024 exabytes or 270 bytes. A yottabyte is 1024 zettabytes or 280 bytes. (That's 24 zeros!)
V5.2
Student Notebook
Uempty
SHMFS-specific information
SHMFS: POSIX compliant Shared Memory Filesystem Filesystem stored in memory, expands when used to required size Not persistent across reboot Typically mounted on /dev/shm Required by certain applications
Figure 9-21. SHMFS-specific information
LX036.0
Notes: Introduction
The last filesystem we want to cover here is the Shared Memory Filesystem (SHMFS). 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 Linux 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 some applications, such as Apache HTTP Server, Oracle, and SAP.

Unit 9. Filesystems
9-33
Student Notebook
Quota concepts
Quotas 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 Two limits per quota: Soft and hard
User exceeds soft limit User exceeds hard limit warning only error
Grace period identifies how long the soft limit may be exceeded
After that period, a user gets errors instead of warnings
20 MB 5 MB
Filesystem: 300 MB
Each user may consume only 20 MB permanently and 25 MB temporarily

Figure 9-22. Quota concepts
LX036.0
Notes: Introduction
Quotas are used to limit the amount of data a user can store on a specific filesystem. A user can have a 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 quotas, 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, the user will receive warnings that the quote limit has been exceeded, 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 or she tries to write files. Thus, by setting the soft limit and the grace limit to a reasonable value, users are able to
V5.2
Student Notebook
Uempty
exceed their soft limit for a short period of time, usually just enough to request a quota upgrade.

Unit 9. Filesystems
9-35
Student Notebook
Quota implementation on Linux

Quota support compiled into the kernel
No daemon necessary
Implemented on a per-filesystem basis

A user can have different quota on different filesystems Stored in aquota.user and aquota.groups in the root of the filesystem
Quota checking should be enabled when mounting the filesystem

Mount options: usrquota, grpquota Can be specified in /etc/fstab
Quota checking should be turned on after mounting with the quotaon command
Automatically executed from bootscript after mount -a
Figure 9-23. Quota implementation on Linux
LX036.0
Notes: Introduction
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.
Earlier implementations used the quota.user and quota.groups file. To convert the old format in the new format, use convertquota.
V5.2
Student Notebook
Uempty
Enabling quota
Modify /etc/fstab
/dev/sda2 /dev/sda4 /dev/sdb /dev/sda3 /dev/fd0 none none / /home /mnt/cdrom swap /mnt/floppy /proc /dev/pts ext3 ext3 iso9660 swap msdos proc devpts defaults defaults,usrquota,grpquota noauto,owner,ro defaults noauto,owner defaults gid=5,mode=620 1 1 0 0 0 0 0 1 2 0 0 0 0 0
Create aquota.user and aquota.group in the filesystem's root directory Remount the partition Calculate current usage and turn on quota checking
# # # # touch /home/aquota.user /home/aquota.group mount -o remount /home quotacheck /home quotaon /home
Figure 9-24. Enabling quota
LX036.0
Notes: Introduction
So how do we enable quota? The first step is to change the /etc/fstab file to indicate that a certain filesystem uses quota. Because you might 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 is 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.

Unit 9. Filesystems
9-37
Student Notebook
Configuring quota
Done with the edquota command
Starts $EDITOR (default: vi) in a subshell Only edit the block/inode soft/hard quota numbers
User quota: edquota -u username

Disk quotas for user tux1 (uid 501): Filesystem blocks soft hard /dev/sda4 10700 20000 25000 /dev/sda9 320 300 350 ~ ~ ~ "/tmp/Edp.a9fSEQK" 3L, 213C inodes 407 23 soft 0 30 hard 0 50
Group quota: edquota -g groupname Grace period: edquota -t Copy quota: edquota -p tux1 -u tux2 tux3 tux4
Figure 9-25. Configuring quota
LX036.0
Notes: Introduction
After quota checking is turned on, we can specify the quota per user or group. This is done with the edquota command. The edquota command reads the aquota.user and aquota.group files (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 reads the contents of the temporary file and merges 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 expect 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).
V5.2
Student Notebook
Uempty
A very useful feature of edquota is the copying of quota information. If you want the users tux2, tux3, and tux4 all to have the same quota limits as the user tux1, just run the command edquota -p tux1 -u tux2 tux3 tux4, and you're done.

Unit 9. Filesystems
9-39
Student Notebook
Quota information
quota command
Reports on the quota of one user Can be executed by anyone A regular user can only view his own quota
tux1$ quota Disk quotas for user tux1 (uid 501): Filesystem blocks quota limit grace /dev/sda4 10700 20000 25000
files 407
quota 0
limit 0
grace
repquota command
Reports on the quota of all users and groups Can only be executed by root
root# repquota /dev/hda4 Block limits User used soft hard root -- 848804 0 0 . tux1 ++ 1500 1000 1500 tux2 -176 1000 1500 grace File limits used soft hard 56892 0 0 112 44 112 0 115 0 grace
7days
none
Figure 9-26. Quota information
LX036.0
Notes: Introduction
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.
V5.2
Student Notebook
Uempty
Checkpoint
1.
a. b. c. d.
Assuming a blocksize of 1024, how many inodes and data blocks do you need for a file on an ext2 filesystem?
with size 0? with size 1? with size 2000? with size 12289 (12 K+1)?
2.
a. b.
What are the two methods of copying a file to a (not yet mounted) MS-DOS floppy?
__________________________________ __________________________________
3.
What files are important with respect to quotas? _____________________________________________
LX036.0
Notes:
1. a. b. c. d. 2. a. b. 3.

Unit 9. Filesystems
9-41
Student Notebook
Exercise 9: Filesystems
What you will do in this exercise: Create and manipulate filesystems Configure user quota
Figure 9-28. Exercise 9: Filesystems
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Unit summary
Having completed this unit, you should understand: A file is a is a consecutive number of bytes with no internal structure A filesystem is a reference to files, usually stored in a hierarchical system of directories and subdirectories Linux supports multiple filesystems, such as ext2/ext3 and ReiserFS, the primary filesystem types for Red Hat and SUSE Linux Filesystems are mounted either automatically via the file /etc/fstab at boot time, or manually Quota can be used to limit the amount of data a user can store on a specific filesystem
LX036.0
Notes:

Unit 9. Filesystems
9-43
Student Notebook
V5.2
Student Notebook
Uempty
Unit 10. Memory management and Xen

This unit teaches you how Linux manages its memory.

After completing this unit, you should be able to: Describe the principles of memory management in Linux Create paging space partitions Create paging space files Interpret results and reports generated by standard Linux tools Configure and manage Xen

References
Linux Kernel Development Second Edition by Robert Love, Copyright 2005 Pearson Education, Inc, 0-672-32720-1 http://www.tldp.org/HOWTO/KernelAnalysis-HOWTO.html#toc7 KernelAnalysis - HOWTO: Linux Memory Management http://www.uwsg.iu.edu/hypermail/linux/kernel/0306.3/1647. html Linux-Kernel Archive: What to expect with the 2.6 VM
10-1
Student Notebook
Unit objectives
After completing this unit, you should be able to: Describe the principles of memory management in Linux Create paging space partitions Create paging space files Interpret results and reports generated by standard Linux tools Describe Xen memory management
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Linux memory management

Total memory available for processes = real memory + paging space - kernel memory First portion of real memory is used for kernel program and kernel data: not for applications Remaining memory is used for processes Pages in real memory will be paged out to disk if necessary Unused real memory will be used for caching 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 512 TB
Figure 10-2. Linux memory management
LX036.0
Notes: Introduction
The Linux 2.6 kernel uses a virtual memory model and consumes as much physical memory as possible to improve performance. The total amount of memory for process utilization is: - process=(real memory + paging space) - kernel memory The kernel is mapped into the lower region of physical memory, with the remaining memory be utilized for processes. As memory is needed by processes, the Linux kernel uses demand paging to provide memory (swaps at the page level, not at the process level). The initial virtual memory space of a process is empty and backed by the programs binary. As pages are required or modified, the virtual memory subsystem will page in the needed data.
10-3
Student Notebook
Virtual memory model

The virtual memory subsystem of the Linux kernel provides each process its own linear virtual address space. It is comprised of equal-sized components that are referred to as virtual pages. The size of a virtual memory page is the same as a physical memory page (architecture specific). The virtual address space is divided into two regions: the user space and kernel space. Each page is assigned a page table entry (PTE) to translate a virtual address to a physical memory location. During the life of a process, virtual memory locations are mapped to a physical memory location.
Memory consumption
The Linux 2.6 kernel will consume as much physical memory as possible. It will allocate both page cache and buffers when physical memory is available to increase system performance. The page cache is used to store recently used files. If a file is needed that is currently in cache, it will increase the speed in which the data is read in (RAM versus disk). If physical memory resources are needed, the Linux kernel will decrease and eventually eliminate the use of a page cache, if needed, to free up physical memory resources. Note: This cache should not be confused with processor cache. The Linux kernel will also create disk buffers. When a process needs to write to disk, the Linux kernel will stash the data into the buffer, allowing the process to continue on without waiting for the I/O to complete. On a periodic basis, the data will be flushed to disk. Similar to page cache, buffer use will be reduced and eventually eliminated if needed to free up physical memory resources.
Intel architecture
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 referred to as i686, Intel added Processor Address Extension (PAE). This allows memory addresses of 36 bits to be used instead of 32 bits, 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.
Technical issues under Linux currently limit this to 3 GB.
V5.2
Student Notebook
Uempty
Example: Lightly loaded system
Paging space
Unused
Used for caching Real memory Used by programs Kernel memory Used by kernel
Figure 10-3. Example: Lightly loaded system
LX036.0
Notes: Introduction
On the left, the visual depicts real memory and paging space regions that are used by the kernel and programs (processes). On a lightly loaded system (right hand blocks), it is possible that all processes will fit in real memory with the kernel. In this case, there can be real physical memory left over for the kernel to use for page/disk caches. This improves the overall performance of the system, since the data is located in memory and can be accessed very quickly.
10-5
Student Notebook
Example: Heavily loaded system

Unused Paging space Used by programs Used for caching Real memory Used by programs Kernel memory Used by kernel
Figure 10-4. Example: Heavily loaded system
LX036.0
Notes: Introduction
On a heavily loaded system, less often used processes are swapped out to disk (paging space), and only the most used processes remain in real memory. The remaining real memory is 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.
V5.2
Student Notebook
Uempty
Creating paging space: Partition/LV/RAID

We need an empty partition/LV/RAID volume
Partition type 82 (Linux swap)
Create paging space in that partition # mkswap /dev/sdb1 Activate paging space # swapon p 42 /dev/sdb1 Check swap space in procfs (/proc)
# cat /proc/swaps
Filename Type Size Used /dev/mapper/VolGroup00-LogVol01 partition 1048568 160 /dev/hdb1 partition 65563 4096 Priority -1 42
Deactivating paging space is done using swapoff

Figure 10-5. Creating paging space: Partition/LV/RAID
LX036.0
Notes: Introduction
Paging space can be created either using a partition or a file. The visual shows the steps needed to use a partition as swap space. There are three steps in creating and activating paging space using a partition: First, using the fdisk command, create an empty partition with a partition ID of 82 (Linux swap). This empty partition can be created from empty disk space, LVM logical volume, or a RAID volume. Next, initialize a paging space in that partition with the mkswap command. Finally, 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.
10-7
Student Notebook
Minimum and maximum size of paging space

The minimum size of the paging space is 40 KB, and the maximum size is 2 GB (architecture dependent) 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. Note: The Linux 2.4.10 kernel and later supports the use of up to 32 swap spaces on a system.
Deactivating a paging space

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 starts to kill off random processes, so be careful with this command.
V5.2
Student Notebook
Uempty
Creating paging space: File

Create a large file to act as swap space
# dd if=/dev/zero of=/var/tmp/swapspace bs=1M count=64 # mkswap /var/tmp/swapspace
Activate paging space # swapon /var/tmp/swapspace Check swap space in procfs (/proc)
# cat /proc/swaps
Filename Type Size Used /dev/mapper/VolGroup00-LogVol01 partition 1048568 160 /swapspace file 65528 0 Priority -1 -2
Deactivate paging space using swapoff

Figure 10-6. Creating paging space: File
LX036.0
Notes: Introduction
It is possible to use a file for paging space too. This is less efficient (gives poorer performance) than paging space implemented with a partition/LV/RAID. It 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. Thus, the sequence becomes (for a 64 MB swapfile): # dd if=/dev/zero of=/var/tmp/swapspace bs=1M count=64 # mkswap /var/tmp/swapspace # swapon /var/tmp/swapspace
Deactivating a paging space

As mentioned earlier, deactivating a paging space is done by using the swapoff command.
Copyright IBM Corp. 2001, 2009 Unit 10. Memory management and Xen 10-9
Student Notebook
Useful memory-related commands/files

procinfo /proc/meminfo free top vmstat ps /proc/PID/status /proc/PID/maps
Figure 10-7. Useful memory-related commands/files
LX036.0
Notes: Introduction
There are a wide variety of commands and files that can be used or examined to determine the utilization of memory. The following will be covered during the next series of visuals: - procinfo (SLES only by default, may be downloaded and installed on RHEL/Fedora) - /proc/meminfo -free -top -vmstat -ps - /proc/<PID>/status - /proc/<PID>/maps
V5.2
Student Notebook
Uempty
procinfo command
Provides system status from information found in /proc
# procinfo
Linux 2.6.16-rc1-git3-7-default (geeko@buildhost) (gcc 4.1.0 20060123) #1 1CPU [sys2] Memory: Mem: Swap: Total 385592 1044216 Used 380532 24 Free 5060 1044192 Shared 0 Buffers 44680
Bootup: Tue Apr user : nice : system: IOwait: hw irq: sw irq: idle : uptime:
4 03:36:16 2006 0.5% 0.0% 0.1% 0.0% 0.0% 0.0% 99.3%
Load average: 0.00 0.00 0.00 1/156 20559 page in : page out: page act: page dea: page flt: swap in : swap out: context : 1599745 11273264 571729 503875 59170706 14 20 567926192 disk 1: disk 2: 106169r 1633986w 406r 0w
1:51:45.35 0:02:11.66 0:30:55.60 0:09:50.56 0:00:30.53 0:00:04.39 15d 22:26:34.03 16d 1:01:52.48
irq 0: 346506380 timer irq 1: 2106 i8042 irq 2: 0 cascade [4] irq 3: 4 irq 4: 4 irq 5: 139662 eth0 irq 6: 5 uptime: 3d 18:16:20.77
irq 7: 2 parport0 [3] irq 8: 2 rtc irq 9: 1 acpi irq 10: 0 uhci_hcd:usb1 irq 12: 17546 i8042 irq 14: 1740168 ide0 irq 15: 12419696 ide1 context : 11717465 interrupts: 1055180
Figure 10-8. procinfo command
LX036.0
Notes: Introduction
The SLES release provides the procinfo command to display system status information based on values gathered from the /proc virtual filesystem. The procinfo command can be run as a single snapshot, continuous update, or continuous update with delta values (-d option) to display the system status. In regards to overall system memory utilization, the example shown in the visual shows: - The system has ~376 MB of memory of total memory (real memory - reserved bits kernel binary) - The system is using ~371 MB of memory - There is ~4.9 MB of memory free - The system is using of ~43.6 MB of memory for buffers
10-11
Student Notebook
Operation
Looking at the example shown in the visual, the procinfo command was executed to display to current system statistics.The statistics presented are presented below: Table 18: procinfo memory statistics Statistic Description Total amount of physical memory (real memory Total reserved bits - kernel binary code) Used Total amount of allocated memory Free Total amount of free memory Shared Obsolete - Ignore Buffers Total amount of memory used for buffers page in Total number of blocks read in from disk page out Total number of blocks written to disk swap in Total number of pages read in from swap swap out Total number of pages written to swap
Command options
The procinfo command has a number of options and commands that can change how information is displayed while it is running. The command syntax for procinfo is as follows: # procinfo [ options ] [ -n seconds ] [ -f file ] Commonly used options are as follows: Table 19: procinfo commonly used options Option Function -f Run in full screen mode Display delta of statistics between samples -d rather than totals -D Display statistics totals -n seconds Delay between interval sample -f filename Output statistics to a file For complete information, check the man page.
RPM package
The procinfo command can be found in the following RPM package: - SLES - procinfo-X-X.X
V5.2
Student Notebook
Uempty
/proc/meminfo
Provides current system wide memory performance statistics
# cat /proc/meminfo MemTotal: 385592 MemFree: 5124 Buffers: 44680 Cached: 130076 SwapCached: 0 Active: 252224 Inactive: 69956 HighTotal: 0 HighFree: 0 LowTotal: 385592 LowFree: 5124 SwapTotal: 1044216 SwapFree: 1044192 Dirty: 4 Writeback: 0 Mapped: 212828 Slab: 24888 CommitLimit: 1237012 Committed_AS: 386020 PageTables: 2424 VmallocTotal: 638968 VmallocUsed: 4836 VmallocChunk: 633980 HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 4096 kB kB kB kB kB kB kB kB kB kB kB kB kB kB kB kB kB kB kB kB kB kB kB
kB
Figure 10-9. /proc/meminfo
LX036.0
Notes: Introduction
The /proc/meminfo file provides current system-wide memory performance statistics. In regards to overall system memory performance, the example shown in the visual shows: - The system has ~376 MB of memory (real memory - reserved bits - kernel binary code) - There is ~5 MB of memory free - The system has ~1 GB of swap space configured for use
10-13
Student Notebook
Operation
The example shown in the visual shows the contents of /proc/meminfo being displayed by the cat command. The following table lists the memory statistics shown in /proc/meminfo and their description. All output values are shown in KB. Table 20: /proc/meminfo memory statistics Statistic Description Total amount of physical memory (real memory - reserved bits MemTotal - kernel binary code). MemFree Total amount of free physical memory. Buffers Total amount of memory being used for buffers. Cached Total amount of memory being used for page cache. Memory that once was swapped out, is swapped back in, but still also is in the swapfile (if memory is needed, it doesn't SwapCached need to be swapped out again because it is already in the swapfile. This saves I/O). Total memory currently active (will not be swapped, unless Active absolutely necessary). Inactive Total memory currently inactive (can be swapped, if needed). Total memory allocated as high memory (ZONE_HIMEM used HighTotal for Intel architecture; PPC64 does not use high memory). HighFree Total high memory that is free. LowTotal Total memory allocated as low memory. LowFree Total low memory that is free. Total amount of swap space (swap space allocated for use; in SwapTotal this example, a partition assigned as swap 0x82). SwapFree Total amount of swap space available for use. Dirty Memory waiting to be written to disk. Writeback Memory currently being written to disk. Total amount of memory mapped into a processs virtual Mapped address space. Slab Total amount of memory assigned to slab caches. Total amount of memory allocated to processes. Linux Committed_AS overallocates memory to processes. This is the total memory if all processes utilize all of their allocated memory. Total amount of memory that is reserved for kernel page PageTables tables. VmallocTotal Total amount of memory that is usable for vmalloc. VmallocUsed Total amount of vmalloc memory used. VmallocChunk Largest contiguous chuck of memory that can be vmalloc. HugePages_Total Total number of reserved huge pages. HugePages_Free Total number of free huge pages. Hugepagesize Size of a huge page (architecture dependent; 4 MB for i386.
V5.2
Student Notebook
Uempty
free command
Provides system memory status
# free total Mem: 385592 -/+ buffers/cache: Swap: 1044216 # free -t total Mem: 385592 -/+ buffers/cache: Swap: 1044216 Total: 1429808 # free -l total Mem: 385592 Low: 385592 High: 0 -/+ buffers/cache: Swap: 1044216 used 380528 205748 24 used 380528 205748 24 380552 used 380528 380528 0 205744 24 free 5064 179844 1044192 free 5064 179844 1044192 1049256 free 5064 5064 0 179848 1044192 shared 0 buffers 44684 cached 130096
shared 0
buffers 44684
cached 130096
shared 0
buffers 44684
cached 130100
Figure 10-10. free command
LX036.0
Notes: Introduction
The free command provides a high-level view of system memory and swap resources. More detailed information can be found in /proc/meminfo. In regards to overall system memory performance, the example shown in the visual shows: - The system has ~376 MB of memory (real memory - reserved bits - kernel binary code) - The system is using ~371.6 MB of memory - There is ~4.9 MB of memory free - The system is using of ~43.6 MB of memory for buffers
10-15
Student Notebook
Operation
Looking at the example shown in the visual, the free command was executed three separate times to display current system statistics: - With no options: Displays default memory statistics - With -t: Displays the memory statistics with a total line (memory + swap) - With -l: Displays low and high watermarks for memory The statistics presented are as follows: Table 21: procinfo memory statistics Statistic Description Total amount of physical memory (real memory Total reserved bits - kernel binary code) Used Total amount of allocated memory Free Total amount of free memory Shared Obsolete - Ignore Buffers Total amount of memory used for buffers page in Total number of blocks read in from disk page out Total number of blocks written to disk swap in Total number of pages read in from swap swap out Total number of pages written to swap
Command options
The free command has a number of options and commands that can change how information is displayed while it is running. The command syntax for free is as follows: # free [-b|-k|-m|-g] [-l] [-o] [-t] [-s delay] [-c count] [-V] Commonly used options are as follows: Table 22: free commonly used options Option Function -b | -k | -m | -g Displays output in bytes, KB, MB, or GB -l Displays detailed low and high memory -o Displays old format (No -/+buffers/cache line) -t Displays total for memory + swap -s delay Updates the display every [delay] seconds -c count Updates the display [count] times For complete information, check the man page.
V5.2
Student Notebook
Uempty
RPM package
The free command can be found in the following RPM package: - SLES - procps-X-X.X - RHEL/Fedora - procps-X.X.X-X.X
10-17
Student Notebook
top command
top is a common UNIX/ Linux utility that provides comprehensive real-time performance data
top - 04:46:19 up 16 days, 1:10, 7 users, load average: 0.00, 0.00, 0.00 Tasks: 117 total, 1 running, 115 sleeping, 1 stopped, 0 zombie Cpu(s): 0.3% us, 1.0% sy, 0.0% ni, 98.7% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 385592k total, 378184k used, 7408k free, 44192k buffers Swap: 1044216k total, 24k used, 1044192k free, 127920k cached PID 20619 1 2 3 4 5 6 8 9 113 112 318 USER root root root root root root root root root root root root PR 17 16 34 RT 10 10 10 10 18 11 15 11 NI 0 0 19 0 -5 -5 -5 -5 -5 -5 0 -5 VIRT RES 2188 1032 716 288 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 SHR 776 248 0 0 0 0 0 0 0 0 0 0 S %CPU %MEM R 1.6 0.3 S 0.0 0.1 S 0.0 0.0 S 0.0 0.0 S 0.0 0.0 S 0.0 0.0 S 0.0 0.0 S 0.0 0.0 S 0.0 0.0 S 0.0 0.0 S 0.0 0.0 S 0.0 0.0 TIME+ 0:00.52 0:01.65 0:00.00 0:00.00 0:00.05 0:00.09 0:00.00 0:00.12 0:00.00 0:00.00 0:01.59 0:00.00 COMMAND top init ksoftirqd/0 watchdog/0 events/0 khelper kthread kblockd/0 kacpid aio/0 kswapd0 cqueue/0
Figure 10-11. top command
LX036.0
Notes: Introduction
The top command is a common UNIX/ Linux utility that provides a comprehensive real-time performance data view of a running system. It has the capability to display system summary information and a list of processes currently being scheduled. The display is user configurable, and can be customized to display information by: - Type - Size - Order In regards to overall system memory performance, the example shown in the visual shows: - The system has ~376 MB of memory (real memory - reserved bits - kernel binary code) - The system is using ~369 MB of memory
V5.2
Student Notebook
Uempty
- There is ~7.2 MB of memory free - The system is using of ~43 MB of memory for buffers - The process top is consuming 0.3% of memory
Operation
The default configuration of top will display system summary information followed by a list of scheduled processes. The configuration can be modified to be persistent across restarts by writing a configuration file with the W command ($HOME/.toprc)
Command options
The top command has a number of options and commands that can change how information is displayed while it is running. The command syntax for top is as follows: # top [ options ] [ -d delay ] [ -n iterations ][ -p process_id ] Commonly used options are as follows: Table 23: top commonly used options Option Function Starts top in batch mode. Useful to send output -b from top to another performance program. -d delay Delay between screen updates. The number of iterations to run before exiting -n iterations top. Monitor only processes with an effective UID or -u user user name matching that given. Monitor only processes with specified process IDs.This option can be given up to 20 times, or -pN1 -pN2 . . you can provide a comma delimited list with up to 20 PIDs. Co-mingling both approaches is permitted. Commands within top toggle settings on/off. Some useful commands are as follows: Table 24: top useful command options Key Function Sorts the display by top consumers of various system resources; A very useful to quickly identify the performance hungry tasks on a system Enters an interactive configuration screen for top; very helpful to set up top for a specific task f Note: Enter j to add the last used CPU column o Allows you to interactively select the ordering within top m Shows only running tasks For complete information, check the man page.
Student Notebook
RPM package
The top command can be found in the following RPM packages: - SLES - procps-X.X.X-X.X - RHEL/Fedora - procps-X.X.X-X.X
V5.2
Student Notebook
Uempty
vmstat command
Print report on virtual memory and CPU statistics
# vmstat 4 5
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 24 7540 44668 127956 0 0 1 8 13 7 0 0 99 0 0 0 24 7540 44696 127956 0 0 0 8 261 415 0 0 100 0 0 0 24 7540 44696 127956 0 0 0 5 261 414 0 0 100 0 0 0 24 7540 44708 127956 0 0 0 5 261 407 0 0 100 0 0 0 24 7532 44720 127956 0 0 0 5 261 413 0 0 100 0
# vmstat -a 4 5
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---r b swpd free inact active si so bi bo in cs us sy id wa 1 0 24 6980 75772 245028 0 0 1 8 13 7 0 0 99 0 0 0 24 6856 75796 245036 0 0 0 13 262 430 0 0 100 0 0 0 24 6856 75808 245088 0 0 0 29 264 425 0 0 100 0 0 0 24 6856 75840 245088 0 0 0 14 262 421 0 0 100 0 0 0 24 6732 75852 245092 0 0 0 7 261 438 0 0 100 0
Figure 10-12. vmstat command
LX036.0
Notes: Introduction
The vmstat command is designed to report statistics about processes, memory, paging, block I/O, traps, and CPU activity. When looking at system-wide CPU-related performance issues, the vmstat command can provide a high-level snapshot of what the system is doing. The vmstat command runs in either average or sample modes. If the vmstat command is issued without a delay option, vmstat will display system averages since the system was booted. If a sample delay is specified, the first line of output will show the system averages since the system was booted and, after that, it will display statistics captured during the sample delay period. In regards to overall system memory performance, the first example shown in the visual shows: - The system is not swapping memory out (0 pages)
Student Notebook
- The system has ~7.3 MB of free memory - The kernel is using ~43.6 MB of memory for buffers - The kernel is using ~124.9 MB of memory for cache The second example shown in the visual shows the use of the -a option. This option replaces the buff/cache columns with inact (inactive) and active memory columns.
Operation
Looking at the example shown in the visual, the vmstat command was executed to display to standard out with a four-second delay between sample intervals for five times. Using this method placed vmstat in interactive mode. Using vmstat in average mode displays values averaged since the system was booted: # vmstat The values related to memory activity either in interactive or average mode are as follows: Table 25: vmstat memory related data values Data Description swpd The amount of virtual memory used free The amount of free memory buff The amount of memory used as buffers cache The amount of memory used as cache si Total amount of memory swapped in so Total amount of memory swapped out active The amount of active memory inactive The amount of inactive memory
Command options
The vmstat command has a number of options and commands that can change how information is displayed while it is running. The command syntax for vmstat is as follows: # vmstat [ options ] [delay [ count ] ] Commonly used options are as follows: Table 26: vmstat commonly used options Option Function Displays active/inactive memory versus the -a default display of buffers/cache utilization Outputs a single snapshot of memory and CPU -s related statistics -m Displays slab information Number of seconds to wait between sample delay interval
V5.2
Student Notebook
Uempty
Table 26: vmstat commonly used options Option Function count Number of times to sample the system For complete information, check the man page.
RPM package
The vmstat command can be found in the following RPM packages: - SLES - procps-X.X.X-X.X - RHEL/Fedora - procps-X.X.X-X.X
10-23
Student Notebook
vmstat s command
Print single table of virtual memory and CPU statistics since the system was booted
# vmstat s 385592 total memory 379108 used memory 245156 active memory 76124 inactive memory 6484 free memory 45508 buffer memory 128312 swap cache 1044216 total swap 24 used swap 1044192 free swap 670664 non-nice user cpu ticks 13166 nice user cpu ticks . . . 1601781 pages paged in 11281804 pages paged out 14 pages swapped in 20 pages swapped out . . . 220549 forks
Figure 10-13. vmstat s command
LX036.0
Notes: Introduction
To gather a single snapshot of memory and CPU related statistics with the vmstat command, use the -s option. This option gives detailed information regarding memory and swap utilization. In the example shown in the visual, the values shown are those since the system was booted. Using the values displayed: - The system has ~376 MB of memory (real memory - reserved bits - kernel binary code) - The system is using ~370 MB of memory - There is ~6.33 MB of memory free - The kernel is using ~44.44 MB of memory for buffers
V5.2
Student Notebook
Uempty
ps command
The process status command ps generates a snapshot of process information Large number of output formatting options:
# ps L
# ps -o vsz,rss,tsiz,dsiz,majflt,minflt,cmd 15299 VSZ RSS TSIZ DSIZ MAJFLT MINFLT CMD 45396 5868 312 45083 0 757 /usr/sbin/httpd2-prefork -f /etc/apache2/ht # ps aux|sort -nr +3|grep -v USER|head -5 root 9291 0.0 11.8 70812 45700 pts/3 Sl Apr18 0:28 /usr/lib/YaST2/ bin/y2base sw_single qt --fullscreen root 3610 0.0 6.4 29116 24828 tty7 Ss+ Apr04 0:34 /usr/X11R6/bin/ X :0 -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7 root 3124 0.0 4.7 63716 18208 ? RNsl Apr04 1:09 /usr/lib/zmd/ zmd-bin /usr/lib/zmd/zmd.exe root 27576 0.0 4.5 30208 17464 ? Sl Apr15 0:11 /usr/bin/mono /usr/lib/zen-updater/ZenUpdater.exe root 4642 0.0 4.5 30292 17432 ? Sl Apr04 0:31 /usr/bin/mono /usr/lib/zen-updater/ZenUpdater.exe
Figure 10-14. ps command
LX036.0
Notes: Introduction
As we have seen so far, there are a number of tools to track system memory utilization. One tool that is useful in looking at how a process is consuming memory is the ps command. From the previous unit, we have seen how the ps command is a basic tool that can be used to report a number of statistics about running processes on the system. It reports static values, such as: Process ID Parent process ID Controlling TTY CPU Utilization Memory Utilization Accumulated CPU time Nice value Priority
Unit 10. Memory management and Xen 10-25
Student Notebook
The ps command has a number of options to define information to display and how to format the output. The command ps L will list the various fields that can be displayed. In regards to overall system memory utilization, the example shown in the visual shows the following range of data: - The first example shows the command httpd-prefork has: A virtual set size (VSS) of 45396 KB A resident set size (RSS) of 5868 KB A text size (TSIZ) of 312 KB A data size (DSIZ) of 45083 KB Created minor page faults (MINFLT, pages that can be provided from cache) totaling 757 since it began execution - The second example shows the top five consumers of memory (%MEM) running on the system. The highest consumer of memory is the /usr/lib/YaST2/bin/y2base process (PID 9291).
Operation
When using the ps command, a number of options and options styles can be utilized. The command recognizes the following format styles: - UNIX options, which may be grouped and must be preceded by a dash - BSD options, which may be grouped and must not be used with a dash - GNU long options, which are preceded by two dashes Thus, it is likely that the ps command options you have used on other operating systems such as AIX will probably work on Linux. The ps command can be used as a diagnostic tool to find processes causing performance issues or to track a specific process. When using it to locate a process causing a performance issue, the ps command can be used with options to format the display of details about a process. For example, to show all system processes with output with virtual set size, resident set size, text size, data size, major faults, and minor faults, enter the following: # ps -eo vsz,rss,tsiz,dsiz,majflt,minflt,cmd VSZ RSS TSIZ DSIZ MAJFLT MINFLT CMD 628 284 537 90 8 558 init [3] 0 0 0 0 0 0 [migration/0] 0 0 0 0 0 0 [ksoftirqd/0] 0 0 0 0 0 0 [migration/1] 0 0 0 0 0 0 [ksoftirqd/1] . . . 11320 3104 156 11163 0 4 /usr/sbin/rsct/bin/IBM.DRMd 11320 3104 156 11163 0 2 /usr/sbin/rsct/bin/IBM.DRMd 11320 3104 156 11163 0 88 /usr/sbin/rsct/bin/IBM.DRMd 1688 656 150 1537 0 54397 /sbin/iprupdate --daemon
V5.2
Student Notebook
Uempty
. . . To track a specific process ID, the ps command can be used to display data about that particular process. For example, to display output formatted data for process ID 6003, enter the following: # ps -o vsz,rss,tsiz,dsiz,majflt,minflt,cmd 6003 VSZ RSS TSIZ DSIZ MAJFLT MINFLT CMD 1704 568 274 1429 0 171 /bin/ksh ./busycpu
Command options
The ps command has a number of options and commands that can change how information is displayed while it is running. The command syntax for ps is as follows: # ps [ options ] Commonly used options are as follows: Table 27: ps commonly used options Options Function Show all processes running on the system aux (BSD) syntax Show all processes with a process tree (BSD axjf syntax) Output format control. See man page for detailed list of selectable fields, or use: -o <format> # ps L For complete information, check the man page.
RPM package
The ps command can be found in the following RPM packages: - SLES - procps-X.X.X-X.X - RHEL/Fedora - procps-X.X.X-X.X
10-27
Student Notebook
Process memory: /proc/PID/status

# cat /proc/15299/status
Each process has a subdirectory under /proc The status file provides a wide variety of information, including memory utilization statistics The statm file provides process memory usage information
Name: httpd2-prefork State: S (sleeping) SleepAVG: 88% Tgid: 15299 Pid: 15299 PPid: 1 TracerPid: 0 Uid: 0 0 0 Gid: 0 0 0 FDSize: 32 Groups: 0 VmPeak: 45396 kB VmSize: 45396 kB VmLck: 0 kB VmHWM: 5868 kB VmRSS: 5868 kB VmData: 2024 kB VmStk: 84 kB VmExe: 316 kB VmLib: 8668 kB VmPTE: 24 kB Threads: 1 SigQ: 1/3063 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000000001000 SigCgt: 000000018800466b CapInh: 0000000000000000 CapPrm: 00000000fffffeff CapEff: 00000000fffffeff
0 0
Figure 10-15. Process memory: /proc/PID/status
LX036.0
Notes: Introduction
The /proc virtual filesystems provides a view into the kernels configuration and operation. The kernel provides a directory structure under /proc for each currently running process. The directory is named after the process identification (PID) and contains details about the process. For example, the init process (PID 1) has a directory structure /proc/1. A number of files and subdirectories can be found under the PID directory structure. Some sample files are: cmdline: Contains the command that was used to start the process cwd: Contains a link to the current working directory of the process environ: Contains a list of the environment variables that the process has available exe: Contains a link to the program that is running in the process mem: Contains the memory contents of the process stat: Contains process status information statm: Contains process memory usage information
V5.2
Student Notebook
Uempty
- status: Contains process status information in a readable format - maps: Contains the mapping of the process address space that is mapped to a file
/proc/PID/status
The contents of the status file provides a wide variety of information, including memory utilization statistics. Some of the information it contains is: State: Running/sleeping Process ID Parent Process ID User ID Group ID Number of threads Virtual Memory statistics
The information related to the virtual memory statistics are as follows: Table 28: Virtual memory related data values Data Description VmSize The size of the virtual memory allocated to the process VmLck The amount of locked memory VmRSS The amount of memory mapped into physical memory VmData The size of the data segment VmStk The stack size VmExe The size of the executable segment VmLib The size of the library code Note: This information can be viewed in a more efficient manner by using tools like top or ps.
/proc/<PID>/statm
The contents of the statm file contains the status of memory in use by the process. For example, to display the contents of the init process (PID 1) statm file, enter the following: # cat /proc/1/statm 157 71 62 120 0 37 0 The seven values displayed show different memory statistics. The following table shows the value positions and their descriptions: Table 29: Memory statistics from statm file Position Description 1 Total program size (KB) 2 Size of memory portions (KB) 3 Number of pages that are shared 4 Number of pages that are code
Student Notebook
Table 29: Memory statistics from statm file Position Description 5 Number of pages of data/stack 6 Number of pages of library 7 Number of dirty pages
V5.2
Student Notebook
Uempty
Process memory: /proc/PID/maps

# cat /proc/15299/maps
80000000-8004f000 8004f000-80052000 80052000-8020b000 b554e000-b754e000 b754e000-b7583000 b7583000-b75b8000 b75b8000-b75ed000 b75ed000-b7713000 b7713000-b771c000 b771c000-b771d000 . . . b7f6c000-b7f6e000 b7f6e000-b7f6f000 b7f6f000-b7f71000 b7f71000-b7f72000 b7f72000-b7f73000 b7f73000-b7f74000 b7f74000-b7f8e000 b7f8e000-b7f90000 bf83e000-bf853000 ffffe000-fffff000 r-xp rw-p rw-p rw-s r--s r--s r--s r-xp rw-p rw-p r-xp rw-p r-xp rw-p r-xp rw-p r-xp rw-p rw-p ---p 00000000 0004e000 80052000 00000000 00000000 00000000 00000000 00000000 00126000 b771c000 00000000 00001000 00000000 00002000 00000000 00001000 00000000 00019000 bf83e000 00000000 03:06 03:06 00:00 00:07 03:06 03:06 03:06 03:06 03:06 00:00 03:06 03:06 03:06 03:06 03:06 03:06 03:06 03:06 00:00 00:00 99234 99234 0 4456453 137752 137751 137750 51630 51630 0 106457 106457 106455 106455 106454 106454 14195 14195 0 0 /usr/sbin/httpd2-prefork /usr/sbin/httpd2-prefork [heap] /SYSV00000000 (deleted) /var/run/nscd/dbAveZie (deleted) /var/run/nscd/group /var/run/nscd/passwd /usr/lib/libxml2.so.2.6.23 /usr/lib/libxml2.so.2.6.23
/usr/lib/apache2/mod_auth_basic.so /usr/lib/apache2/mod_auth_basic.so /usr/lib/apache2/mod_alias.so /usr/lib/apache2/mod_alias.so /usr/lib/apache2/mod_actions.so /usr/lib/apache2/mod_actions.so /lib/ld-2.3.90.so /lib/ld-2.3.90.so [stack] [vdso]
Figure 10-16. Process memory: /proc/PID/maps
LX036.0
Notes: Introduction
The /proc/PID/maps file contains information related to the process memory map that is mapped to a file (typically to a library). The columns from left to right contain the following information: - Address space associated with mapping - Permissions of the memory region r: Read w: Write x: Execute s: Shared p: Private - Offset from the beginning of the file where the mapping starts - The device where the mapped file is located (major/minor device number) - The inode number of the file
Student Notebook
- The file that the region is mapped to From the example on the visual, the memory region b75b8000-b75ed000: Has permissions of read and shared Has a zero offset into the mapped file The mapped file is located on major/minor device number 03:06 The inode of the mapped file is 137750 The mapped file is /var/run/nscd/passwd
V5.2
Student Notebook
Uempty
Xen overview
Originally a research project from the University of Cambridge, now developed by XenSource Open Source (licensed under GPL) Included in many new Linux distributions Current version (v3.1) released in May 2007. Citrix acquired XenSource in 2007.
Figure 10-17. Xen overview
LX036.0
Notes: Introduction
Xen is an open source software project that provides high-performance resource-managed virtualization on the x86 processor architecture. It allows multiple operating system instances to run concurrently on a single physical computer. Xen manages the computer's hardware resources so they are shared effectively among the operating system instances, called domains.
Open means open software Xen has grown dramatically over the past few years. With the release of v3.1 in May 2007 and the wide acceptance by key Linux distributors such as Novell and Red Hat, Xen is becoming a player in the arena of Enterprise Linux. Because it is an open source product, the cost factor becomes important as well. In late 2007, XenSource was acquired by Citrix.
Student Notebook
Xen installation
May not be installed by default, but included on CD/DVD Most distributions will install all packages through a common bundle or component group Main components:
xend daemon Xen-enabled kernel Xen utilities Virtual Machine Manager (GUI)
Figure 10-18. Xen installation
LX036.0
Notes:
The Xen packages are typically included in most modern distributions but not automatically installed. Many distributions include a bundle or component group that eases the installation. The components of Xen are: The Xen hypervisor The Xen-enabled kernel Command line utilities Virtual Machine Manager (GUI interface to Xen)
Once the installation of the packages is complete, the system needs to be rebooted and the Xen kernel selected from the boot loader.
V5.2
Student Notebook
Uempty
Booting the Xen kernel

Select the Xen kernel from the bootloader menu Watch for the extra (XEN): messages on bootup
Allocating processor and memory resources Setting up bridged network adapters
Kernel becomes Domain0 (hypervisor)
Figure 10-19. Booting the Xen kernel
LX036.0
Notes:
On reboot, select the new Xen kernel from the bootloader menu (GRUB or LILO). As the kernel is initializing, an all new set of messages will appear. They will be prefixed with (XEN:) and describe Xen detecting CPU and memory, as well as reconfiguring the network adapters.
10-35
Student Notebook
Xen domain configuration file

Located in /etc/xen/vm directory Common values to edit (minimum)
kernel: Path to the Xen enabled kernel memory: Domain's memory in MB disk: Which partitions in domain map to which device dhcp: use DHCP to obtain network information
Figure 10-20. Xen domain configuration file
LX036.0
Notes:
Guest domains must have a Xen configuration file created so Xen knows how to boot them. These files are all stored in the /etc/xen/vm subdirectory.
Administrators may adjust the values as necessary to reflect their own system and network configuration. Details can be obtained from the Xen User Manual.
V5.2
Student Notebook
Uempty
Example Xen configuration file
# cat /etc/xen/vm/vm_1 disk = [ 'file:/var/lib/xen/images/vm_1/hda/hda/w', 'file:/ar/lib/xen/images/vm_1/hdb,hdb,w' ] memory = 128 vcpus 1 builder = 'linux' kernel = '/tmp/YaST2-056760d5EBnL/vmlinuz-2.6.26.21-0.8-xen' ramdisk = '/tmp/YaST2-05676-d5EBnL/inst-initrd' name='vm_1' ip = '10.0.0.1' netmask = '255.255.255.0' gateway = '10.0.0.100' interface = 'eth0'
Figure 10-21. Example Xen configuration file
LX036.0
Notes:
A sample configuration file is shown in the visual above. It can be manually edited to reflect specific system and network configuration.
10-37
Student Notebook
Booting a guest domain

Done with the xm command
# xm create vm1_dev
Automatically open console when starting guest

# xm create -c vm1_dev
Domains may be autostarted on OS boot

Create symlink in /etc/xen/auto to point to your configuration file
Figure 10-22. Booting a guest domain
LX036.0
Notes:
Guest Domain boot operation The visual above shows an example of using the xm command to create a domain called vm_dev). If the configuration file /etc/xen/vm/vm1_dev exists and contains valid information, this domain will be created.
Automating the start of domains The directory tree /etc/xen/auto contains entries for automatically starting a domain at boot time. If you want the domain in our previous example to start automatically, issue the following command:
# /bin/ln -s /etc/xen/vm/vm1_dev /etc/xen/auto
V5.2
Student Notebook
Uempty
Xen domain management (1 of 2)

Done with the xend node control daemon Written in Python Automatically started when dom0 is booted Can be started on the command line
# xend start | stop | restart | status
SLES10, RHEL5, and Fedora include SysV init scripts for xend
Figure 10-23. Xen domain management (1 of 2)
LX036.0
Notes:
Xen management is accomplished by daemon and by command line. These tools can be accessed via command line and GUI management. The xen daemon (xend) performs system management functions related to virtual machines. It forms a central point of control for a machine and can be controlled using an HTTP-based protocol. Xend must be running in order to start and manage virtual machines. It is necessary for Xend to run as root because it needs access to privileged system management functions.
Xend logs events to /var/log/xend.log and /var/log/xend-debug.log
10-39
Student Notebook
Xen domain management (2 of 2)

Primary tool is xm command Common sub-commands
create: Create a domain destroy: Remove a domain list: Display all known domains and states save: Save state and config of a domain restore: Restore domain
Figure 10-24. Xen domain management (2 of 2)
LX036.0
Notes:
xm command The xm command is the primary tool for managing Xen from the console. The general format of an xm command line is:
# xm command [switches] [arguments] [variables] The available switches and arguments are dependent on the command chosen. The variables may be set using declarations of the form variable=value, and command line declarations override any of the values in the configuration file being used, including the standard variables described above and any custom variables.
V5.2
Student Notebook
Uempty
File system management

There are four methods of exporting storage to guests as a virtual block device (VBD)
Physical device: File-backed VBD: LVM-backed VBD: NFS-backed VBD: Raw partition on disk Image file Use LVM logical volumes Use NFS mounted volumes
Figure 10-25. File system management
LX036.0
Notes:
Storage can be made available to virtual machines in a number of different ways. The most straightforward method is to export a physical block device (a hard drive or partition) from dom0 directly to the guest domain as a virtual block device (VBD).
Storage may also be exported from a filesystem image or a partitioned filesystem image as a file-backed VBD. If you are using an LVM structure, you can utilize a logical volume. Finally, standard network storage protocols such as NBD, iSCSI, NFS, and so on, can be used to provide storage to virtual devices.
10-41
Student Notebook
Networking in Xen
Xen creates seven pairs of connected virtual Ethernet interfaces
veth0 vif0 ... veth6 vif0.6
Can be used by configuring veth0 with an IP and attaching vif0.# to a bridge Each domain instance is assigned a new number For each domain, Xen creates a new pair of connected virtual Ethernet interfaces.
Figure 10-26. Networking in Xen
LX036.0
Notes:
Xen creates, by default, seven pairs of connected virtual Ethernet interfaces for use by domain 0 (dom0). Think of them as two Ethernet interfaces connected by an internal crossover cable. veth0 is connected to vif0.0, veth1 is connected to vif0.1, and so on. You can use them by configuring IP and MAC addresses on the veth# end, then attaching the vif0.# end to a bridge.
Additional domains For each new domain, Xen creates new connected virtual Ethernet interfaces, with one end of each pair existing within the domain and the other end existing within domain 0 (the hypervisor). For Linux-based domains, the device name it sees is named eth0.
V5.2
Student Notebook
Uempty
Virtual Machine Manager

Graphical management utility for Xen Developed by Red Hat
Figure 10-27. Virtual Machine Manager
LX036.0
Notes:
Both SuSE and Red Hat include the Virtual Machine Manager utility. It is a graphical program designed to make management and creation of your domains easier.
10-43
Student Notebook
Checkpoint
1. Which file in /proc shows current system-wide memory performance statistics?
_______________________________
2.
List two commands that provide system memory status:

_______________________________ _______________________________
3.
What is the difference between a paging partition and a paging file? Which is more efficient? ______________________________________________ What does the Xen Virtual Memory Manager do? ______________________________________________
4.
LX036.0
Notes:
1. 2. 3. 4.
V5.2
Student Notebook
Uempty
Exercise 10: Memory management and Xen
What you will do in this exercise: Perform various memory management activities
Figure 10-29. Exercise 10: Memory management
LX036.0
Notes:
10-45
Student Notebook
Unit summary
Having completed this unit, you should understand: Linux 2.6 kernel uses a virtual memory model Linux 2.6 kernel uses a page cache to store recently used files The Linux 2.6 kernel swaps at the page level to either a partition (0x82) or a specially formatted file. There are several Linux tools and /proc entries that can be utilized to extract system and process specific memory statistics:
procinfo, /proc/meminfo, free, top, vmstat, ps, /proc/<PID>/status, /proc/<PID>/statm, /proc/<PID>/maps
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Unit 11. Scheduling

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

After completing this unit, you should be able to: 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

References
Linux man pages SUSE Linux 10 Administration Guide RedHat Enterprise Linux V5 Administration Guide

Unit 11. Scheduling
11-1
Student Notebook
Unit objectives
After completing this unit, you should be able to: 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
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Scheduling
Scheduling automates routine tasks Scheduling allows you to run commands at a specific moment in the future The crond daemon performs the scheduling for the crontab files The anacron command performs the execution of anacron jobs The atd daemon is responsible for execution of jobs submitted by the at and batch command
Figure 11-2. Scheduling
LX036.0
Notes: Introduction
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.

Unit 11. Scheduling
11-3
Student Notebook
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 (RHEL/Fedora) In /var/spool/cron/tabs (SLES)
A crontab entry has the following syntax:

[minute] [hour] [day] [month] [weekday] [command]
To regulate the use of crontab, list the users involved in one of the following files:
/etc/cron.allow (strongest) and /etc/cron.deny (RHEL/Fedora) /var/spool/cron/allow and /var/spool/cron/deny (SLES)
Figure 11-3. Cron
LX036.0
Notes: Introduction
cron was originally invented by Paul Vixie (it is sometimes called Vixie Cron for this reason). 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
V5.2
Student Notebook
Uempty
Crontab operations
Being able to schedule tasks is really useful for recurring tasks that you dont 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. However, 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.
Crontab control files

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 SLES 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 neither 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.

Unit 11. Scheduling
11-5
Student Notebook
User crontab example

0 0,30 0,30 */5 12 49 0 1 8 9 8-18 * 13 23 15 1 * * * * 1 16 * 1 * * * * * 9 * 1 * * * * * * 1 1 Once_a_day Twice_a_day Twenty_Two_times_a_day Every_five_minutes Once_a_month Once_a_year Every_monday ??? (caveat!)
Minute
Hour
Day Month Weekday Command

Figure 11-4. User crontab example
LX036.0
Notes: Introduction
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 a.m., every day.
V5.2
Student Notebook
Uempty
Weekday operations
All other entries work exactly the same, except for the last example. On a first glance, the last example would only seem to be executed on January 1st, if January 1st is a Monday. Thus, on average, it would be executed only once every 5 or 6 years. Obviously, this would be ridiculous 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. Thus, the last entry actually means every Monday and January 1st.

Unit 11. Scheduling
11-7
Student Notebook
crontab command
A regular user cannot edit his own crontab file directly crontab command runs SUID root so that it can edit the users crontab file Three usage methods:
crontab -l crontab -r crontab -e List your crontab file Remove your crontab file Edit your crontab file using $EDITOR
# crontab -e 30 12 * 1-12 1-5 echo "Having lunch." | /usr/bin/wall ~ ~ ~ "/tmp/crontab.2989" 1L, 45C 0,0-1
Figure 11-5. crontab command
LX036.0
Notes: Introduction
All user crontab files are stored in /var/spool/cron and cannot be edited by 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.
V5.2
Student Notebook
Uempty
System crontab file

A system wide crontab file is used to automate system tasks: /etc/crontab Slightly different syntax: [Time] [UID] [Command]
SHELL=/bin/sh PATH=/usr/bin:/usr/sbin/:/sbin/:/bin:/usr/lib/news/bin MAILTO=root */15 * * * * root /usr/lib/crons/run-crons 59 * * * * root run-parts /etc/cron.hourly 14 0 * * * root run-parts /etc/cron.daily 29 0 * * 6 root run-parts /etc/cron.weekly 44 0 1 * * root run-parts /etc/cron.monthly
Figure 11-6. System crontab file
LX036.0
Notes: Introduction
The crontab files in /var/spool/cron are used to run tasks on behalf of users. However, there are also a number of tasks that need to be run on behalf of the system administrator. For a variety of reasons which are not discussed 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 are 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 runs2
1 2
Actually, quite a few UNIX systems still do this. With a user crontab, the environment variables are set using the .bash_profile and .bashrc scripts in the users home directory.

Unit 11. Scheduling
11-9
Student Notebook
anacron (RHEL/Fedora)
Most crontab jobs typically run at night But... most workstations are switched off at night! The solution: anacron
Runs commands periodically
At night if the system is on At startup to catch up on any missed jobs

Jobs specified in /etc/anacrontab Anacron is called by the boot scripts and by cron Job execution information stored in /var/spool/anacron
Figure 11-7. anacron (RHEL/Fedora)
LX036.0
Notes: Introduction
anacron is a recent addition to Linux. It was 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. However, note that anacron 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
V5.2
Student Notebook
Uempty
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.
SLES 10 and anacron

Currently, SLES does not support anacron. 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.

Unit 11. Scheduling
11-11
Student Notebook
/etc/anacrontab (RHEL/Fedora)
Example:
SHELL=/bin/sh PATH=/usr/sbin:/usr/bin:/sbin:/bin 1 7 30 6 70 75 cron.daily cron.weekly cron.monthly run-parts /etc/cron.daily run-parts /etc/cron.weekly run-parts /etc/cron.monthly
Syntax:
[period] [delay] [identifier] [job] Period is number of days after which a job should run Delay is number of minutes to wait before starting a job Identifier is used to uniquely identify a job Job can be any shell command
Figure 11-8. /etc/anacrontab (RHEL/Fedora)
LX036.0
Notes: Introduction
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.
V5.2
Student Notebook
Uempty
at command
Runs a command once in the future # at 4am ps aux ^d (CTRL+D) # at -f bshfile 16:00 + 3 days # echo "mail -s report < rep.txt boss" | \ at now +2min
Figure 11-9. at command
LX036.0
Notes: Introduction
The at command can be used to run a command once in the future. It creates a script in the /var/spool/at (RHEL) or /var/spool/atjobs (SLES) 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 # at 6pm # at 16 # at 16:00 # at 5pm + 4 days
Run the at job at the next 4 a.m. Run the at job at the next 6 p.m. Run the at job at the next 1600 hours (4 p.m.) Run the at job at the next 1600 hours (4 p.m.) run the at job at 5am over 4 days.
Unit 11. Scheduling 11-13
Student Notebook
Run the at job tomorrow at 4 a.m. Run the commands in commandfile at 7 # at -f commandfile 19 p.m. Run the commands in commandfile at 7 # at 19 < commandfile p.m. The output of the commands run by atd will be mailed to you if you didn't specify output redirection. # at 4 tomorrow
V5.2
Student Notebook
Uempty
batch command
Runs a command when the system load is low enough. A command is run when the average workload is below 0.8
Workload: Number of processes waiting for CPU time
$ batch echo workload is low enough <ctrl-d>
Figure 11-10. batch command
LX036.0
Notes: Introduction
When you start a command, this command gets 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 also mean that the overall performance of the machine degrades. The batch command gives you a means of entering a command which affects 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.

Unit 11. Scheduling
11-15
Student Notebook
Controlling at jobs
To control at jobs, use the at command
# at -l 93 2003-05-24 04:15 a tux1 94 2003-12-14 15:47 a tux1 # at -d 93 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
Figure 11-11. Controlling at Jobs
LX036.0
Notes: Introduction
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.
V5.2
Student Notebook
Uempty
Checkpoint
1. 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. b. c. cron anacron at
2.
3.
How do you regulate the use of the crond and atd daemons? ______________________________________________
LX036.0
Notes:
1. 2. 3.

Unit 11. Scheduling
11-17
Student Notebook
Exercise 11: Scheduling
What you will do in this exercise: Use commands and daemons that make up scheduling on Linux Start and stop jobs through scheduling
Figure 11-13. Exercise 11: Scheduling
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Unit summary
Having completed this unit, you should understand: Scheduling is used to execute tasks in the future
cron and anacron jobs are executed repetitively at and batch jobs are run once
cron jobs are run by the crond daemon anacron jobs are run by the anacron program, which is called when the system starts up and periodically by crond
anacron is not supported on SLES
at jobs are initiated by the atd daemon batch jobs are executed by the atd daemon
LX036.0
Notes:

Unit 11. Scheduling
11-19
Student Notebook
V5.2
Student Notebook
Uempty
Unit 12. Backup and restore

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

After completing this unit, you should be able to: Discuss backup strategies Discuss backup media List the different backup tools supported in Linux

References
Linux man pages SUSE Linux 10 Administration Guide RedHat Enterprise Linux V5 Administration Guide World Wide Web resources: http://www-106.ibm.com/developerworks/library/l-fs.html http://www.suse.de/~nashif/autoinstall/linuxrc.html http://www.linuxplanet.com/linuxplanet/reports/4294/5/ http://kmself.home.netcom.com/Linux/FAQs/backups.html http://surf.ap.seikei.ac.jp/~nakano/dump-restore/
12-1
Student Notebook
V5.2
Student Notebook
Uempty
Unit objectives
After completing this unit, you should be able to: Discuss backup strategies Discuss backup media List the different backup tools supported in Linux
LX036.0
Notes:
12-3
Student Notebook
Backup schemes
Full backup
Preserves the whole system
System backup
Preserves system directories and files Must include backup/restore tools Usually on bootable media (floppy, optical)
Data backup
Preserves user data
Incremental or differential backup

Only backup files that changed Very fast, but takes more time to restore Must be used carefully Needs more media
Figure 12-2. Backup schemes
LX036.0
Notes: Introduction
There is a story, an urban legend, that warns of the perils of not backing up your system. One such version goes as follows:
Customer: My system just crashed, and I need to get the data off it. Tech support: What does it say on page 1 of the manual? Customer (reading): If you do not have a good backup, you will be sorry. Tech support: Do you have a good backup? Customer: No Tech support: Are you sorry? Customer: Yes! Tech support: Well then, the system works as documented!
While we cant vouch for the authenticity of this story, variations on the theme have undoubtedly played out over the entire history of electronic computing. While each of you are probably aware of the importance of backing up data on your system, we will focus our discussion on how Linux handles the backup process.
V5.2
Student Notebook
Uempty
Why backup?
Whether it is to protect important data, meet legal requirements, or to rebuild a system, we all need to back up our systems. There are many methods available, and each has benefits. 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 off. 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.
12-5
Student Notebook
Incremental versus differential backup

Day 1 Day 2 Day 3 Day 4
Full
L1
L2
L3
Incremental backup
Full
L1
L1
L1
Differential backup
Figure 12-3. Incremental versus differential backup
LX036.0
Notes: Introduction
The visual demonstrates 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 or 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, dump does an incremental backup against the previous-but-last backup.
V5.2
Student Notebook
Uempty
Sample monthly backup scheme

Su Mo Tue We Thu 1 Level 0 3 4 Level 2 10 11 Level 2 17 18 Level 2 24 25 Level 2 31 5 Level 3 12 Level 3 19 Level 3 26 Level 3 6 Level 4 13 Level 4 20 Level 4 27 Level 4 7 Level 5 14 Level 5 21 Level 5 28 Level 5 8 Level 1 15 Level 1 22 Level 1 29 Level 0 30 23 16 9 Fr 2 Sa
Figure 12-4. Sample monthly backup scheme
LX036.0
Notes: Introduction
The visual shows a backup scheme for a full month, using the schedule of the previous visual.
12-7
Student Notebook
Backup devices
Tape drive
Large capacity, fast Requires new tapes regularly
CD-R, CD-RW, DVD

Cheap but relatively slow
(Removable) Hard disk

Fast but expensive
Diskette drive
Often available but cumbersome for large backups
Network
Useful in large installations; usually requires commercial software (for instance, Tivoli Storage Manager)
Figure 12-5. Backup devices
LX036.0
Notes: Introduction
Various devices and media can be used to perform backups. This visual describes some of the devices you might use in backing up your system. Table 30: Backup methods Method Description 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 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.
V5.2
Student Notebook
Uempty
Table 30: Backup methods Method Description 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 slow, and that it is currently hard to predict how long the Optical drives 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 Fixed disk taken away from the computer, which doesn't help you if your computer burns down or is stolen. 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 Floppy disk read just about anywhere since it is the only removable media which is often available by default in almost any computer (though many PCs today do not include a diskette drive). Backing up over the network is a good idea in large installations. In such environments, however, the backup strategy usually becomes complex Network enough to warrant the usage of commercial backup solutions such as Tivoli Storage Manager (TSM).
12-9
Student Notebook
Default backup tools

tar
Backs up individual files Widely available Excellent for transferring data between platforms
cpio
Backs up individual files Widely available Difficulties with many symbolic links
dump
Backs up whole filesystems Can handle incremental backups (nine levels)
dd
Useful for making bit-for-bit dumps of disks and filesystems
Figure 12-6. Default backup tools
LX036.0
Notes: Introduction
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 nine 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.
V5.2
Student Notebook
Uempty
tar command
Traditional UNIX tape archive command Backup with tar: # tar -cvf home.tar /home Restore with tar: # tar -xvf home.tar [ files to extract ] List contents of a tar backup: # tar -tvf home.tar
Figure 12-7. tar command
LX036.0
Notes: Introduction
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.
Usage
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
Copyright IBM Corp. 2001, 2009 Unit 12. Backup and restore 12-11
Student Notebook
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 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 t extract files from an archive list files in an archive
V5.2
Student Notebook
Uempty
GNU tar
The GNU version of tar has a lot of improvements: Compression: use z option (gzip) or j option (bzip2) # tar -zcvf home.tar.gz /home # tar -jcvf home.tar.bz2 /home To include absolute pathnames, use P option: # tar -Pcvf home.tar /home To make a multivolume backup, use M option: # tar -cvMf /dev/fd0 1440 /home
Figure 12-8. GNU tar
LX036.0
Notes: Introduction
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.
Copyright IBM Corp. 2001, 2009 Unit 12. Backup and restore 12-13
Student Notebook
cpio command
Common UNIX backup command Backup with cpio: # cpio -ov <files> > device # find /home | cpio -ov > /dev/fd0 Restore with cpio: # cpio -iv[-dum] [files] < device # cpio -ivdum "/home/j*" < /dev/fd0 List contents of a cpio backup: # cpio -itv < device # cpio -itv < /dev/fd0
Figure 12-9. cpio command
LX036.0
Notes: Introduction
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.
V5.2
Student Notebook
Uempty
dump command
To backup a complete filesystem, use the dump command Can handle incremental backups up to nine levels
Information is stored in /etc/dumpdates
# dump -0 -u -a -f /backupdir/home.dump /home # dump -1 -u -f backup@remhost:/tux.dump / To restore a dumped filesystem: # cd /home # restore -xvf /backupdir/home.dump ... set owner/mode for .? [y/n] The -a option is used to determine the size of the backup medium
Figure 12-10. dump command
LX036.0
Notes: Introduction
dump is a backup tool which can back up whole filesystems. It correctly handles symbolic links and special device files, and it can handle incremental backups up to nine 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.
12-15
Student Notebook
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:
# dd if=/dev/sda of=/mnt/nfs/sda.img bs=1M # dd if=/mnt/nfs/sda.img of=/dev/sdc bs=1M
To make a backup of your MBR:

# dd if=/dev/sda of=/mnt/nfs/mbr.img bs=512 count=1
To trash your system thoroughly:

# dd if=/dev/zero of=/dev/sda bs=1M # dd if=/dev/urandom of=/dev/sda bs=1M
Figure 12-11. dd command
LX036.0
Notes: Introduction
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.
V5.2
Student Notebook
Uempty
Other backup tools

Taper: http://taper.sourceforge.net BRU Desktop: http://www.tolisgroup.com Lone-Tar: http://www.cactus.com Arkeia Software: http://www.arkeia.com AMANDA: http://www.amanda.org IBM/Tivoli Storage Management products:
IBM TotalStorage Productivity Center Tivoli Storage Manager Tivoli Storage Manager Express (And many more. Refer to http://www.ibm.com/software/tivoli)
Figure 12-12. Other backup tools
LX036.0
Notes: Introduction
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. Note: This visual is not intended as an endorsement of these products. Always research any tool you might consider using, especially for something as critical as backing up your system!
12-17
Student Notebook
Checkpoint
1.
a. b.
What is the difference between A and B?

find /home/francis -print cpio -ov >/dev/rmt0 find . -print cpio -ov >/dev/rmt0
2.
______________________________________________ Which one of the following commands supports multilevel incremental backups?
a. b. c. tar dump cpio
3. 4. 5.
True / False: An incremental backup will always back up the operating system files. True / False: It is not necessary to use the dash (-) with the option in the tar command. When did you last back up your files? ______________________________________________
LX036.0
Notes:
1. 2. 3. 4. 5.
V5.2
Student Notebook
Uempty
Exercise 12: Backup and restore
What you will do in this exercise: Utilize system tools such as tar, cpio, and dd to back up data
Figure 12-14. Exercise 12: Backup and restore
LX036.0
Notes:
12-19
Student Notebook
Unit summary
Having completed this unit, you should understand: In order to perform successful backups, consider the:
Frequency Media to be used Backup schedule Backup procedure Restore procedure Type of backup
Backups can be initiated on a single file or on an entire file system. There are many backup tools which can be used.
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Unit 13. User administration

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

After completing this unit, you should be able to: Add, change, and delete user accounts Add, change, and delete groups Manage user passwords Communicate with the user community

Accountability: Checkpoint questions Lab exercises
References
Linux man pages SUSE Linux 10 Administration Guide RedHat Enterprise Linux V4 Administration Guide Essential System Administration by AEleen Frisch, Copyright 1995 OReilly & Associates, Inc. 1-56592-127-5
13-1
Student Notebook
Unit objectives
After completing this unit, you should be able to: Add, change, and delete user accounts Add, change, and delete groups Manage user passwords Communicate with the user community
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Security concepts
User Accounts
Groups
Unique name Unique ID Password File ownership is determined by user ID
Unique name Unique ID Users who need access to the same files
Figure 13-2. Security concepts
LX036.0
Notes: Introduction
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.
13-3
Student Notebook
User hierarchy
root
Super user File permissions do not apply for root Can do anything except the obvious Account for the system administrator
bin, daemon, lp, sync, news, ftp ...

User accounts used by different applications and daemons Cannot (and should not) be used to log in
Ordinary user accounts
Figure 13-3. User hierarchy
LX036.0
Notes: Introduction
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 or she 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.
Special user accounts

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.
V5.2
Student Notebook
Uempty Table 31: Common system users User Description Used to execute system server processes. This user only exists to daemon own these processes (and associated files) and to guarantee that they execute with appropriate file access permissions. bin Owns the executable files for most user commands. sys Owns system files. adm Owns accounting files news Pseudo-user for news service. lpd Pseudo-user for print subsystem. mail Pseudo-user for mail service. cron Pseudo-user for job scheduler. auth Pseudo-user associated with system audit facility. nobody Used by NFS server.
Standard users
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.
13-5
Student Notebook
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
Figure 13-4. Groups
LX036.0
Notes: Introduction
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.
Group definitions
User groups User groups should be made for people who need to share files on the system, such as people who work in the same department or people who work on the same project. System-defined groups The system-defined groups are used to control certain subsystems.
V5.2
Student Notebook
Uempty
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.
13-7
Student Notebook
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, ...)
RHEL/Fedora uses User Private Groups, SLES does not
Group john
Figure 13-5. User private groups
Group mary
Group users
LX036.0
Notes: Introduction
In the previous visual weve 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. However, some distributions, including RHEL/Fedora, have introduced something called User Private Groups.
Group scheme
With this scheme, a group is created for each and every user account. This account is made a 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
V5.2
Student Notebook
Uempty
boss directory): Simply make the secretary member of the boss group. With the traditional scheme, still used by SLES, this is virtually impossible. Also, 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.
13-9
Student Notebook
Shadow password suite

Local users and groups secret information (passwords, ...) are managed by the shadow password suite
User and group database
/etc/{passwd,group}
Utilities useradd usermod userdel groupadd chage chfn passwd ...
Configuration file
User and group database secret entries
/etc/login.defs
/etc/{shadow,gshadow}
Figure 13-6. Shadow password suite
LX036.0
Notes: Introduction
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.
Security concerns
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 todays 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.
V5.2
Student Notebook
Uempty
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 cant get access to them, except for a few carefully written SUID programs that are part of the shadow password suite. 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.
13-11
Student Notebook
Command line user tools

Add a user account # useradd -m -g staff -G audio,uucp tux20 # passwd tux20 Delete a user account # userdel -r tux20 Change a user account # usermod -g users -G video tux20 Locking and unlocking a user account # usermod -L tux20 # usermod -U tux20
Figure 13-7. Command line user tools
LX036.0
Notes: adduser or useradd

The adduser and useradd commands 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: Removes users from your system. The -r option also removes the contents of the user's home directory and the directory itself. usermod: Changes 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.
V5.2
Student Notebook
Uempty
/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 useradd -m -k allows you to specify a different skeleton directory # useradd -m tux25 # useradd -m -k /etc/my_own_skel tux30
Figure 13-8. /etc/skel
LX036.0
Notes: Introduction
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.
13-13
Student Notebook
Command line group tools

Add, delete, or change groups
# groupadd penguins # groupmod -n oldname newname # groupdel penguins
Add or delete users to/from groups

# usermod -G penguins tux1 tux2 # gpasswd -a tux1 penguins
Defer administration of a group to a user

# gpasswd -A linus penguins linus$ gpasswd -a tux1 penguin linus$ gpasswd -d tux2 penguin
Figure 13-9. Command line group tools
LX036.0
Notes: Introduction
You could also use the command tools to manage your groups. An interesting feature of 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. Remember, the user accounts themselves still need to be created by the superuser.
V5.2
Student Notebook
Uempty
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 tux30 New password: ... # mkpasswd tux30 VjOmnoYXyPP4U # chage -l tux30 Minimum: 14 Maximum: 186 Warning: 21 Inactive: 7 ...
Figure 13-10. Passwords
LX036.0
Notes: Introduction
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 RHEL/Fedora system, it is part of the expect RPM, while on a SLES system, it is part of the whois RPM. Another useful tool is chage. This allows you to view and change the password aging information.
13-15
Student Notebook
/etc/passwd
The /etc/passwd file contains non-secret information about the users
# cat /etc/passwd root: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) User name 2) Password (x means encrypted password available) 3) UID 4) GID 5) GECOS (user information) 6) Home directory 7) Login shell
Figure 13-11. /etc/passwd
LX036.0
Notes: Introduction
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: 1. 2. 3. 4. 5. The user name. 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. 6. The home directory of the user. 7. The preferred shell of the user. This file is world readable, meaning that everyone can read (but not write) to this file.
V5.2
Student Notebook
Uempty
/etc/shadow
Credentials of any user account are stored in the /etc/shadow file
# cat /etc/shadow ... bin:*:10787:0:99999:7:-1:-1: ... tux1:$1$VOHuuCQM$Kqc9m7wSlQnRtqANtZCba/:10792:0:99999:0:0:13453 tux2:$1$BgSP6XLW$/tDKJTmLZzqh9372X7U7o0:10791:-1:99999:-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
Figure 13-12. /etc/shadow
LX036.0
Notes: Introduction
The passwords of the users are stored in /etc/shadow. This file contains, from left to right: 1. The user name. 2. 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. Note: A * means that this user does not have a password. That user account can therefore not be used to log in.
13-17
Student Notebook
3. 4. 5. 6. 7. 8.
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. 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. The /etc/shadow password file should be read/writable by root only. Other users should not be able to read this file at all.
V5.2
Student Notebook
Uempty
/etc/group and /etc/gshadow

# cat /etc/group root::0:root bin::1:root,bin,daemon daemon::2:root,bin,daemon sys::3:root,bin,adm adm::4:root,adm,daemon ... penguins:x:500:linus,tux1,tux2 tux1:x:501: tux2:x:502: # cat /etc/gshadow ... penguins:!:linus:tux1,tux2
Figure 13-13. /etc/group and /etc/gshadow
LX036.0
Notes: Introduction
The /etc/group file contains group information. The file contains, 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. Note that the group password is an old UNIX concept which is seldom used today. For backwards compatibility, this field is kept alive. - The name of the group administrator. - The list of users that have this group as their secondary group.
13-19
Student Notebook
/etc/issue and /etc/issue.net

Contain the login message for mingetty and telnetd
# cat /etc/issue Welcome to Generic Linux 1.0 Kernel \r on an \m
Several backslash escaped sequences are supported by mingetty: \r - kernel release \m - machine type \o - domain name See the mingetty manual page for a complete list.
Figure 13-14. /etc/issue and /etc/issue.net
LX036.0
Notes: Introduction
The /etc/issue and /etc/issue.net (not available in SLES) 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 file only appears on an ASCII screen, not on a GUI window. 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.
V5.2
Student Notebook
Uempty
Message of the day

/etc/motd Should only contain information necessary for the users to see
# cat /etc/motd ***************** SYSTEM OUTAGE **************** Due to a hardware upgrade this system will not be available between 10pm and 11pm tonight. ************************************************
If $HOME/.hushlogin exists, /etc/motd will not be shown when the user logs in
Figure 13-15. Message of the day
LX036.0
Notes: Introduction
The message of the day (motd) is stored in /etc/motd. Under normal conditions, users do see the contents of this file on their screen when they login. Users who login graphically do not see the message of the day. 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.
13-21
Student Notebook
Checkpoint
1.
a. b. c. d.
What is a User Private Group?

A group for users who need privacy A group which has the same name as the user; this user has this group as its primary group A group which is used for sharing files between the members of this group The "staff" group
2.
Where are the passwords of users stored? ______________________
LX036.0
Notes:
1. 2.
V5.2
Student Notebook
Uempty
Exercise 13: User administration
What you will do in this exercise: Add and delete users and groups Manipulate files involved in user administration
Figure 13-17. Exercise 13: User administration
LX036.0
Notes:
13-23
Student Notebook
Unit summary
Having completed this unit, you should understand: 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.
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Unit 14. User-level security

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

After completing this unit, you should be able to: 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

References
Linux man pages SUSE Linux 10 Installation and Administration Guide Red Hat Enterprise Linux V5 Administration Guide
14-1
Student Notebook
Unit objectives
After completing this unit, you should be able to: Describe the concepts of PAM 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
LX036.0
Notes:
V5.2
Student Notebook
Uempty
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 access

File permissions Account restrictions (login times, login tty, and so forth)
Figure 14-2. User-level security overview
LX036.0
Notes: Introduction
Security issues that surround users that log into a system, are handled under the area of user-level security. Securing users to access only system resources they should have access is to requires two steps: - Authentication - Authorization
Authentication
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
Copyright IBM Corp. 2001, 2009 Unit 14. User-level security 14-3
Student Notebook
- By showing that you are something, for instance, by using biometric data such as finger prints, retina scans and so forth
Authorization
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.
V5.2
Student Notebook
Uempty
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 Microsystems
Adapted for Linux
Figure 14-3. Pluggable Authentication Modules (PAM)
LX036.0
Notes: Introduction
Linux uses a subsystem called Pluggable Authentication Modules (PAM) to authenticate users. It is very flexible due to its modular design, allowing the system administrator to customize how applications authenticate users.
Shared libraries
PAM is implemented as a suite of shared libraries that are used by the different programs that need authentication services.
Sun Microsystems
PAM was initially developed by Sun Microsystems but later adapted for Linux.
14-5
Student Notebook
Authentication before PAM
Login
ftp
httpd
Other program
Very secure program
/etc/passwd
httpd authentication
Other authentication
Retina scan
Voice recognition
Figure 14-4. Authentication before PAM
LX036.0
Notes: Introduction
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
V5.2
Student Notebook
Uempty
authentication device. With a scheme like this, it is close to impossible to implement that.
14-7
Student Notebook
Authentication with PAM
Login
ftp
httpd
Other program
Very secure program
PAM config files in /etc/pam.d
PAM
httpd authentication Other authentication Retina scan Voice recognition
/etc/passwd
Figure 14-5. Authentication with PAM
LX036.0
Notes: Introduction
With PAM, every application that needs some kind of authentication, needs to be rewritten to use the PAM authentication mechanisms. Then, the only thing that program has to do is ask PAM, Is this user authorized to use me? 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
V5.2
Student Notebook
Uempty
- Secure tty, meaning that logging in is only allowed from a secure terminal 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.
14-9
Student Notebook
PAM configuration file example

# cat /etc/pam.d/login #%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/security/pam_unix.so likeauth auth required /lib/security/pam_nologin.so auth required /lib/security/pam_env.so account required /lib/security/pam_unix.so password required /lib/security/pam_cracklib.so retry=3 password required /lib/security/pam_unix.so nullok session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so session optional /lib/security/pam_console.so
Note: PAM configuration is different from distribution to distribution Please see the Notes area, below:
Figure 14-6. PAM configuration file example
LX036.0
Notes: Introduction
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.
V5.2
Student Notebook
Uempty
Example
Using the example shown on the visual, 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. Dont 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/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: The file in the visual is not an actual file, but merely an example.
RHEL/Fedora
Some actual examples are: # cat /etc/pam.d/login: #%PAM-1.0 auth [user_unkown=ignore success=ok default=bad pam_securetty.so auth include system-auth auth account required pam_nologin.so account required system-auth password include system-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session include system-auth session required pam_loginuid.so include system-auth session optional pam_console.so # pam_selinux.so open should be the last session rule session required pam_selinux.so open session optional pam_keyinit.so force revoke
14-11
Student Notebook
As you can see, RHEL/Fedora 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 contents of the system-auth file: # cat /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 pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeeed_if.so uid > = 500 quiet auth required pam_deny.so account required pam_unix.so account sufficient pam_succeed_if.so uid < 500 quiet account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok password required pam_deny.so session optional pam_keyinit.so revoke session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_nid session required pam_unix.so
SLES
An actual example from a SLES system is: # cat /etc/pam.d/login: auth required auth include auth required account include password include session include session required session required session optional pam_securetty.so common-auth pam_nologin.so common-account common-password common-session pam_lastlog.so nowtmp pam_resmgr.so pam_mail.so standard
As you can see, SLES uses the include option to direct PAM to use other PAM stacks, such as common-auth, for example.
V5.2
Student Notebook
Uempty
Common PAM modules

Some commonly used PAM modules are:
pam_unix.so: Regular UNIX authentication (passwords) pam_env.so: Set environment variables pam_cracklib.so: Check passwords for strength pam_pwdb.so: Enforce password aging rules pam_pwcheck.so: Check passwords (SLES only) pam_nologin.so: Deny login if /etc/nologin exists pam_listfile.so: Allow/deny login if user listed in file pam_securetty.so: Allow login for root only from secure ttys pam_time.so: Allow/deny login based on time of day pam_stack.so: Include another PAM config file (RHEL/FC only) pam_limits.so: Set limits on CPU and memory usage pam_console.so: Set permissions for console users pam_deny.so: Always gives an error pam_selinux.so: Sets up the default security context for the next execed shell
Several PAM modules have additional configuration files in /etc/security
Figure 14-7. Common PAM modules
LX036.0
Notes: Introduction
Various modules exist as part of the PAM library and can be used by applications. Also, 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.
14-13
Student Notebook
Principles of authorization
Authorization in Linux based on file permissions
Exception: 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 file mount: Allows users to mount a floppy or CD su: Runs a shell as another user, after supplying the password sudo: Runs a particular command as another user Various games (to track high scores)
All SUID programs should be known to the administrator and checked/updated for security problems
Figure 14-8. Principles of authorization
LX036.0
Notes: Introduction
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.
SUID programs
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 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.
V5.2
Student Notebook
Uempty
- 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. - sudo: This was invented when people started noticing that sometimes users need to execute scripts or complicated commands as root without actually becoming root. Traditional methods would either mean giving these users the root password or setting 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 high score tracking.
Locating SUID programs

Apart from kernel bugs, SUID programs are the only means for a hacker to gain root privileges when he or she 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 +4000 -ls 30292 32 -rwsr-xr-x 1 root 26339 36 -rwsr-xr-x 1 root 66295 20 -rwsr-xr-x 1 root 66739 112 -rwsr-xr-x 1 root . . . root 32108 Jan 26 04:21 /bin/su root 35692 Jan 29 08:23 /bin/ping audio 20404 Jan 29 09:58 /bin/eject root 114448 Feb 1 01:49 /bin/mount
14-15
Student Notebook
File permissions
Permission r w x SUID SGID File User can see contents of file User can change contents of file User can execute file as a command Program runs with effective user ID of owner Program runs with effective group ID of owner No effect Directory Use can list the contents of s directory User can change the contents of the directory User can cd to directory and can use it in PATH No effect Files created in directory inherit the same group ID as the directory Only the owner of the file and the owner of the directory may delete files in this directory
Sticky bit
Figure 14-9. File permissions
LX036.0
Notes: Introduction
There are a number of permission bits associated with files and directories. These permissions are: - r (see): User can see 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
V5.2
Student Notebook
Uempty
Directory: cd directory - Switch UID (SUID): If the file gets executed, it runs 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. - Switch GID (SGID): On an executable file, this 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 or she usually leaves 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.
14-17
Student Notebook
Changing permissions
Setting file permissions is done with the chmod command
# chmod 1755 (or o+t) commondir # ls -ld commondir drwxr-xr-t 2 root proj1 4096 May 19 09:00 commondir/ # chmod 2755 (or g+s) myprog # ls -l myprog -rwxr-sr-x 1 root root 729402 May 19 09:02 myprog # chmod 4755 (or u+s) passwd # ls -l /etc/passwd -rwsr-xr-x 1 root root 2721 Mar 15 10:58 /etc/passwd
Changing user and group

# chown john finance # chgrp staff finance # chown john.staff finance
Figure 14-10. Changing permissions
LX036.0
Notes: Introduction
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 ...
V5.2
Student Notebook
Uempty
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 For user 022 002 (if user private groups are used) or 022 (otherwise)
Figure 14-11. umask
LX036.0
Notes: Introduction
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.
Copyright IBM Corp. 2001, 2009 Unit 14. User-level security 14-19
Student Notebook
Example: Creating a team directory

Create a group # groupadd penguins Add users to the group # usermod -G penguins tux1 or: # gpasswd -a tux1 penguins Create a directory and set group permissions # mkdir /groups/penguins # chgrp penguins /groups/penguins # chmod 2770 /groups/penguins
Figure 14-12. Example: Creating a team directory
LX036.0
Notes: Introduction
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.
V5.2
Student Notebook
Uempty
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
Figure 14-13. Root access
LX036.0
Notes: Introduction
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. 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 might 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.
14-21
Student Notebook
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.
V5.2
Student Notebook
Uempty
su command
Switch to another userid $ whoami tux1 $ su Password: # whoami root Using su - <user> changes to the environment of that user Execute a command as another user
$ su - root -c /sbin/poweroff Password: $ Broadcast message from root (tty1): The system is going down for system halt NOW!
Figure 14-14. su command
LX036.0
Notes: Introduction
The su command runs in a subshell with the effective user ID and root privileges (if no username is specified). You are asked for root's password before you gain root permissions. To end the session, type exit or CTRL-D, which returns you to the original shell session and privileges. For example, su terry gives you the privileges of Terry, but you can still be in the environment of the user issuing su. su - terry sets up the environment as if you had logged in as Terry.
14-23
Student Notebook
sudo command
Allows users to execute specific commands as another user without requiring that users password
Do NOT use sudo for interactive commands!
/etc/sudoers file lists 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/sudoers User_Alias OPERATORS = tux1, tux2, tux3 Host_Alias WEBSERVERS = www, www-1, www-2 Cmnd_Alias PRINTCMDS = /usr/bin/printtool, /usr/bin/klpq tux1 WEBSERVERS = (root) /sbin/service httpd restart OPERATORS printsvr = (root) PRINTCMDS
Figure 14-15. sudo command
LX036.0
Notes: Introduction
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.
V5.2
Student Notebook
Uempty
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. 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.
14-25
Student Notebook
Security logs
/var/log/lastlog /var/log/messages /var/log/secure /var/log/wtmp /var/run/utmp - Last successful login - General log file - Failed logins - Successful logins - Currently logged in users
Figure 14-16. Security logs
LX036.0
Notes: Introduction
There are several files that keep track of failed, successful, and current logins. These files are: - /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. - /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.
V5.2
Student Notebook
Uempty
- /var/run/umtp: Logs the users currently logged in the system. The default output of the who command is the contents of this file.
14-27
Student Notebook
Useful commands
Who is logged in and doing what?
# w
09:43:46 USER root root root root up 17 days, 20:50, 6 users, load average: 0.00, 0.02, 0.00 TTY FROM LOGIN@ IDLE JCPU PCPU WHAT pts/3 sig-9-49-140-187 09:40 2:09 0.03s 0.01s ssh 10.0.02 pts/4 sig-9-49-140-187 09:40 2:13 0.02s 0.01s ssh 10.0.0.3 pts/5 sig-9-49-140-187 09:41 49.00s 0.02s 0.01s ssh 10.0.0.4 pts/6 sig-9-49-140-187 09:43 0.00s 0.01s 0.00s w
Who is logged in and examine the contents of /var/log/wtmp and /var/log/utmp

# who
root root root root root root pts/3 pts/2 pts/1 pts/4 pts/5 pts/6 May May May May May May 19 8 8 19 19 19 09:40 07:43 10:22 09:40 09:41 09:43 (sig-9-49-140-187.mts.ibm.com) (:1.0) (:1.0) (sig-9-49-140-187.mts.ibm.com) (sig-9-49-140-187.mts.ibm.com) (sig-9-49-140-187.mts.ibm.com)
Figure 14-17. Useful commands
LX036.0
Notes: Introduction
The visual shows example command output.
V5.2
Student Notebook
Uempty
Additional commands
Show information about a user
# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:system_r:unconfined_t
Show the last time a user logged in or the last time a tty was used to log in
# last
root pts/6 sig-9-49-140-187 Fri May 19 09:43 still logged in . . . reboot system boot 2.6.9-27.ELsmp Mon May 1 12:53 (17+20:53) root pts/1 sig-9-65-56-32.m Mon May 1 11:40 - down (00:03) wtmp begins Mon May 1 11:40:45 2006
Show the last login time of all users

# lastlog
Username root bin . . . guest Port pts/6 From Latest sig-9-49-140-187 Fri May 19 09:43:15 -0700 2006 **Never logged in** sig-9-48-37-17.m Mon Apr 24 10:52:59 -0700 2006
pts/7
Figure 14-18. Additional commands
LX036.0
Notes: Introduction
The visual shows more example command output.
14-29
Student Notebook
Checkpoint
1. What is the difference between authentication and authorization? ______________________________________________ True/False: The user root can log in anywhere, anytime. True/False: PAM is the subsystem responsible for user authentication.
2. 3.
LX036.0
Notes:
1. 2.
3.
V5.2
Student Notebook
Uempty
Exercise 14: User-level security
What you will do in this exercise: Perform various activities related to user-level security
Figure 14-20. Exercise 14: User-level security
LX036.0
Notes:
14-31
Student Notebook
Unit summary
Having completed this unit, you should understand: Pluggable Authentication Modules (PAM) 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.
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Unit 15. Troubleshooting

This unit teaches you the basics of troubleshooting a Linux system.

After completing this unit, you should be able to: Perform basic problem determination Utilize Rescue Mode to perform system recovery

References
Linux man pages SUSE Linux 10 Installation and Administration Guide Red Hat Enterprise Linux V5 Administration Guide http://www.google.com/linux Google Search Engine http://www.tldp.org/ The Linux Documentation Project https://bugzilla.redhat.com/bugzilla Red Hat Bugzilla Main Page http://www.novell.com/support Novell Support Center
15-1
Student Notebook
Unit objectives
After completing this unit, you should be able to: Perform basic problem determination Utilize Rescue Mode to perform system recovery
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Troubleshooting
Identifying and fixing problems Required:
Deep understanding of the system Knowledge of dependencies in the system Knowledge of problem determination tools Knowledge of problem solving methods Experience Documentation Reference systems Internet access No outside distraction Sparring partner
Useful:
Figure 15-2. Troubleshooting
LX036.0
Notes: Introduction
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 gives 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 and of the troubleshooting tools that are available on your system. Also, a lot of experience helps a lot too. Useful things to have include documentation, reference systems, and Internet access. However, 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
Copyright IBM Corp. 2001, 2009 Unit 15. Troubleshooting 15-3
Student Notebook
and talking to management so that the others are able to direct their full attention to the problem. - 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.
V5.2
Student Notebook
Uempty
Identifying the problem: Part 1

Check the system to see if this is an isolated failure (single service not responding) or if it is a broader issue
For example, a http service may fail (not respond) due to networking issues
Check logfiles in /var/log for any sign of failure (generic and application specific)
Debugging switch or key might give more information
Check configuration files

Use syntax checkers if available
Check and see if anything was changed recently

Run a rpm verification on the system
Figure 15-3. Identifying the problem: Part 1
LX036.0
Notes: Service not responding

Identifying the problem usually starts with determining if the reported problem is an isolated failure (meaning one subsystem) or is it a broader issue. Actions to take: - Test the server and any services that it relies on for signs of failure. Note: A service failure may be caused by a problem with an underlying service, such as networking, DNS, PAM, full filesystems, improper permissions, or the X Font Server (xfs). For example, an NFS mount will fail if either forward or reverse name resolution fails. - Read the logfiles for signs of failure, both the generic logfiles (such as /var/log/messages) and the application-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 reconfigured your /etc/syslog.conf file to log debug output too.
Student Notebook
- If your logfiles don't give you a clue, read the configuration files for the service that you are debugging. Most services provide a method to check the configuration file for syntax errors. For example, Apache provides the apachectl configtest command that checks for errors in the configuration file. - Check and see if anything was changed recently: Run a rpm verification: # rpm -Va From Rescue Mode, use the -root option to the rpm command: - For example, on SUSE with the root filesystem mounted onto the /mnt mount point, enter: # rpm -root /mnt -Va - For example, on RHEL/Fedora with the root filesystem mounted onto the /mnt/sysimage mount point, enter: # rpm -root /mnt/sysimage -Va - If Tripwire1 is configured on the system, run a tripwire check.*
Tripwire is a security package that is included with the SUSE Linus distribution, available from http://sourceforge.net/projects/tripwire or from www.tripwire.com (Tripwire Enterprise/Server) for purchase.
V5.2
Student Notebook
Uempty
Identifying the problem: Part 2

Check the change documentation for the system Compare with reference system Check the Web
Google: http://www.google.com/linux The Linux Documentation Project: http://www.tldp.org Red Hat Bugzilla: https://bugzilla.redhat.com Novell Support: http://www.novell.com/support
Figure 15-4. Identifying the problem: Part 2
LX036.0
Notes: Additional things to consider

When dealing with a failure of a service or a system-wide outage, the following items should be also considered: - Are there multiple system administrators managing the system? - How does the failing system compare to a working system? - Has anyone else seen this type of failure before?
Multiple administrators
For systems that are being administered by multiple system administrators, it is recommended that a system change log be kept. Doing so will help reduce the time to identify the cause of a service/system failure. Checking this type of log will provide hints as to what has changed and how the changes might be rolled back, if needed.
15-7
Student Notebook
Reference system
During times of a service/system failure, it might be useful to compare the actual situation with a working reference system, another system running the same services.
Web resources
Finally, it can 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. Sites of interest include: - Google: http://www.google.com/linux - The Linux Documentation Project: http://www.tldp.org - Red Hat Bugzilla: https://bugzilla.redhat.com/ - Novell: http://www.novell.com/support
V5.2
Student Notebook
Uempty
Core dumps
Due to programming/compilation errors, programs may misbehave
Access memory outside the assigned memory area Perform illegal instructions Divide by zero And so on
In this cases, the kernel will detect this behavior and dump core, which saves 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 gdb

Only useful for the programmer Core dumps can generally be deleted without consequence
Saving core dumps can be prevented with ulimit c 0

Figure 15-5. Core dumps
LX036.0
Notes: Introduction
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 - They may try to divide by zero In most cases, the kernel will detect this behavior2, 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-\ keys. Note, however, that it is possible
2 In fact, its usually the CPU that detects these illegal instructions. The CPU will then suspend the program and start the error handler of the kernel.
15-9
Student Notebook
for the programmer to write a signal handler that assigns a different meaning to this signal. This core file can then be used by the programmer to figure out what went wrong in his or her program. For this, the programmer typically uses 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 dont want core dumps to be saved, you can set the maximum size of them to zero with the command ulimit -c 0. Most distributions will set a soft core dump limit of zero by default.
V5.2
Student Notebook
Uempty
Fixing the problem

Fixing the problem is usually obvious once you find the error When repairing a problem, change one item at a time Can be more complicated if system refuses to boot normally Solutions:
Boot from boot floppy Boot into single user mode and/or with special kernel parameters such as init=/bin/bash Boot into Rescue Mode
Figure 15-6. Fixing the problem
LX036.0
Notes: Introduction
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 (GRUB or LILO), a Linux kernel, and (if needed) an Initial RAM Disk. This allows you to bypass any problem that might exist in your master boot record or in your /boot partition/directory (that is, corrupt or missing kernel image, initrd), but does not help you if the problem is in your root filesystem or further along in the boot process.
15-11
Student Notebook
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 GRUB or LILO boot prompt with linux root=/dev/hda6 The kernel on the boot disk is optimized for your processor. This means that you cannot use a boot disk created on an older 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 RHEL/Fedora 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 thus cannot 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 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. Note: When repairing a problem, change one item at a time!
V5.2
Student Notebook
Uempty
What is Rescue Mode?

The ability to boot a small Linux environment entirely from an external source Why Rescue Mode?
You are unable to boot Linux You are having hardware or software problems You want to get a few important files off your system's hard drive
Rescue Mode is available from CD #1 of distribution or from network server
Figure 15-7. What is Rescue Mode?
LX036.0
Notes: Small Linux environment entirely from an external source

If you have worked with any UNIX-like operating system, you have probably needed to recover or repair that system at some time. Even though todays operating systems, like Linux, are robust and stable, they are still susceptible to possible corruption. In the case of Linux, this is handled by a process called Rescue Mode. Linux Rescue Modes generally fall into two classes. The first class of these are rescue disks that are provided with or produced by a specific Linux distribution and are therefore targeted toward correcting problems encountered on a machine running that distribution. The second class of Rescue Mode is distribution-independent, single-CD rescue disks that are designed to help you recover any Linux system, regardless of the distribution on which it is based.
15-13
Student Notebook
Why Rescue Mode?

Some classic examples of things that can induce boot problems are: - Missing or damaged disk blocks (such as the master boot record (MBR)) - Missing files required by the boot loader - Bad or incorrectly updated boot loader configuration information - Bad or missing kernel - Bad or missing initrd Rescue Mode is used in the situation where your system won't boot because the root file system is corrupted and you can't even boot to the point where you can access the fsck utility on the system itself. The following are possible reasons for using Rescue Mode: - File system mis-configuration - Bootloader problems - Damaged kernel In the worst case, you may find that your file systems are so damaged that it is easier to reinstall your system in its entirety. In this case, you can boot into Rescue Mode and then use backup utilities to back up files to supported removable media or over the network.
V5.2
Student Notebook
Uempty
Use available rescue tools (1 of 3)

The first task is to see if your partition table exists
# fdisk l Disk /dev/sda: 80.0 GB, 80026361856 bytes 255 heads, 63 sectors/track, 9729 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot /dev/sda1 /dev/sda2 * /dev/sda3 /dev/sda4 /dev/sda5 /dev/sda6 /dev/sda7 /dev/sda8 Start 1 4152 4283 4414 4414 5067 5720 6373 End Blocks Id System 4152 33342907 7 HPFS/NTFS 4283 105227 83 Linux 4414 1052257+ 82 Linux swap / Solaris 9729 42700769+ f W95 Ext'd (LBA) 5066 1574463 83 Linux 5719 252459 83 Linux 6372 252459 83 Linux 7025 1574463 83 Linux
Can you pick out your root partition?

Figure 15-8. Use available rescue tools (1 of 3)
LX036.0
Notes:
One of the first thing you need to do in Rescue Mode is to figure out where your root and boot and usr filesystems exist. The fdisk l command will show you your partition table or not, if it is corrupted. You then need to discover which of the partitions show is your root partition, as well as your boot and usr partitions. This can be a daunting task if this happens to NOT be your machine or one that you set up. There are some hints, such as size or type. If there is no documentation, you just have to take your best guess and mount and see one at a time.
15-15
Student Notebook

Next, did you choose the correct partition?
# ls -l /mnt/resq total 264 drwxr-xr-x 3 root root drwxr-xr-x 2 root root drwxr-xr-x 2 root root drwxr-xr-x 2 root root drwxr-xr-x 119 root root drwxr-xr-x 6 root root drwxr-xr-x 117 root root drwxr-xr-x 13 root root drwxr-xr-x 11 root root drwxr-xr-x 2 root root drwxr-xr-x 232 root root drwxr-xr-x 4 root root lrwxrwxrwx 1 root root 4096 65536 4096 4096 12288 4096 69632 4096 4096 20480 12288 4096 10 Dec 18 Dec 19 Oct 10 Oct 10 Dec 18 Sep 11 Dec 19 Dec 19 Dec 18 Dec 19 Dec 19 Dec 18 Dec 18 2007 X11R6 2007 bin 2006 etc 2006 games 2007 include 2007 kerberos 2007 lib 2007 libexec 2007 local 2007 sbin 2007 share 2007 src 2007 tmp -> ../var/tmp
Can you prove this is or is not root?

Figure 15-9. Use available rescue tools (2 of 3)
LX036.0
Notes:
Lets say you chose this partition because it was the largest or the smallest or lowest/highest partition number or one of many other reasons. After you mount it, do you like what you see? If you remember from earlier in this course, there are five directories that must exist in the root directory (and we are NOT speaking of /root/ here). Those five directories are /dev, /etc, /bin, /sbin, and /lib. The display above does not have these, so it cannot be the one we are looking for. Can you figure out which partition this is? One hint that it is not / is the entry for tmp it is a symbolic link to somewhere up. One hint that this display is from /usr are the entries for X11 and games.
V5.2
Student Notebook
Uempty

Maybe this is the correct partition?
ls -l /mnt/resq total 176 drwxr-xr-x 2 root root 4096 Dec 19 2007 bin drwxr-xr-x 5 root root 4096 Dec 19 2007 boot drwxr-xr-x 11 root root 4220 Aug 4 15:45 dev drwxr-xr-x 106 root root 12288 Aug 4 15:46 etc drwxr-xr-x 3 root root 4096 Dec 18 2007 home drwxr-xr-x 14 root root 4096 Dec 19 2007 lib drwxr-xr-x 2 root root 4096 Aug 4 13:19 media drwxr-xr-x 3 root root 16384 Dec 31 1969 mnt dr-xr-xr-x 147 root root 0 Aug 4 09:14 proc drwxr-x--- 21 root root 4096 Jan 14 2008 root drwxr-xr-x 2 root root 12288 Dec 19 2007 sbin drwxr-xr-x 2 root root 4096 Oct 10 2006 srv drwxr-xr-x 11 root root 0 Aug 4 09:14 sys drwxrwxrwt 4 root root 4096 Aug 4 14:35 tmp drwxr-xr-x 14 root root 4096 Dec 18 2007 usr drwxr-xr-x 26 root root 4096 Dec 18 2007 var
Can you prove this is or is not root?

Figure 15-10. Use available rescue tools (3 of 3) LX036.0
Notes:
This display looks like the right partition, First, it contains all five necessary directories. Now you might need to find the boot and usr partitions to continue your challenge to fix the system.
15-17
Student Notebook
chroot command
chroot command reassigns your root path
etc passwd etc passwd sbin (/dev/hda6) sbin /
mnt
Rescue: ~ # df Filesystem 1K-blocks /dev/root 57576 udev 192796 /dev/sda6 10490040 /dev/sda5 17510244 Rescue: ~ # chroot /mnt Rescue: ~ # df Filesystem 1K-blocks /dev/sda6 10490040 proc 10490040 udev 10490040
Used Available Use% Mounted on 57576 0 100% / 72 192724 1% /dev 2934416 7555624 28% /mnt 38808 17471436 1% /mnt/home
Used Available Use% Mounted on 2934416 7555624 28% / 2934416 7555624 28% /proc 2934416 7555624 28% /dev
Figure 15-11. chroot command
LX036.0
Notes: chroot command

The chroot command reassigns your root path to the disk file system instead of the rescue file system. If you do not use the chroot command, any other command will perform an action on the RAM disk, not the target disk you actually want to fix! Looking at the example in the visual (SLES), we see the following: - The root filesystem is stored in a RAM disk called /dev/root - The root filesystem of the SLES installation on the hard disk is stored on /dev/hda6 - /dev/hda6 is mounted on /mnt Without the use of the chroot command, any operation will be relative to the root node of /dev/root. For example, when recovering the root password on a SLES installation: - If the passwd command is issued without chroot being invoked, the /etc/passwd file of the root filesystem stored in the RAM disk (/dev/root) will be modified
V5.2
Student Notebook
Uempty
With the use of the chroot command invoked with the mount point of /mnt, any operation will be relative to the root node of /dev/hda6: - If the passwd command is issued with chroot being invoked, the /etc/passwd file of the root filesystem stored in the hard disk (/dev/hda6) will be modified.
15-19
Student Notebook
Booting Rescue Mode: RHEL/Fedora

Step 1: Boot with rescue option Step 2: Decide to mount existing installation to /mnt/sysimage
boot: linux rescue
+---------------------+ Rescue +---------------------+ | | | The rescue environment will now attempt to # | | find your Red Hat Linux installation and mount # | | it under the directory /mnt/sysimage. You can # | . . . | | | +----------+ +-----------+ +------+ | | | Continue | | Read-Only | | Skip | | | +----------+ +-----------+ +------+ | +----------------------------------------------------+ +---------------+ Rescue +----------------+ | | | Your system has been mounted under | | /mnt/sysimage. | | | | Press <return> to get a shell. If you | | would like to make your system the | | root environment, run the command: | | | | chroot /mnt/sysimage | | | | The system will reboot automatically | | when you exit from the shell. | | | | +----+ | | | OK | | | +----+ | +-----------------------------------------+
Step 3: Acknowledge mount on /mnt/sysimage
Figure 15-12. Booting Rescue Mode: RHEL/Fedora
LX036.0
Notes: Introduction
The Rescue Mode environment for RHEL/Fedora is accessed by either booting from the first CD-ROM of the distribution or over the network. When booting from the CD-ROM, issue the command linux rescue at the boot: prompt.
Automatic mount of Linux installation

During the loading of the Rescue Mode environment, you will be prompted if you want Rescue to find any existing installations and mount them to the directory structure /mnt/sysimage. The options presented are: - Continue: Find and mount the discovered installation to the mount point /mnt/sysimage with read-write - Read Only: Find and mount the discovered installation to the mount point /mnt/sysimage as read-only
V5.2
Student Notebook
Uempty
- Skip: Do not attempt to discovered the existing installation In the example shown in the visual, the Continue button was selected, and the system administrator is prompted to acknowledge that the mount was successful.
15-21
Student Notebook
Using Rescue Mode: RHEL/Fedora

At this point, take administrative action to fix problem or recover data When using the chroot command, the first exit will leave the chroot environment
Second exit will leave the rescue environment
sh-3.00# df Filesystem 1K-blocks Used Available Use% rootfs 7163 4944 1810 74% /dev/root.old 7163 4944 1810 /tmp/loop0 183580 183580 0 100% /dev/VolGroup00/LogVol00 16320424 6876448 8614948 45% /dev/sda1 101105 13834 82050 15% /dev/root.old 7163 4944 1810 sh-3.00# chroot /mnt/sysimage sh-3.00# df Filesystem 1K-blocks Used Available Use% /dev/VolGroup00/LogVol00 16320424 6876448 8614948 45% /dev/sda1 101105 13834 82050 15% Mounted on / 74% / /mnt/runtime /mnt/sysimage /mnt/sysimage/boot 74% /mnt/sysimage/dev
Mounted on / /boot
sh-3.00# exit sh-3.00# exit

Figure 15-13. Using Rescue Mode: RHEL/Fedora
LX036.0
Notes: Now what?

Once the Rescue Mode environment has been booted, it is now time to take administrative action to fix or recover the system. If you selected the mounting of the existing installation to the /mnt/sysimage mount point, you can now dive in to resolve the problem. Remember, that you may need to use the chroot command to change the roots path to the /mnt/sysimage mount point.
Exiting chroot/Rescue
Exiting chroot/Rescue relies on the use of the exit command. If the chroot command was invoked, the first exit will leave the chroot environment. The second exit will leave the Rescue Mode environment and reboot the system.
V5.2
Student Notebook
Uempty
Booting Rescue Mode

Step 1: boot with rescue option Step 2: Log in as root Step 3: Find existing filesystems Step 4: Mount existing installation to /mnt
Boot from Hard Disk Installation InstallationACPI Disabled InstallationSafe Settings Rescue System Memory Test Boot Options _____________________ F1 Help F2 Language F3 Other Options
Rescue login: root Rescue: ~# guessfstype /dev/hda3 /dev/sda3 *appears* to be: swap Rescue: ~# guessfstype /dev/sda5 /dev/sda5 *appears* to be: reiserfs Rescue: ~# guessfstype /dev/sda6 /dev/sda6 *appears* to be: reiserfs Rescue: ~# mount /dev/sda6 /mnt Rescue: ~# mount /dev/sda5 /mnt/home
Figure 15-14. Booting Rescue Mode
LX036.0
Notes: Introduction
The Rescue Mode environment for SLES is accessed by either booting from the first CD-ROM of the distribution or over the network. When booting from the CD-ROM, the boot splash screen as shown in the visual will appear. Select the Rescue System options. Note: Rescue requires you to login as root, and no password by default is required.
Accessing Linux installation

Unlike RHEL/Fedora, the SLES Rescue Mode environment does not prompt you to mount the existing installation to a given mount point. It is up to you as the system administrator to know the disk layout of your system. However, if you dont know the layout, you can use the following commands: - fdisk -l (To determine the partitioning of the system)
Student Notebook
- guessfstype (To guess the type of filesystem utilized in a given partition) In the example shown in the visual, the devices sda5/6 contain reiserfs filesystems. Using the fdisk command, enter: # fdisk /dev/sda Disk /dev/sda: 30.0 GB, 30020272128 bytes 255 heads, 63 sectors/track, 3649 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot /dev/sda1 * /dev/sda2 /dev/sda3 Solaris /dev/sda5 /dev/sda6 Start 1 16 3520 16 2196 End 15 3519 3649 2195 3501 Blocks 120456 28145880 1044225 Id 83 f 82 System Linux W95 Ext'd (LBA) Linux swap /
17510818+ 83 Linux 10490413+ 83 Linux
Given the size of the device /dev/hsa6, it is possible to guess that it is the root filesystem and mount it on /mnt.
V5.2
Student Notebook
Uempty
Using Rescue Mode: SUSE

At this point, take administrative action to fix problem or recover data When using the chroot command, the first exit will leave the chroot environment
halt will leave the rescue environment
Rescue: ~ # df Filesystem 1K-blocks /dev/root 57576 udev 192796 /dev/sda6 10490040 /dev/sda5 17510244 Rescue: ~ # chroot /mnt Rescue: ~ # df Filesystem 1K-blocks /dev/sda6 10490040 proc 10490040 udev 10490040 Rescue: ~ # exit
Used Available Use% Mounted on 57576 0 100% / 72 192724 1% /dev 2934416 7555624 28% /mnt 38808 17471436 1% /mnt/home
Used Available Use% Mounted on 2934416 7555624 28% / 2934416 7555624 28% /proc 2934416 7555624 28% /dev
exit
Rescue: ~ #
halt
Figure 15-15. Using Rescue Mode: SUSE
LX036.0
Notes: Now what?

Once the Rescue Mode environment has been booted, it is time to take administrative action to fix or recover the system. Once the existing installation is mounted, you can now dive in to resolve the problem. Remember, that you may need to use the chroot command to change the roots path to the /mnt mount point.
Exiting chroot/Rescue
Exiting chroot relies on the use of the exit command. If the chroot command was invoked, the exit will leave the chroot environment. To exit Rescue, use the halt command. The halt command will leave the Rescue Mode environment and reboot the system.
15-25
Student Notebook
Repair installed system: SUSE
Figure 15-16. Repair installed system: SUSE
LX036.0
Notes: Introduction
Because it cannot be assumed that a damaged system can boot by itself and a running system cannot be easily repaired, the YaST System Repair utility is run from the SUSE Linux installation CD-ROM or network. Note: Because the test and repair procedure is loaded from CD-ROM or network, it is essential to run it from an installation medium that exactly corresponds to your installed version of SLES.
Automatic repair
This method is best suited to restoring a damaged system with unknown cause. Selecting it starts an extensive analysis of the installed system, which takes quite some time due to the large number of tests and examinations. The progress of the procedure is displayed at the bottom of the screen with two progress bars. The upper bar shows
V5.2
Student Notebook
Uempty
the progress of the currently running test. The lower bar shows the overall progress of the analysis process. The log window above allows tracking of the currently running activity and its test result. The following main test runs are performed with every run. They contain, in turn, a number of individual sub-tests: Partition tables of all hard disks The validity and coherence of the partition tables of all detected hard disks are checked. Swap partitions The swap partitions of the installed system are detected, tested, and offered for activation where applicable. The offer should be accepted for the sake of a higher system repair speed. File systems All detected file systems are subjected to a file system-specific check. Entries in the file /etc/fstab The entries in the file are checked for completeness and consistence. All valid partitions are mounted. Boot loader configuration The boot loader configuration of the installed system (GRUB or LILO) is checked for completeness and coherence. Boot and root devices are examined, and the availability of the initrd modules is checked. Package database This checks whether all packages necessary for the operation of a minimal installation are present. While it is optionally possible also to analyze the base packages, this takes a long time because of their vast number. Whenever an error is encountered, the procedure stops and a dialog opens, offering details and possible solutions. It is not possible to describe all these cases. Read the messages on the screen carefully and choose the desired action from the list options. It is also possible to decline the offered repair action in cases of doubt. The system remains unaltered in this case, and no repair is ever performed automatically without prompting the user.
Customized repair
If you already know what part of the system is affected, the range of the applied tests can be narrowed. Choosing Customized Repair shows a list of test runs that are all marked for execution at first. The total range of tests matches that of automatic repair. If you already know where no damage is present, unmark the corresponding tests. Clicking Continue then starts a narrower test procedure that probably has a significantly shorter running time.
Student Notebook
Not all test groups are applicable individually. The analysis of the fstab entries is always bound to an examination of the file systems, including existing swap partitions. YaST automatically satisfies such dependencies by selecting the smallest number of necessary test runs.
Expert tools
If you are knowledgeable with SUSE Linux and already have a very clear idea of what needs to be repaired in your system, directly apply the tools necessary for repairing it by choosing Expert tools. Install new boot loader This starts the YaST boot loader configuration module. Run partitioning tool This starts the expert partitioning tool in YaST. Fix file system This checks the file systems of your installed system. You are first offered a selection of all detected partitions and can then choose the ones to check. Restore lost partitions It is possible to attempt a reconstruction of damaged partition tables. A list of detected hard disks is presented first for selection. Clicking OK starts the examination. This can take a while depending on the processing power and size of the hard disk.
V5.2
Student Notebook
Uempty
Checkpoint
1. True/False: Internet access is required for troubleshooting. 2. If your X server does not start, then the problem might also be:
a. b. c. d. The network The font server A full filesystem All of the above
3. SUSE Linux provides a __________ from the Installation menu.
LX036.0
Notes:
1. 2. 3.
15-29
Student Notebook
Exercise 15: Troubleshooting
What you will do in this exercise: Insert and resolve problems on your system
Figure 15-18. Exercise 15: Troubleshooting
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Unit summary
Having completed this unit, you should understand: 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. If a system won't boot, you can use the boot disk, single user mode or the Rescue Mode to fix the system.
LX036.0
Notes:
15-31
Student Notebook
V5.2
Student Notebook
AP
Appendix A. Checkpoint solutions

Unit 1
Checkpoint solutions
1. True / False: A network install server needs to be a Linux system. False. It is possible to use UNIX or Windows NT. 2. Which of the following install methods does not require a network server?
a) b) c) d) NFS SMB FTP CD-ROM
3. What are some possible locations where a RHEL/Fedora kickstart or SLES AutoYaST file can be stored? Floppy disk Network server (HTTP, NFS) USB key Local VFAT partition
A-1
Student Notebook
Unit 2
1. Name the four steps that form the startup order of a Linux system: BIOS, boot loader, kernel, init 2. How would you select a graphical login screen (xdm, kdm, or gdm)? By setting runlevel 5 as the default runlevel in /etc/inittab
A-2
V5.2
Student Notebook
AP
Unit 3
1. The RHEL/Fedora _setup____ tool provides a menubased interface for various tools used during a text-based installation. True / False RHEL/Fedora provide separate tools that start with system-config to administrate the system with a GUI interface. SUSE provides a tool called _YaST________ as a GUI interface/text menu tool to be used for various system administration tasks. What is the default port number to connect with the Webmin administration tool using a Web browser?
10000
2.
3.
4.
A-3
Student Notebook
Unit 4
1. Which basic modes of operation does rpm have? _Install, freshen and upgrade, uninstall, query, and verify_ 2. Which command can I use to verify that the permissions of /etc/sendmail.cf are still correct? _rpm V f /etc/sendmail.cf____________ 3. From the list provided, check all software maintenance operations that the rpm command provides:
_X_ Installation of a RPM package ___ Installation of a tar ball archive ___ Removal of seldom used packages _X_ Updating a package _X_ Verification of package installation
A-4
V5.2
Student Notebook
AP
Unit 5
1. What is the function of X.org? It is the graphical user interface for UNIX/Linux What is the function of a window manager? It allows more control for your windows space How do you run an individual X application over a network?
Set the DISPLAY variable (or option) and enable authentication with xauth or ssh
2.
3.
A-5
Student Notebook
Unit 6
1. The syslogd daemon receives all logging requests and forwards it to the right destination, depending on priority and facility. What does the logger command do? It sends log messages to the syslogd daemon The logrotate command
a) b) c) Creates new log files Rotates and cleans up log files Deletes log files
2.
3.
A-6
V5.2
Student Notebook
AP
Unit 7
1. 2. True / False: A character device allows random seeks. What is the difference between /dev/random and /dev/urandom?
/dev/urandom allows many more random numbers
3.
PCMICA and USB devices are detected automatically by the kernel, usually .
A-7
Student Notebook
Unit 8
1. True/False: RAID volumes can be used as physical volumes in an LVM setup. Mirroring is offered by RAID level:
a. b. c. d. e. Linear Zero One Four Five
2.
3.
What command is used to create a RAM disk? There is no specific command. A RAM disk is created automatically as soon as you start using it.
A-8
V5.2
Student Notebook
AP
Unit 9
1.
a. b. c. d.
Assuming a blocksize of 1024, how many inodes and data blocks do you need for a file on an ext2 filesystem?
with size 0? 1 inode and 0 data blocks with size 1? 1 inode and 1 data block with size 2000? 1 inode and 2 data blocks with size 12289 (12 K+1)? 1 inode and 12 data blocks directly from the inode, an indirect block, and an extra data block. Total 14 data blocks.
2.
a. b.
What are the two methods of copying a file to a (not yet mounted) MS-DOS floppy?
Mount filesystem, and use cp command Use mcopy (from mtools)
3.
What files are important with respect to quotas? /etc/fstab to specify filesystems /quota.users and /quota.groups
A-9
Student Notebook
Unit 10
1. Which file in /proc shows current system-wide memory performance statistics? _ meminfo _____________________ List two commands that provide system memory status: _ <Answers may vary>___ __procinfo, free, top, vmstat, ps__ What is the difference between a paging partition and a paging file? Which is more efficient? _A paging partition is directly written in the partition table and to disk, while a paging file has to go through the filesystem. A paging partition is more efficient. ___ What does the Xen Virtual Memory Manager do? _Xen is an open source virtual machine monitor that uses virtualization to allow multiple operating systems to run on the same computer._
2.
3.
4.
A-10 Linux System Administration I
V5.2
Student Notebook
AP
Unit 11
1. What command can be used to look at your crontab jobs? crontab l What tool would you use to run a daily cleanup job on your workstation?
a. b. c. cron anacron at
2.
3.
How do you regulate the use of the crond and atd daemons? cron: /etc/cron.allow and /etc/cron.deny at: /etc/at.allow and /etc/at.deny
A-11
Student Notebook
Unit 12
1.
a. b.
What is the difference between A and B?

find /home/francis -print cpio -ov >/dev/rmt0 find . -print cpio -ov >/dev/rmt0 A - Will back up the files using the full pathnames. B - Will back up the file names using the relative pathnames. B - Can also restore its file into any directory.
2.
Which one of the following commands supports multilevel incremental backups?

a. b. c. tar dump cpio
3. 4. 5.
True / False: An incremental backup will always back up the operating system files. True / False: It is not necessary to use the dash (-) with the option in the tar command. When did you last back up your files?
Yesterday evening, and you checked it this morning..right?!
V5.2
Student Notebook
AP
Unit 13
1.
a. b. c. d.
What is a User Private Group?

A group for users who need privacy A group which has the same name as the user; this user has this group as its primary group A group which is used for sharing files between the members of this group The "staff" group
2.
Where are the passwords of users stored? ___/etc/shadow__________
A-13
Student Notebook
Unit 14
1. What is the difference between authentication and authorization? _Authentication is how you identify yourself to the system, and authorization specifies what you can do once logged in____________ True/False: The user root can log in anywhere, anytime. True/False: PAM is the subsystem responsible for user authentication.
2. 3.
V5.2
Student Notebook
AP
Unit 15
1. True/False: Internet access is required for troubleshooting. 2. If your X server does not start, then the problem might also be:
a. b. c. d. The network The font server A full filesystem All of the above
3. SUSE Linux provides a repair tool from the Installation menu.
A-15
Student Notebook
Appendix C
1. True/False: Rack-mounted equipment is generally a little more expensive than regular, non-rack mounted equipment. You have 25 servers, each rated at 450 watt. How many tons of air conditioning do you need for this?
a. b. c. d. 38,385 3.20 11,250 None of the above
2.
3.
What should you do to limit the risk of static electricity damage to a minimum? Use wrist straps and antistatic mats when maintaining equipment
V5.2
Student Notebook
AP
Appendix D
1. True/False: 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. b. c. d. User policy Procedure handbook Security policy Administrator policy
2.
3.
What are the three dilemma factors to consider in system management? Security, ease of use, and cost
A-17
Student Notebook
Appendix E
1. What directory structure gives you access to the kernel runtime parameters? _ /proc/sys _________________________________ True/False: 2.6 kernel modules end with a .o suffix. True/False: The command make oldconfig will generate a new .config file. The command _modprobe__ loads a module and modules that it depends on.
2. 3.
4.
V5.2
Student Notebook
AP
Appendix F
1. Name the six main types of Linux usage today: a. Infrastructure solutions b. Application solutions c. Workload consolidation d. Linux clusters e. Distributed enterprise f. Desktop What is a BladeCenter? 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. 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. What are considerations when determining the architecture on which you want to run an ISV application? First is the architectures that are supported by that particular ISV and the ISVs application. Second is scalability requirements.
2.
3.
A-19
Student Notebook
V5.2
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 is IBM. The certification tests are delivered by Virtual University Enterprises (VUE) (http://www.vue.com). LPI aims to implement three levels of certification, of which the first two levels are currently ready. 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 six 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. Novell (http://www.novell.com) is the distributor of SUSE Linux, one of the leading commercial Linux distributions. They have developed their own education leading to the Novell Certified Linux Professional (Novel CLP) and Novell Certified Linux Engineer. For all four 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.
B-1
Student Notebook
IBM Training courseware

IBM Training 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 nine courses are important: 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. 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. 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. LX15 (Linux Jumpstart for UNIX System Administrators) is a course designed to jumpstart generic UNIX administrators into Linux system administration. LX22 (Linux Perl Programming) is the course that covers Perl programming. 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. 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. 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. 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 Training and selected business partners (pricing and availability may differ from country to country). For information on pricing and scheduling, contact your local IBM Training representative. IBM Training 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
B-2
V5.2
Student Notebook
AP
student is able to fully grasp a topic, and is able to apply this successfully on his Linux system(s).
From education to certification

IBMs arrangements of topics into IBMs 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 (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 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 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.
B-3
Student Notebook
Education/Certification matrix
The following table lists the required and recommended courses for each of the supported certification programs: Course LX02 LX03 LX07 LX22 LX23 LX24 LX25 LX26 CompTIA Linux+ Required Required Recomm. LPI Test 101 Test 102 Required Required Required Required Required Test 201 Required Required Required Recomm. Recomm. Red Hat Test 202 RHCT RHCE Required Required Required Required Required Required Required Required Recomm. Recomm. Recomm. Recomm.
Recomm.
Recomm. Recomm. Required
Required Required
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, where applicable. This part of the exam is not related to Linux and thus not covered in any of IBMs Linux courses. CompTIAs own education (and other education) that leads to CompTIA A+ certification may be used to obtain this knowledge. 3. ProCert (http://www.procert.com) has certified these courses as appropriate course material for preparing for LPI certification tests. This certification is only valid if all courses, including the courses that are listed here as recommended, are taken before attempting an LPI certification test. 4. IBM IT Education Services is a Red Hat Authorized Training Partner and as such allowed to teach the Red Hat courses RH033, RH133, and RH253. These courses can be used as an alternative to LX02, LX03, and LX07, respectively, to prepare for RHCT/RHCE certification. They cannot be used for other certifications, though, and these courses are not scheduled in all countries.
B-4
V5.2
Student Notebook
Uempty
Appendix C. Physical planning and maintenance

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

After completing this appendix, you should be able to: Discuss issues to be considered when planning the physical installation of the system List best practices for physical maintenance

Accountability: Checkpoint questions
C-1
Student Notebook
Appendix objectives
After completing this appendix, you should be able to: Discuss issues to be considered when planning the physical installation of the system List best practices for physical maintenance
Figure C-1. Appendix objectives
LX036.0
Notes:
C-2
V5.2
Student Notebook
Uempty
Issues in physical planning and maintenance

Weight Footprint Accessibility Power Temperature Humidity Static electricity Cleaning
50 40 30 20 10 0 10 20 30 40 50
120 100 80 60 40 20 0 20 40 60
Figure C-2. Issues in physical planning and maintenance
LX036.0
Notes: Introduction
When planning for the physical installation, several issues must considered. These are covered in the subsequent visuals.
C-3
Student Notebook
Computer room
In most cases, servers are placed in separate computer rooms Advantages
Raised floor makes it easier to keep tidy Separate air conditioning settings allows optimum environment Access control systems disallow unauthorized access to console
Disadvantages
Less accessible if console access is needed
Figure C-3. Computer room
LX036.0
Notes: Introduction
In most cases, servers are 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 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
C-4 Linux System Administration I Copyright IBM Corp. 2001, 2009
V5.2
Student Notebook
Uempty
sophisticated biometric devices). This helps keeping unauthorized people out. This is important since 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 or rebooting a hung system), then these systems are generally less accessible than if they were standing under your desk.
C-5
Student Notebook
Rack mounted versus lots of boxes on shelves

Industry standard (19") racks can store a variety of IT-related hardware
Servers and server blade enclosures Network equipment Monitors, keyboards, and keyboard/video/mouse (KVM) switch UPS Significantly reduced footprint Easy to limit physical access to system Easy to keep tidy Looks good
Advantages:
Disadvantages:
Rack-mounted equipment usually more expensive Physical access usually less convenient A full rack might need floor reinforcement
Figure C-4. Rack mounted versus lots of boxes on shelves
LX036.0
Notes: Introduction
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, (keyboard/video/mouse (KVM) 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
C-6
V5.2
Student Notebook
Uempty
vertical position. This saves you a lot of space in (or next to) your rack, while still allowing console access to a system. 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 stand-alone 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 stand-alone 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 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 youve got a floor plate attached to the front of the rack. Without that floor plate attached, theres 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.
Copyright IBM Corp. 2001, 2009 Appendix C. Physical planning and maintenance C-7
Student Notebook
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 W Europe: 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-operated Keeps power up for 10-30 minutes
Figure C-5. Power considerations
LX036.0
Notes: Introduction
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 watts. 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 pop or blow.
C-8
V5.2
Student Notebook
Uempty
In the US, the end-user power grid operates at 120 volts and is typically protected by 20A fuses or breakers. This means that the total power consumption of all devices in a circuit might not exceed 2400 watts. In Europe, the end-user power grid operates at 220-240 volts 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 watts.
Power rating
The power rating of a device (measured in watts) is the maximum amount of power drawn. A typical device (except, perhaps, a light bulb) in normal operation uses 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. Also, for the first few seconds, a lot of devices actually use their maximum power consumption to spin up disk drives and so forth. Power companies always try to give you a clear, alternating current power feed. Various influences beyond their control, such as lightning, might alter the clear sine wave that you expect to receive. This might damage your equipment or wear it out more quickly. To protect against such, you might consider using Surge Arresters and/or Uninterruptible Power Supplies.
Power protection
A Surge Arrester protects you from sudden surges (such as these caused by lightning) in the power feed, but does not keep your equipment powered if the power supply fails altogether. A UPS contains a battery which keeps 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.)
C-9
Student Notebook
Air conditioning
Might need air conditioning for maintaining
Stable temperature Constant humidity
Ideal temperature: 17-20C (64-68F)

Unstable temperature may lead to physical damage because of expansion/contraction of components High temperature might lead to overheating of internal components
Ideal humidity: 40%-60%

Low humidity might cause buildup of static electricity High 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 cooling One "ton" equals 12,000 BTU/hr
Figure C-6. Air conditioning
LX036.0
Notes: Introduction
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
C-10 Linux System Administration I
V5.2
Student Notebook
Uempty
damage. If the humidity is too high, then condensation might occur, which might lead to short-circuiting of equipment. Air conditioning capacity is expressed in British Thermal Units (BTU/hr), 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, which equals about 3500 watts of heat - the heat generated by about 10 medium-sized servers. Coincidentally, in moderate climates, it takes about 3500 watts 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.
C-11
Student Notebook
Fire detection and suppression system

Make sure that you can detect a fire early
Smoke and carbon monoxide detector Also put detectors under raised floors and above lowered ceilings
Consider fire suppression methods

Water? CO2? Inert gas? Consult local fire department
Consider installing a master switch which terminates all power to your computer room immediately
Figure C-7. Fire detection and suppression system
LX036.0
Notes: Introduction
Your computer room almost certainly needs 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.
V5.2
Student Notebook
Uempty
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.
C-13
Student Notebook
Best practices
Be aware of static electricity when replacing components
Ground all components properly Touch outer case and/or grounded connector before going inside Store unused components in static-free bags Do not touch electrical circuits if you can avoid it Consider using wrist-straps and antistatic 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
Figure C-8. Best practices
LX036.0
Notes: Introduction
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
C-14 Linux System Administration I Copyright IBM Corp. 2001, 2009
V5.2
Student Notebook
Uempty
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. - 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
C-15
Student Notebook
Checkpoint
1. True/False: Rack-mounted equipment is generally a little more expensive than regular, non-rack mounted equipment. You have 25 servers, each rated at 450 watt. How many tons of air conditioning do you need for this?
a. b. c. d. 38,385 3.20 11,250 None of the above
2.
3.
What should you do to limit the risk of static electricity damage to a minimum?
Figure C-9. Checkpoint
LX036.0
Notes:
1. 2. 3.
V5.2
Student Notebook
Uempty
Appendix summary
After completing this appendix, you should understand: 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.
Figure C-10. Appendix summary
LX036.0
Notes:
C-17
Student Notebook
V5.2
Student Notebook
Uempty
Appendix D. Policies and procedures

This optional appendix talks about the policies and procedures that most organizations have in place to manage their system management.

After completing this appendix, you should be able to: Discuss the need for policies and procedures Discuss user and administrator policies Discuss system management procedures

D-1
Student Notebook
Appendix objectives
After completing this appendix, you should be able to: Discuss the need for policies and procedures Discuss user and administrator policies Discuss system management procedures
Figure D-1. Appendix objectives
LX036.0
Notes:
D-2
V5.2
Student Notebook
Uempty
About your systems

The systems you manage are not your own Paid for by management Intended for use by the users oh, and also. . . You are expected to implement and manage the system so that it is
100% secure Extremely easy to use And costs nothing...
Figure D-2. About your systems
LX036.0
Notes: Introduction
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.
D-3
Student Notebook
The dilemma
Ease of use
Secure
Economical
Figure D-3. The dilemma
LX036.0
Notes: Introduction
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. 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.
D-4
V5.2
Student Notebook
Uempty
Policies
Policies help you
Determine the balance between security, ease of use, and cost Set the expectancy level of users Set the expectancy level of system administrators Set the expectancy level of management Determine what is acceptable use and what is not
In most jurisdictions, regular law has not yet caught up with advances in ICT technology
In that case, policies "augment" the law
Typical policies:
User policy Administrator policy Security policy
Figure D-4. Policies
LX036.0
Notes: Introduction
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. However, 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 IT 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, this is so in a large number of countries. In these cases,
Copyright IBM Corp. 2001, 2009 Appendix D. Policies and procedures D-5
Student Notebook
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.
D-6
V5.2
Student Notebook
Uempty
User policy
Describes how users can get access to the system
Hostnames, login procedures How to contact the help desk
Describes what the users can expect from the system

Applications that are available/supported Privacy policy Service times Quota policy
Describes how users can obtain support

Telephone, e-mail, personal
Describes what is expected of the users

Password policy Usage policy
Users need to be aware of user policy and express consent before access to systems is granted
Figure D-5. User policy
LX036.0
Notes: Introduction
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.
D-7
Student Notebook
- How users can obtain support: via telephone, e-mail, or personal contact, and when this support is available. - 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 contracts. 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.
D-8
V5.2
Student Notebook
Uempty
Administrator policy
Describe what is expected of administrators
Education level Confidentiality Availability
Describe usage of administrator privileges

Only su to root if really needed; use sudo otherwise Root password maintenance
Describe what to do when an administrator has to violate other policies (for example, privacy) Administrators need to be aware of administrator policy and express consent before administrator access to systems is granted
Figure D-6. Administrator policy
LX036.0
Notes: Introduction
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.
D-9
Student Notebook
- If possible, the users are warned beforehand. If that is not possible, users are informed afterwards. 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.
D-10 Linux System Administration I
V5.2
Student Notebook
Uempty
Security policy
Describes the level of security that needs to be applied to various systems and applications Describes the technical measures taken to reach that level of security:
Authentication Authorization Logging Detection Response
Tradeoff: cost of security versus cost of data
Figure D-7. Security policy
LX036.0
Notes: Introduction
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.
D-11
Student Notebook
Procedure handbook
A procedure handbook describes common system administration tasks Advantages:
Reduces errors Prevents forgetting steps Helps train new administrators
Common procedures:
Adding/removing a workstation/server Adding/removing user accounts Adding/removing printers Backups Regular/emergency power down of important systems Upgrading the operating system or critical software
Typically a living, online document
Figure D-8. Procedure handbook
LX036.0
Notes: Introduction
Another document that you might want to create is a procedure handbook. This document describes common system administration tasks and helps you prevent errors. Please note, a procedure handbook is typically a living, online document which is updated when procedures change. 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
D-12 Linux System Administration I Copyright IBM Corp. 2001, 2009
V5.2
Student Notebook
Uempty
Management of system management

The system management process needs to be managed too Things to consider:
Testing procedures Change management Service level management Management of licenses Management of maintenance contracts Management of contractors Disaster planning Hiring/Firing/Training system administrators Purchasing guidelines
Figure D-9. Management of system management
LX036.0
Notes: Introduction
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.
D-13
Student Notebook
- 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 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 in an accident and end up in the 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.
V5.2
Student Notebook
Uempty
Checkpoint
1. True/False: 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. b. c. d. User policy Procedure handbook Security policy Administrator policy
2.
3.
What are the three dilemma factors to consider in system management? ______________________________________________
Figure D-10. Checkpoint
LX036.0
Notes:
1. 2. 3.
D-15
Student Notebook
Appendix summary
Having completed this appendix, you should understand: 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.
Figure D-11. Appendix summary
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Appendix E. Kernel compilation and configuration

This appendix teaches you why and how to recompile your kernel and how to configure kernel parameters.

After completing this appendix, you should be able to: 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

References
Linux man pages SUSE Linux 10 Installation and Administration Guide Red Hat Enterprise Linux V5 Release Notes Fedora Core 7 Release Notes http://www.kernel.org/ The Linux Kernel Archives http://www.linux.org/ The Linux Home Page at Linux Online http://www.gnu.org/software/grub GNU GRUB - GNU Project - Free Software Foundation (FSF)
E-1
Student Notebook
Appendix objectives
After completing this appendix, you should be able to: 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
Figure E-1. Appendix objectives
LX036.0
Notes:
E-2
V5.2
Student Notebook
Uempty
Why kernel compilation

Standard distribution kernel may not be adequate
Specific hardware not supported Too much hardware support
Consumes memory System startup takes longer
Upgrade to newer version Experimental/development kernel Fun!
Warning: Building a custom kernel is not supported by the Enterprise distributions!

Figure E-2. Why kernel compilation?
LX036.0
Notes: Introduction
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 can 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!
E-3
Student Notebook
Support disclaimer
Each distributor and IBM provides support to their customers based on the service level agreements selected by their customers. Please check the distribution/IBM Web pages for details on service level agreements. The typical support for Linux kernels on each distribution is that they only support the Linux binary kernel that was shipped with the release. Modifications/patches to the kernel source are not supported. This means that a system running a home-compiled kernel generally doesnt receive support unless you can boot it into the original kernel, and show that the problem exists there too. Thus, always keep the original kernel around.
E-4
V5.2
Student Notebook
Uempty
Compilation steps
1.
-
Install kernel source

From distribution CD-ROM From Internet
2. 3. 4. 5. 6. 7.
Create configuration file .config Remove old temporary files Compile kernel image and kernel modules Install kernel image and kernel modules Configure boot loader Reboot system
Figure E-3. Compilation steps
LX036.0
Notes: Introduction
The visual shows the high level steps for kernel compilation. First, you have to install the kernel source, usually in /usr/src directory structure. 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 creating a .config file. Configuring the kernel is accomplished by answering a lot of questions about whether support for a certain adapter or device should be compiled in (static) or not (modular, or not included). After this, you need to clean the kernel source tree of any old temporary files and recreate dependency information. Then the kernel compilation process can begin. This involves compiling a new kernel image and compiling and installing the kernel modules.
E-5
Student Notebook
After compilation, your boot loader has to be configured so that it boots this kernel instead of the standard kernel. After that, reboot your system, and it boots the new kernel.
E-6
V5.2
Student Notebook
Uempty
Installing kernel source: SLES

From SLES distribution:
Use rpm or yast to install the kernel sources package # rpm -Uvh kernel-source-version.rpm
Figure E-4. Installing kernel source: SLES
LX036.0
Notes:
Introduction
Each distribution contains kernel source RPMs that match the distributions binary kernel. These are complete source trees. To create the kernel sources, the distributors start with open source kernels, as well as other patches required by the distribution. The binary and kernel sources are located on the installation medium for the distribution or downloaded from the distributor over the network. Either can be installed using the rpm or yast/yast2 commands. An example of a SUSE Linux Enterprise Server binary kernel and source RPMs for a Intel system includes: - kernel-default-2.6.16_rc1_git3-7 - kernel-xen-2.6.16_rc1_git3-7 - kernel-source-2.6.16_rc1_git3-7
Copyright IBM Corp. 2001, 2009 Appendix E. Kernel compilation and configuration E-7
Student Notebook
Kernel source installation location

Once the kernel source is installed onto the system, the files are located in the /usr/src directory structure. For example, linux-2.6.16-rc1-git3-7 will be found in the directory /usr/src/linux-2.6.16-rc1-git3-7. In addition, the symbolic link /usr/src/linux will be pointing to the highest version of the Linux source code installed on the system.
E-8
V5.2
Student Notebook
Uempty
Installing kernel source: RHEL/Fedora

From distribution source CDs:
Use rpm to install the kernel source package # rpm -Uvh kernel-version.src.rpm
Prepare the kernel sources using the commands:

RHEL # cd /usr/src/redhat/SPECS # rpmbuild -bp --target $(arch) kernel.spec Fedora $ cd ~/rpmbuild/SPECS $ rpmbuild -bp --target $(arch) kernel.spec
Figure E-5. Installing kernel source: RHEL/Fedora
LX036.0
Notes: Introduction
Each distribution contains kernel source rpms that match the distributions binary kernel. These are complete source trees. To create the kernel sources, the distributors start with open source kernels, as well as other patches required by the distribution. The binary and kernel sources are located on the installation medium for the distribution (the SRPMS directory on the appropriate SRPMS CD ISO image) or downloaded from the distributor over the network. Either can be installed using the rpm command. An example of a Red Hat Enterprise Linux binary kernel and source RPMs for a Intel system: - kernel-smp-2.6.9-27.EL - kernel-2.6.9-27.EL - kernel-2.6.9-34.EL.src.rpm
E-9
Student Notebook
Red Hat kernel source installation location

Once the kernel source is installed onto the system, the files are located in the /usr/src directory structure. For example, RHEL 4 U3, kernel-2.6.9-27.EL will be found in the directory /usr/src/redhat structure. Once installed, the source needs to be created by using the following commands: # cd /usr/src/redhat/SPECS # rpmbuild -bp --target $(arch) kernel.spec The resulting source code can be found in the directory structure: - /usr/src/redhat/BUILD/kernel-version/linux-version
Fedora kernel source installation location

For Fedora, it is recommended that the kernel be built as a normal user. In order to compile a kernel, the certain tools need to be loaded on Fedora. Use the following commands to install the rpmbuild tools: $ su -c 'yum install fedora-rpmdevtools' $ fedora-buildrpmtree The sources can be created by using the following commands: $ cd ~/rpmbuild/SPECS $ rpmbuild -bp --target $(arch) kernel.spec The resulting source code can be found in the directory structure: - ${HOME}/rpmbuild/BUILD/kernel-<version>/
E-10 Linux System Administration I
V5.2
Student Notebook
Uempty
Installing kernel source: Internet

From http://kernel.org:
Download linux-version.tar.gz or linux-version.tar.bz2 Unpack source in the /usr/src directory # cd /usr/src # tar -zxvf /root/linux-version.tar.gz # tar -jxvf /root/linux-version.tar.bz2
Figure E-6. Installing kernel source: Internet
LX036.0
Notes: Introduction
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).
E-11
Student Notebook
Patching the kernel

Changes to the kernel are typically distributed as patches
A patch lists only the difference between the old and the new version of the code; it does not contain unmodified code
Patches are generated with the diff command

# diff -u oldfile.c newfile.c > /tmp/file.diff # diff -urN olddirtree newdirdtree > /tmp/tree.diff
Use the patch command to apply a patch to your sourcetree

# patch -p0 < linux-dummy-patch patching file Makefile ...
Use the -R option to remove a previous applied patch
Figure E-7. Patching the kernel
LX036.0
Notes: Introduction
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
1 Not entirely true. A patch file typically contains the few lines of unmodified code that surrounds the modified code. This means that if the line numbers dont match exactly, the patch program can find the correct lines to patch by looking at this unmodified context code.
V5.2
Student Notebook
Uempty
dont overlap. In almost all cases, the resulting patch files can be applied in any order, independent of each other. - 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.6.16.14 is about 50 MB, while the patch to go from 2.6.16.13 to 2.6.16.14 is only about 40 K.
Generating patches
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.
Applying patches
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. 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.
Reversing patches
It is also possible to remove or reverse-apply a patch. This is done using the -R option.
E-13
Student Notebook
Configuring the kernel compile

Configure all kernel compilation options Configuration stored in .config file Editing .config is difficult Use the make utility instead:
make config make menuconfig make xconfig (command line) (ncurses based: much easier) (QT-based GUI)
Figure E-8. Configuring the kernel compile
LX036.0
Notes: Introduction
Before you start the compilation process you have to determine what support should be compiled. For this, you need to know your hardware, and you need to know what function your system fulfills. For instance, your system can only act as a firewall if firewall support is compiled into the kernel.
Configuration file
The kernel configuration information is stored in a file named .config in the distribution specific directory: - SLES: /usr/src/<linux-version> - RHEL: /usr/src/redhat/BUILD/<kernelversion>/<linux-version> - Fedora: ${HOME}/rpmbuild/BUILD/<kernelversion>/
V5.2
Student Notebook
Uempty
To properly configure the kernel parameters a number of make command options are available (distribution specific). There are roughly 1600 kernel configuration parameters which makes hand editing the .config file difficult.
Kernel configuration methods

There are multiple methods of creating a kernel configuration file to use during the kernel build process. Run these commands from the distribution specific directory listed above: - Creating a .config file from the currently running kernel image: Create a .config file and base the kernel configuration from that file: SLES # zcat /proc/config.gz >/usr/src/linux/.config # make oldconfig RHEL/Fedora # cp /lib/modules/<kernelversion>/build/.config \ /<Source_location>/.config # make oldconfig - Creating a .config file from scratch: Create a .config file from answering a series of questions (~1600) from the shell prompt: # make config Create a .config file from selecting options from a nCurses menu: # make menuconfig Create a .config file from selecting options from a X window menu: # make xconfig Note: During the configuration process there are three options: - Y - Include this option in the kernel - N - Do not support this option in the kernel - M - Include this option in the kernel as a module The default (recommended) option will appear capitalized during the configuration process. When in doubt, use the recommended setting.
E-15
Student Notebook
Kernel modules
Certain kernel parts can be configured as modules Separate files in /lib/modules/<KERNELVERSION>, not in kernel image
/lib/modules/ùname r`/kernel/drivers/net/e100.ko
Module advantages:
Do not consume memory unless actually used Drivers can be reconfigured during uptime System boot is faster
Module disadvantages:
Loading costs a little time
Use modules only for hardware which is not needed directly at system boot, or create an Initial RAM Disk (initrd) containing the needed modules
Figure E-9. Kernel modules
LX036.0
Notes: Introduction
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.
V5.2
Student Notebook
Uempty
You can also create an Initial RAM 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 GRUB or LILO. The kernel then loads the modules off this Initial RAM Disk and then mounts the proper root disk. To create an initial root disk, use the mkinitrd command. Modules are stored in /lib/modules/<kernelversion>, where the version number is determined in the Makefile found in the distribution specific source directory structure. 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.
Kernel module files

Kernel module files are located in the following directory structure: - /lib/modules/uname -r For example, the kernel module for the Intel Ethernet Express network adapter is the e100.ko. This module is located at: - /lib/modules/uname -r/kernel/drivers/net/e100.ko Note: 2.6 Kernel modules end with a .ko suffix. 2.4 Kernel modules end with a .o suffix.
E-17
Student Notebook
Compiling the kernel: SLES

Extra version/local version variable
# uname r 2.6.16-rc1-git3-7-default # cd /usr/src/linux # make menuconfig
Navigate to the General Setup menu and modify the local version variable
Kernel build
# cd /usr/src/linux # make j <N> clean modules vmlinux bzImage \ 2>&1 | tee kernelbuild.out
Files created
/usr/src/linux/vmlinux /usr/src/linux/i386/boot/bzImage /usr/src/linux/System.map Kernel modules in various sub-directories of /usr/src/linux
Figure E-10. Compiling the kernel: SLES
LX036.0
Notes: Introduction
Kernel images may either be a compressed kernel (bzImage - vmlinuz) or uncompressed (vmlinux). The benefits of a compressed kernel is to save memory space (not a big issue with todays system memory configurations).
Local version variable

To differentiate the kernel you are going to build from the currently running kernel, the local version variable in the .config file should be modified. To identify the currently running kernel, run the uname -r command: # uname -r 2.6.16-rc1-git3-7-default
V5.2
Student Notebook
Uempty
Modify the local version variable to add -test to the uname -r output: # make menuconfig Navigate to the General Setup menu and modify the local version variable.
Kernel compilation
Once the kernel has been configured, use the following commands: # cd /usr/src/linux # make j <N> clean modules vmlinux bzImage 2>&1 | tee kernelbuild.out Note: The value of N should be two times the number of CPUs.
Files created
Depending on which kernel build commands were used, the following files will be created: - /usr/src/linux/vmlinux - /usr/src/linux/i386/boot/bzImage - /usr/src/linux/System.map - Kernel modules in various sub-directories of /usr/src/linux
E-19
Student Notebook
Installing the kernel: SLES

Install the kernel
# make install
Install modules
# make modules_install
Create Initial RAM Disk if needed

# mkinitrd -k <kernel-version> -i <initrd-version>
Configure GRUB or LILO to include new kernel
Figure E-11. Installing the kernel: SLES
LX036.0
Notes: Introduction
Installation and booting from a new kernel image requires the following steps: 1) Copy the new kernel image and support files to /boot: # make install 2) Install kernel modules: # make modules_install 3) Create an Initial RAM Disk if needed: # mkinitrd -k <kernel-version> -i <initrd-version> 4) Modify the boot loader configuration file
V5.2
Student Notebook
Uempty
Compiling the kernel: RHEL/Fedora

Extra version/local version variable
# uname r 2.6.9-27.ELsmp # cd /usr/src/redhat/BUILD/<kernel-version>\ /<linux-version> # make menuconfig
Navigate to the General Setup menu and modify the local version variable
Kernel build
# cd /usr/src/redhat/BUILD/<kernel-version>\ /<linux-version> # rpmbuild bb -target $(arch) kernel-version.spec
Files created
/usr/src/redhat/RPMS/$arch/kernel-version.rpm
Figure E-12. Compiling the kernel: RHEL/Fedora
LX036.0
Notes: Introduction
Kernel images may either be a compressed kernel (bzImage - vmlinuz) or uncompressed (vmlinux). The benefits of a compressed kernel is to save memory space (not a big issue with todays system memory configurations). Note: The remaining information is for a kernel build on RHEL. For Fedora, modify the working directory to: - ${HOME}/rpmbuild/BUILD/kernel-<version>/
Local version variable

To differentiate the kernel you are going to build from the currently running kernel, the local version variable in the .config file should be modified. To identify the currently running kernel, run the uname -r command: # uname -r
Student Notebook
2.6.9-27.ELsmp
Modify the local version variable to add -test to the uname -r output: # cd /usr/src/redhat/BUILD/<kernel-version>\ /<linux-version> # make menuconfig Navigate to the General Setup menu and modify the local version variable.
Kernel compilation
Once the kernel has been configured, use the following commands: # cd /usr/src/redhat/BUILD/<kernel-version>\ /<linux-version> # rpmbuild bb -target $(arch) kernel-version.spec
Files created
Depending on which kernel build commands were used, the following files will be created: - /usr/src/redhat/RPMS/$arch/<kernel-version>.rpm
V5.2
Student Notebook
Uempty
Installing the kernel: RHEL/Fedora

Install the kernel
# rpm ivh /usr/src/redhat/RPMS/$(arch)\ /kernel-version.rpm
Configure GRUB or LILO to include new kernel
Figure E-13. Installing the kernel: RHEL/Fedora
LX036.0
Notes:
Installation and booting from a new kernel image requires the following steps: 1) Install the kernel RPM: # rpm ivh /usr/src/redhat/RPMS/$(arch)/<kernel-version>.rpm 2) Modify the boot loader configuration file
E-23
Student Notebook
Reboot system and start new kernel

Ctrl-Alt-Delete or shutdown -r now Select new kernel in boot loader Check kernel boot messages for errors
With Shift-PgUp With dmesg In /var/log/messages
Check functionality of kernel

Amount of memory detected All devices working properly? Performance?
Figure E-14. Reboot system and start new kernel
LX036.0
Notes: Introduction
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 can 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.
V5.2
Student Notebook
Uempty
Loading modules
Modules can be loaded manually
insmod lsmod rmmod depmod Loads a single module Lists all loaded modules Removes a single module Determines module dependencies (in: /lib/modules/<linux_version>/modules.dep) Loads a module and modules it depends on Displays information about a module
modprobe modinfo
Modules are loaded dynamically when the kernel discovers it needs to, based on information in /etc/modules.conf More information in /usr/src/linux/Documentation/modules.txt
Figure E-15. Loading modules
LX036.0
Notes: Introduction
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/modules.conf, which might contain module configuration options.
E-25
Student Notebook
Another 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 is covered in a few pages.
V5.2
Student Notebook
Uempty
Configuring the kernel

Certain kernel configuration options can be set after kernel compile Some possibilities for configuration:
When kernel image boots
Amount of memory used

Root filesystem to mount When modules are loaded
Hardware present, hardware settings

Through /proc/sys mechanism
Software functions, such as IP forwarding
Figure E-16. Configuring the kernel
LX036.0
Notes: Introduction
The .config file only configures the kernel compilation process, and is not used afterwards. However, once the kernel has been installed, you 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
E-27
Student Notebook
Configuring the kernel at boot time

Done by adding arguments to the kernel line in the boot manager
GRUB: add to kernel line LILO: use append statement
Examples:
mem=128M Identify amount of memory to kernel root=/dev/hda3 Identify root FS to mount ro Mount root FS readonly init=/sbin/init First program to run initrd=/initrd-2.6.9-27.EL.img Use the initial RAM disk image called initrd-2.6.9-27.EL.img
For more information:

Manual page for bootparam /usr/src/linux/Documentation/kernel-parameters.txt (SLES)
Figure E-17. Configuring the kernel at boot time
LX036.0
Notes: Introduction
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 cant be accessed directly, you need to work with your boot loader to achieve this. For example, to direct the kernel to use only 128 MB of memory: - 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 /vmlinuz-2.6.9-27.EL ro root=/dev/VolGroup00/LogVol00 rhgb quiet mem=128M initrd /initrd-2.6.9-27.EL.img
- 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/vmlinuz
E-28 Linux System Administration I Copyright IBM Corp. 2001, 2009
V5.2
Student Notebook
Uempty
label=linux root=/dev/hda5 append="mem=128M" read-only
Argument examples
There are several parameters that can be useful here. Some of these, and their usage, are: Table 1: Common kernel parameters Parameter Description 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. Failing to use the capital M causes the kernel to use the number of bytes specified, which immediately mem=<memory size>M leads to a kernel panic if it is too small. Note: 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. 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. This value 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. 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.
root=<root device>
ro
init=<progam to start>
Student Notebook
Table 1: Common kernel parameters Parameter Description initrd=<Initial RAM disk> Specifies the Initial RAM Disk to use.
V5.2
Student Notebook
Uempty
Configuring modules at load time

Specify in /etc/modprobe.conf # cat /etc/modprobe.conf alias eth0 eepro100 alias eth1 eepro100 options eth0 irq=9 options eth1 irq=10 alias identifies the module which implements a device Options are specific for each module
Use modinfo to obtain specific information
Pre-install, install, and post-install execute scripts when loading a module Pre-remove, remove, and post-remove execute scripts when unloading a module
Figure E-18. Configuring modules at load time
LX036.0
Notes: Introduction
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 shown in the visual, 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.
E-31
Student Notebook
- 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. - 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 allow 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.
V5.2
Student Notebook
Uempty
Configuring the running kernel

Certain kernel settings can be changed while running All these settings have an entry somewhere in /proc/sys Example: Setting up IP-forwarding # cat /proc/sys/net/ipv4/ip_forward 0 # echo 1 > /proc/sys/net/ipv4/ip_forward sysctl command gives easy interface to this # sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 1 # sysctl -w net.ipv4.ip_forward=0 net.ipv4.ip_forward = 0
The sysctl -a options prints out all current settings, the -p option reads settings from /etc/sysctl.conf (RHEL/Fedora) or /etc/sysconfig/sysctl (SUSE Linux)
Figure E-19. Configuring the running kernel
LX036.0
Notes: Introduction
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, /etc/sysctl.conf or /etc/sysconfig/sysctl. As part of the bootup scripts, the sysctl -p command is executed. This reads all settings from /etc/sysctl.conf or /etc/sysconfig/sysctl and applies them. With the sysctl command you can also list and change settings manually, but this is not often used.
Student Notebook
Checkpoint
1. What directory structure gives you access to the kernel runtime parameters? ___________________________________________ True/False: 2.6 kernel modules end with a .o suffix. True/False: The command make oldconfig will generate a new .config file. The command ___________ loads a module and modules that it depends on.
2. 3.
4.
Figure E-20. Checkpoint
LX036.0
Notes:
1. 2. 3. 4.
V5.2
Student Notebook
Uempty
Exercise: Kernel configuration
What you will do in this exercise: Perform various kernel build activities
Figure E-21. Exercise: Kernel configuration
LX036.0
Notes:
E-35
Student Notebook
Appendix summary
Having completed this appendix, you should know: Kernel compilation is sometimes desirable, but not supported by the Enterprise distributions Kernel sources are available from a variety of locations. One location is from the distribution CDs:
SLES (Main CDs) RHEL/Fedora (SRC CDs)
Configuring the kernel can be accomplished by using one of the following commands:
make make make make oldconfig menuconfig config xconfig
Compiling the kernel differs by distribution Installing the kernel differs by distribution
Figure E-22. Appendix summary
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Exercise: Kernel compilation and configuration What this exercise is about

This lab provides students with a hands on experience configuring, building, and installing a Linux kernel.

After completing this exercise you should have experience with: Installing kernel sources Compiling the kernel Installing the kernel
Introduction
In this exercise, you will be performing various kernel build activities.
Requirements
This workbook A workstation with Fedora, RHEL, or SLES installed
E-37
Student Notebook
Exercise instructions - SLES

Preface
All exercises of this chapter depend on the availability of specific equipment in your classroom. The hints provided for locating documentation on particular Web pages were correct when this course was written. By nature, Web pages tend to change over time, so ask your instructor if you have trouble navigating the Web sites. A computer system with a connection to the World Wide Web and a Web browser is recommended by not required.
Preparation
Before you can complete this exercise, certain application RPM files and their dependencies must be installed. Here is the list of RPM files you need to install: SLES - kernel-source-<version>.i586.rpm qt3-devel-<version>.rpm
Record currently running kernel image version

__ 1. Record the version information for the currently running kernel image: # uname -r _ _______________________
Installing the kernel sources

__ 2. Using the YaST Control Center, click the Software Management icon:
V5.2
Student Notebook
Uempty
__ 3. From the Filter pull down dialog box, select the word Search.
__ 4. In the Search dialog box, enter kernel-source and click the Search button. The kernel-source package will then appear in the right-hand pane. Check the checkbox next to kernel-source package to queue it for installation.
__ 5. Check the Autocheck button in the lower right corner of the window.
__ 6. In the Search dialog box, enter qt3-devel and click the Search button. The qt3-devel related packages will then appear in the right hand pane. Check the
E-39
Student Notebook
checkbox next to qt3-devel to queue it for installation. Next, click the Accept button in the lower right corner of the YaST Control Center to install the queued packages.
__ 7. Next, click the Accept button in the lower right corner of the YaST Control Center to install the queued packages. An Automatic Changes dialog box will appear, click the Continue button.
__ 8. Once the installation completes, exit the YaST Control Center by clicking the Close button in the lower right hand corner.
V5.2
Student Notebook
Uempty
Configuring the kernel

__ 9. Change the working directory to the kernel source directory. # cd /usr/src/linux __ 10. Clean the kernel development tree of all distribution-dependent files. # make mrproper __ 11. Generate a /usr/src/linux/.config file from the current configuration: # zcat /proc/config.gz > /usr/src/linux/.config __ 12. After copying, run the make oldconfig command to make sure that the .config file is correct. # make oldconfig __ 13. Modify the kernel configuration to use the local version variable setting of -lx03: # make menuconfig General Setup -> Select -> Local version - append to kernel release -> Select -> -lx03 -> Ok -> Exit Note: It is also possible to change the local version by either using make config, or make xconfig. Steps to get to the local version variable will differ between the type of configuration program called. __ 14. Verify the Local version variable was changed in the kernel configuration file. # grep lx03 /usr/src/linux/.config
Compiling the kernel

__ 15. Compile the kernel using the following make command: # make clean bzImage modules 2>&1 | tee kernelbuild.out
Installing the kernel

__ 16. Copy the new kernel image and support files to /boot: # make install Note: This step will; copy the kernel image, support files, update the menu.lst configuration file, and create an initrd file for the kernel. __ 17. Install kernel modules: # make modules_install
E-41
Student Notebook
__ 18. Create an initrd: # mkinitrd -k 2.6.16.16-1.6-lx03 -i /boot/initrd-2.6.16.16 -1.6-lx03.img __ 19. Modify /boot/grub/menu.lst to include new initrd image: # vi /boot/grub/menu.lst
Reboot the system using the new kernel image

__ 20. Shutdown and reboot the machine: # reboot __ 21. During the reboot, the default kernel selection will be the kernel image ending with -lx03. Note: During the make install command, the file /boot/vmlinuz was symbolically linked to the new kernel image file. The same was done for /boot/initrd. __ 22. Record the version information for the currently running kernel image: # uname -r _______________________________
Documenting your changes

__ 23. Document any changes that you made in Appendix A of the exercise guide.
END OF EXERCISE - SLES
V5.2
Student Notebook
Uempty
Exercise instructions - RHEL

Preface
Preparation
Before you can complete this exercise, certain application RPM files and their dependencies must be installed. Here is the list of RPM files you need to install: RHEL - kernel-<version>.src.rpm qt-devel-<version>.rpm - or add KDE Software Development package

__ 1. Record the version information for the currently running kernel image: # uname -r _______________________________

__ 2. Install the kernel sources from the distribution media. # # # # # mount 10.0.0.1:/export/rhe51s /mnt/server cd /mnt/server/Server/RPMS rpm -ivh qt-devel-<version>-i386.rpm mount 10.0.0.1:/export/files/mnt/files rpm -ivh /mnt/files/kernel- <version>.src.rpm
Create the kernel source directory __ 3. Create the kernel source directory. # cd /usr/src/redhat # rpmbuild -bp --target $(arch) /SPECS/kernel-<version>.spec Note: The resulting source code can be found in the directory structure: /usr/src/redhat/BUILD/kernel-<version>/linux-<version>
E-43
Student Notebook
Configure the kernel

__ 4. Change the working directory to the kernel source directory. # cd ../BUILD/kernel-<version>linux-<version> __ 5. Clean the kernel development tree of all distribution-dependent files. # make mrproper __ 6. Modify the kernel configuration to use the Local Version variable setting of -lx03: # make menuconfig General Setup -> Select -> Local version - append to kernel release -> Select -> -lx03 -> Ok -> Exit -> Yes Note: It is also possible to change the local version by either using make menuconfig, or make xconfig. Steps to get to the local version variable will differ between the type of configuration program called. __ 7. Verify the Local version variable was changed in the kernel configuration file. # grep lx03 .config

__ 8. Compile the kernel using the following make command: # cd /usr/src/redhat # rpmbuild bb -target $(arch) ./SPECS/kernel-<version>.spec

__ 9. Installing the kernel rpm: # rpm ivh ./RPMS/$(arch)/kernel-<version>.rpm

__ 10. Shutdown and reboot the machine: # reboot __ 11. During the reboot, the default kernel selection will be the kernel image ending with -lx03. __ 12. Record the version information for the currently running kernel image: # uname -r ________________________
END OF EXERCISE - RHEL
V5.2
Student Notebook
Uempty
Exercise instructions - Fedora

Preface
Preparation
Before you can complete this exercise, certain application RPM files and their dependencies must be installed. Here is the list of RPM files you need to install: Fedora kernel-<version>.src.rpm qt-devel-<version>.rpm fedora-rpmdevtools-<version>.rpm

__ 1. Record the version information for the currently running kernel image: # uname -r _______________________________

__ 2. Prepare the rpm build tree and install the kernel sources from the distribution media. # # # # # # mount 10.0.0.1:/export/fedo8 /mnt/server rpm -ivh /mnt/server/Packages/qt-devel*.rpm mount 10.0.0.1:/export/files /mnt/files rpm -ivh /mnt/files/kernel-<version>.src.rpm rpm -ivh /mnt/files/fedora-rpmdevtools fedora-buildrpmtree
Create the kernel source directory __ 3. Create the kernel source directory. # cd ~/rpmbuild/SPECS # rpmbuild -bp --target $(arch) kernel-<version>.spec Note: The resulting source code can be found in the directory structure: ${HOME}/rpmbuild/BUILD/kernel-<version>/linux-<version>
E-45
Student Notebook
Configure the kernel

__ 4. Change the working directory to the kernel source directory. # cd ~/rpmbuild/BUILD/kernel-<version>/linux-<version> __ 5. Clean the kernel development tree of all distribution-dependent files. # make mrproper __ 6. Modify the kernel configuration to use the Local Version variable setting of -lx03: # make menuconfig General Setup -> Select -> Local version - append to kernel release -> Select -> -lx03 -> Ok -> Exit -> Yes Note: It is also possible to change the local version by either using make config, or make xconfig. Steps to get to the local version variable will differ between the type of configuration program called. __ 7. Verify the Local version variable was changed in the kernel configuration file. # grep lx03 .config

__ 8. Compile the kernel using the following rpmbuild command: # cd ~/rpmbuild/BUILD/kernel-<version>/linux-<version> # rpmbuild bb -target $(arch) ~/rpmbuild/SPECS/kernel-<version>.spec

__ 9. Installing the kernel rpm: # rpm ivh ~/rpmbuild/RPMS/$(arch)/kernel-<version>.rpm

__ 10. Shutdown and reboot the machine: # reboot __ 11. During the reboot, the default kernel selection will be the kernel image ending with -lx03. __ 12. Record the version information for the currently running kernel image: # uname -r ________________________
END OF EXERCISE - Fedora
V5.2
Student Notebook
Uempty
E-47
Student Notebook
V5.2
Student Notebook
Uempty
Appendix F. Linux on IBM servers

This appendix describes the various IBM architectures that Linux runs on. It lists their main characteristics, advantages, and disadvantages and lists the issues that are important in determining which IBM server is best suited for your workload.

After completing this appendix, you should be able to: Describe how businesses are using Linux List the main features of the IBM server families List the considerations involved in selecting an IBM server for your workload

Accountability: Checkpoint
F-1
Student Notebook
Appendix objectives
After completing this appendix, you should be able to: Describe how businesses are using Linux List the main features of the IBM server families List the considerations involved in selecting an IBM server for your workload
Figure F-1. Appendix objectives
LX036.0
Notes:
F-2
V5.2
Student Notebook
Uempty
How customers are using Linux
Workload Consolidation
Linux Clusters
Application Solutions
Distributed Enterprise
Infrastructure Solution
Figure F-2. How customers are using Linux
LX036.0
Notes: Introduction
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.
F-3
Student Notebook
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 and print services Web servers Database servers Mail servers
Figure F-3. Workload consolidation
LX036.0
Notes: Introduction
The first workload that Linux is typically used for is workload consolidation. Its 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 theyre going to run. After a few years, this leads to a variety of hardware vendors, architectures, operating systems, and applications that dont 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.
F-4
V5.2
Student Notebook
Uempty
Note that moving your application to one or a few servers doesnt 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 is discussed later.
F-5
Student Notebook
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
Figure F-4. Linux high-performance clusters
LX036.0
Notes: Introduction
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.
F-6
V5.2
Student Notebook
Uempty
Distributed enterprise
Enterprise with a lot of branch offices that need basic computer services at each office
File and print services Checkout desks Inventory tracking
Examples:
Restaurant franchises Retail industry
Figure F-5. Distributed enterprise
LX036.0
Notes: Introduction
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.
F-7
Student Notebook
Application solutions
Running mission-critical applications on Linux Examples:
DB2, Oracle MQSeries PeopleSoft SAP WebSphere
Figure F-6. Application solutions
LX036.0
Notes: Introduction
By 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.
F-8
V5.2
Student Notebook
Uempty
Infrastructure solutions
Low-level services are needed in each computer network Examples:
DHCP DNS File and print services Routing Firewalls VPN services Network monitoring and intrusion detection Backup services
Figure F-7. Infrastructure solutions
LX036.0
Notes: Introduction
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.
F-9
Student Notebook
And how about Linux on the desktop?

Not an official IBM strategy (yet), but...
Internal Linux-based desktop is available (Open Client for Linux) IBM will support customers if they ask for it
Solutions:
WINE, CrossOver Office win4lin StarOffice/OpenOffice VMWare
Figure F-8. And how about Linux on the desktop?
LX036.0
Notes: Introduction
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 small enough that it is not an official IBM strategy. Of course, well support everyone who asks.
F-10 Linux System Administration I
V5.2
Student Notebook
Uempty
IBM servers for On Demand Business

IBM System i
This is the combination of the product lines of System i5, SServer i5, SServer iSeries, and AS/400
IBM System p
This is the combination of the product lines of System p5, SServer p5, SServer pSeries, SServer OpenPower, and optionally RS/6000
IBM System z
This is the combination of the product lines of System z9, SServer zSeries, and optionally, S/390 x86 servers for Windows and Linux
IBM System x All servers run Linux natively All servers fully supported by RHEL/Fedora and SUSE Linux
Figure F-9. IBM servers for On Demand Business
LX036.0
Notes: Introduction
There is an IBM server for any situation. The IBM server family consists of the following: - IBM System i: This is the combination of the product lines of System i5, eServer i5, eServer System i, and AS/400 - IBM System p: This is the combination of the product lines of System p5, eServer p5, eServer System p, eServer OpenPower, and optionally, RS/6000 - IBM System z: This is the combination of the product lines of System z9, eServer System z, and optionally, S/390 - IBM System x: This represents all systems based on x86 servers for Windows and Linux Obviously, all of these series run their own native operating systems, such as i5/OS, AIX, OS/390, and Windows. However, they all run Linux as well: IBM has made sure that the Linux kernel natively supports all architectures and that the main Linux
Copyright IBM Corp. 2001, 2009 Appendix F. Linux on IBM servers F-11
Student Notebook
business partners (Red Hat and SUSE) have enterprise versions of their distributions available for all four architectures. The IBM On Demand family of servers 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 example, the System x 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.
V5.2
Student Notebook
Uempty
IBM System x
System x = 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
Figure F-10. IBM System x
LX036.0
Notes: Introduction
IBM System x is the family which uses Intel or Intel-compatible CPUs. Its 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 thats in use by most Linux developers. Because of this, its 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. System x 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 System x architecture is quite simple though. The main drawback is that it doesnt have any hardware/microcode support for
F-13
Student Notebook
partitioning your system into multiple machines. If you want partitioning, you have to use VMware ESX/GSX server. 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.
V5.2
Student Notebook
Uempty
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 Four SCSI adapters Four serial (COM) ports Two printer (LPT) ports Four Ethernet NICs
Figure F-11. VMware ESX/GSX server
LX036.0
Notes: Introduction
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-solution, you will have to consider a performance loss. This is typically a few percent only but can occasionally reach 30%, depending on your workload.
F-15
Student Notebook
IBM System i
System i = POWER architecture Recent versions allow system to be split in logical partitions, each running a different OS (i5/OS or Linux)
Current models: Max 256 LPARs, future models support more At least one i5/OS LPAR is required for management
Operating Systems in LPARs can communicate using virtual LAN

LPAR1 OS/400 V5R1 LPAR2 OS/400 V4R5 LPAR3 Linux LPAR4 Linux
Primary Partition
Figure F-12. IBM System i
LX036.0
Notes: Introduction
IBM System i, formerly known as IBM eServer iSeries and AS/400, is based on the POWER architecture. Recent System i machines can be split into multiple logical partitions, each running a different operating system. At least one of these partitions needs to run i5/OS 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.
V5.2
Student Notebook
Uempty
IBM System p
System p = POWER architecture Recent versions allow system to be split in logical partitions, each running a different OS (AIX or Linux)
Current models: 16-254 LPARs, future models support more Control Workstation (CWS) required for management
Figure F-13. IBM System p
LX036.0
Notes: Introduction
Just like System i, System p is also built around POWER architecture. In fact, these families have more hardware in common. Both families can be split into a number of logical partitions, each running a different operating system. Again, the operating systems in the various partitions can communicate with each other using a virtual LAN.
F-17
Student Notebook
IBM System z
System z = 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 (hundreds 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
Server farms
Linux for zSe ries image s
zOS*
zOS*
Single purpose Internet-related servers
VM or IBM zSeries Virtual Image Facility for Linux
Inter Partition Communication
Figure F-14. IBM System z
LX036.0
Notes: Introduction
IBM System z is sometimes still referred to as a mainframe. Its 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, 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. VM is especially interesting since it allows you to run literally hundreds of Linux instances on a single box. It is 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%.
F-18 Linux System Administration I Copyright IBM Corp. 2001, 2009
V5.2
Student Notebook
Uempty
When running Linux on System z, 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 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. This is 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.
All mainframes have multiple processors, and these can be enabled/disabled at will.
F-19
Student Notebook
IBM BladeCenter
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: One 2-way Intel Xeon (32 bits) HS40: One 4-way Intel Xeon (32 bits) JS20: 2-way PowerPC 970 (64 bits)
Advantage of BladeCenter versus 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
Figure F-15. IBM BladeCenter
LX036.0
Notes: Introduction
The IBM 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 or 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 is otherwise fully independent. Here is a sample of server Blades and the technology behind them: - HS20: One to two Intel Xeon processors - HS40: One to four Intel Xeon processors
V5.2
Student Notebook
Uempty
- JS21: 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 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. When buying a BladeCenter, make sure you perform your calculations for power, air conditioning, and weight correctly!
F-21
Student Notebook
IBM system comparison

System family System x Architecture Intel-32 bits 32 max # processors 1 (Pentium) 4 (Xeon) 32 (Xeon MP) (*) 4 (Itanium 2) 2 (Opteron) 64 (*) 64 (*) 32 (*) 4 (Xeon) 2 virtualization VMWare
System p System i System z BladeCenter
Intel-64 AMD-64 POWER POWER z/Architecture Intel-32 POWER
32/64 32/64 32/64 32/64 32/64 32 32/64
LPAR LPAR LPAR, VM VMWare -
(*) Current Linux distributions, using the 2.4 kernel, do not scale well beyond eight processors; virtualization recommended
Figure F-16. IBM system comparison
LX036.0
Notes: Introduction
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.
V5.2
Student Notebook
Uempty
Which is "the best" for running Linux?

All IBM System brands run Linux natively All IBM System brands are fully supported by IBM, RHEL/Fedora, 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)
Figure F-17. Which is the best for running Linux?
LX036.0
Notes: Introduction
Youve seen that all IBM servers 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.
Student Notebook
Workloads revisited
Workload Consolidation
Linux Clusters
Application Solutions
Distributed Enterprise
Infrastructure Solution
Figure F-18. Workloads revisited
LX036.0
Notes: Introduction
The issues mentioned in the previous visual play out differently for the various workloads that weve discussed so far. Thus, we are revisiting our workloads again to see how things work out.
V5.2
Student Notebook
Uempty
Workload consolidation
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
Figure F-19. Workload consolidation
LX036.0
Notes: Introduction
When you are doing workload consolidation, the most important consideration is whether the architecture that youd like to use supports your application(s). If youre consolidating standard Open Source software such as Samba or Apache, youll find that all these applications run on any architecture. However, 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. Lastly, 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 server architectures may be suitable.
Student Notebook
Linux high-performance clusters

Price per node CPU performance Manageability of hundreds or thousands of identical systems For some applications: Network bandwidth and/or memory size
Recommenced architectures:
System p or System x for "average" clusters System p for massive SMP, when a huge amount of memory is required per node, or 64-bit floating point operations are required
Consider IBM BladeCenter (System x or System p Blades)
Figure F-20. Linux high-performance clusters
LX036.0
Notes: Introduction
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 hundreds or thousands of identical systems and the network bandwidth and memory size of each individual node. Considering the price and performance of the IBM Sservers, you will typically want to look at the System x or System p architecture. For average clusters, System x and System p perform about as well. However, System p 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, System x machines have 64-bit processors as well. However, these processors are fairly new and theres not much experience with them. You need to
V5.2
Student Notebook
Uempty
consider that youre one of the first using that new technology if you use System x 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 memory, and one network adapter, BladeCenters are ideal for creating Linux high-performance clusters. The ability to mix and match System x and System p blades might be beneficial too.
F-27
Student Notebook
Distributed enterprise
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:
System x System p or System x if you also need an AIX or i5/OS application on-site
Figure F-21. Distributed enterprise
LX036.0
Notes: Introduction
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 current hardware is typically good enough. Because of these issues, all else being equal, the System x 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.
V5.2
Student Notebook
Uempty
Application solutions
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)
Figure F-22. Application solutions
LX036.0
Notes: Introduction
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 Sserver architectures are candidates.
F-29
Student Notebook
Infrastructure solutions
Low cost per box High but not extreme reliability Remote management Easy on-site maintenance and repair Performance is typically not an issue Security
System x System i, System p or System z if you have spare capacity on existing hardware and their network location is convenient
Figure F-23. Infrastructure solutions
LX036.0
Notes: Introduction
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: System x. 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.
V5.2
Student Notebook
Uempty
...And on the desktop?

The only IBM architecture that has a convenient form factor for desktop/laptop use is the System x/ThinkPad* IBM Systems with deskside form factor: System x and System p Advantage of System x:
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)
* Lenovo
Figure F-24. ...And on the desktop?
LX036.0
Notes: Introduction
Weve said it before: Linux on the desktop is not an official IBM strategy, but well support customers if they ask for it. As for platform choice, most people will use System x or ThinkPads for desktop usage. There are basically two reasons for this: - ThinkPads and System x 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 System x, you can also use System p 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.
F-31
Student Notebook
Checkpoint
1. Name the six main types of Linux usage today: a. b. c. d. e. f. What is a BladeCenter? a.
2.
b.
3.
What are considerations when determining the architecture on which you want to run an ISV application?
Figure F-25. Checkpoint
LX036.0
Notes:
V5.2
Student Notebook
Uempty
Appendix summary
Having completed this appendix, you should understand: The reasons Linux is used most, today, are:
Workload consolidation High-performance clusters Distributed enterprise Application solutions Infrastructure solutions
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 and budget Current experience Performance and scaling requirements Interoperability requirements with other legacy applications Availability of spare/unused hardware
Figure F-26. Appendix summary
LX036.0
Notes:
F-33
Student Notebook
V5.2
Student Notebook
glos
Acronyms
A
AMD Advanced Micro Devices, Inc. APAR Affinity Partition API Application Programing Interface ARP Address Resolution Protocol
F
FAQ Frequently Asked Questions FBC Fabric Bus Controller FP Floating Point execution unit FIR Fault Isolation Register FreeBSD Free Berkeley Software Distribution FRU Field Replaceable Unit FSF Free Software Foundation FTP File Transfer Protocol FW Firmware FX Fixed Point execution unit
B
BIST Built In Self Test BRX Branch Execution unit BSD Berkeley Software Distribution UNIX
C
CA Certificate Authority CD-ROM Compact Disk-Read Only Memory CE Customer Engineer CGI Common Gateway Interface CHS Cylinder Head Sector CLI Command Line Interface CLU Command Line Utility CPU Central Processing Unit CSM Cluster Systems Management CUPS Common UNIX Printing System
G
GB GigaByte GIMP GNU Image Manipulation Program GNOME GNU Network Object Model Environment GNU GNUs Not UNIX (recursive acronym) GPFS General Parallel File System GRUB Grand Unified Bootloader GUI Graphical User Interface
H
HMC Hardware Management Console HPC High Performance Computing HPS High Performance Switch HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol HW Hardware
D
DHCP Dynamic Host Configuration Protocol DIMM Dual In-line Memory Module DLL Dynamic Link Library DNS Domain Name Service DRAM Dynamic Random Access Memory DVD-RAM Digital Video Disk-Random Access Memory
I
IBM International Business Machines IFU Instruction Fetch Unit INITRD Initial RAM Disk IP Internet Protocol IPL Initial Program Load IPP Internet Printing Protocol I/O Input/Output
E
ECC Error Correction Circuitry ECC Error Checking and Correction EDFI Error Detection Fault Isolation EED Extended Error Data EEPROM Electrically Erasable Programmable Read-Only Memory EIA Electronics Industry Standard ELA Error Log Analysis EPROM Electrically Programmable Read-Only Memory EULA End User License Agreement
J
JDK Java Development Kit JFS Journaled/Journaling File System JIT Just-In-Time Compiler JVM Java Virtual Machine
Acronyms
X-1
Student Notebook
K
Kb Kilobit KB KiloByte KDE K Desktop Environment
L
LAN Local Area Network LANANA Linux Assigned Names and Numbers Authority LCD Liquid Crystal Display LDAP Lightweight Directory Access Protocol LED Light Emitting Diode LILO Linux Loader LPRng LPR Next Generation LPAR Logical Partition LS Load Store unit LSB Linux Standards Base LSU Load Store Unit LVM Logical Volume Management
PHB PCI Host Bridge PID Process Identification Number POST Power On Self-Test POWER Performance Optimized With Enhanced RISC PPAR Physical Partition
Q
QCM Quad Chip Module
R
RAID Redundant Arrays of Inexpensive Disks RAM Random Access Memory RAS Reliability Availability Serviceability RIO Remote Input/Output RISC Reduced Instruction Set Computing RPM RPM Package Manager RTAS Runtime Abstraction Services
S M
MA Maintenance Agreement Mb Megabit MB MegaByte MBR Master Boot Record MLD Merged Logic DRAM MPP Massively Parallel Processing MSS Maximum Segment Size MTU Maximum Transmission Unit SAN Storage Area Network SCSI Small Computer System Interface SDRAM Synchronous Dynamic Random Access Memory SGML Standard Generalized Markup Language SMI Synchronous Memory Interface SMP Symmetrical Multi-Processing SSH Secure Shell SSL Secure Socket Layer
N
NFS Network File System NIC Network Interface Card NTF No Trouble Found NUMA Non Uniform Memory Architecture (or Access) NVRAM Non Volatile Random Access Memory
T
TB TeraByte TCE Translation Control Entries TCP/IP Transmission Control Protocol/Internet Protocol TU Test Unit
U O
OS Operating System UE Uncorrectable Error UEPO Universal Emergency Power Off UPIC Universal Power Interface Control UPS Uninterruptible Power Supply URI Universal Resource Identifier UTC Universal Time Constant
P
PAM Pluggable Authentication Modules PB PetaByte PCI Peripheral Component Interconnect PE Parallel Environment PGP Pretty Good Privacy
X-2 Linux System Administration I
V
VMM Virtual Memory Manager
Student Notebook
VNC Virtual Network Computing VT Virtual Terminal
W
WAN Wide Area Network WebSM Web-based System Manager WLAN Wireless Local Area Network WWW World Wide Web
X
X X Window System XML Extensible Markup Language
Y
YaST Yet Another Setup Tool

Acronyms
X-3
Student Notebook
X-4
V5.2
Student Notebook
glos
Glossary
A
Account Name Same as Login ID, User ID, or User Name. The name assigned to a user on a UNIX/ Linux system. Multiple users can be set up on a system with unique account names, each with varying access (permission) levels. After Linux installation, account names are assigned by the Superuser, or root operator. Activate (a partition) Before an operating system can boot on a partition, the partition must be made available by activating it. Adapter cassette A container that PCI adapters are placed in before being installed in the Remote I/O drawer. This enables adapters to be removed without placing the drawer into a service position, as with previous pSeries model servers. Append Symbol The > keyboard character, repeated (that is, >>). It is often used to send the output from a command to a text file, appending the data to the end of the file, rather than replacing the existing content. For example, ls -a >> output.txt sends the current directory list to a file called output.txt, and adds it to the end of the file. Repeating the command will continue to add new data to the end of the file. (Also, see Piping Symbol and Redirection Symbol.) Archive A single large file containing multiple files, usually compressed to save storage space. Often created to facilitate transferring between computers. Popular archival formats include ARJ, TAR, ZIP, and ZOO. Also, to create such an archive file. a much lower price. This sort of system is ideal for compute-intensive tasks such as weather modeling because the calculations can be divided among dozens, hundreds, or even thousands of separate processors all running simultaneously. Sometimes referred to a Beowulf-class supercomputer, or a super-cluster or hyper-cluster. Blind Swap PCI Another term for the ability to replace a PCI adapter while the system is operating. Bourne Shell A popular command line shell offering many advantages over the DOS command prompt. (Also, see Bash and Korn Shell.) BSD (Berkeley Software Distribution) UNIX UNIX distribution from University of California at Berkeley. (Also, see FreeBSD.) Bzip2 A newer file compression program for UNIX/ Linux, providing smaller file sizes than Gzip.
C
Certificate Authority (CA) A trusted third-party organization or company that issues digital certificates used to create digital signatures and public-private key pairs. The role of the CA in this process is to guarantee that the individual granted the unique certificate is, in fact, who he or she claims to be. Central Electronics Complex (CEC) Housing that contains system processors, memory, and remote I/O connections. Common Gateway Interface (CGI) Used on Web servers to transmit data between scripts and/or applications and then return the data to the Web page or browser. CGI scripts are often created using the Perl language, and can generate dynamic Web content (including e-commerce shopping baskets, discussion groups, survey forms, current news, and so forth). Chipkill Recovery The memory chips are organized such that the failure of any specific memory module only affects a single bit within an ECC word (bit scattering) thus allowing for error correction and continued operation in the presence of a complete chip failure. Cylinder/Head/Sector (CHS) Disk information required by FDISK during partitioning. Client A machine that requests services (e-mail, for example) from a server. Command Line Utility (CLU) A program that is run from a command line session, or shell, such as Tar or Mkdir. Cluster A network of workstations (PCs or other) running Linux. (Also, see Beowulf.) Cluster Grouping more than one system together to handle a given task. Each system is independent,
B
Background Process A program that is running without user input. A number of background processes can be running on a multitasking operating system, such as UNIX/Linux, while the user is interacting with the foreground process (for example, data entry). Some background processesdaemons, for examplenever require user input. Others are merely in the background temporarily while the user is busy with the program presently running in the foreground. Bourne Again Shell (BASH) An enhanced version of the Bourne Shell. (Also, see Korn Shell.) BDF Fonts A variety of bit mapped fonts for the X Window System. (Also, see PostScript Fonts and TrueType Fonts.) Beans Components for the JavaBeans architecture. Beowulf A network of relatively inexpensive computers (including PCs), potentially using different processors and hardware architectures, united by Linux and special system-level software into a massively parallel computing system. The end result is a Preparing Today for Linux Tomorrow 4 system capable of supercomputer computation at
Glossary
X-5
Student Notebook
but connects to a single point for management tasks (example: IBM eServer 1600). Command Line Interface (CLI) A full-screen or windowed text-mode session where the user executes programs by typing in commands with or without parameters. The CLI displays output text from the operating system or program and provides a command prompt for user input. Command Prompt The DOS/Windows and OS/2 term for the part of the command line interface where the user types commands. (Also, see Shell Prompt.) Compile To turn programming source code into an executable program. Compiled Language A language that requires a compiler program to turn programming source code into an executable machine-language binary program. After compiling once, the program can continue to be run from its binary form without compiling again. Compiled languages/programs tend to be faster than interpreted or p-code languages, but require compilers (which can be expensive), and are often more difficult to program in than interpreted and p-code languages. Examples of compiled languages are C and C++, COBOL, and FORTRAN. Compiler A program used to turn programming source code into an executable program. Console Application A command line program that does not require (or perhaps even offer) a graphical user interface to run. Cron A Linux daemon that executes specified tasks at a designated time or interval.
operating system commands into instructions the device understands. Direct Access Storage Device (DASD) Pronounced daz-dee, another name for disk drive in the world of mainframes. Distributed Converter Assembly (DCA) Provides Direct Current (DC) to DC power converter (350Vto-logic V) used in I/O Drawers. Functions in the DCA include dual UPIC communication, power sequencing, sensor monitoring, overvoltage warn/ crit, undervoltage warn/crit, overcurrent warn/crit, MDC (Microcontroller Diagnostic / Communication Card) selftest, EDFI, and monitor / control / activate / deactivate both AMDs and LED control. Distribution A packaging of the Linux kernel (core) with various user interfaces, utilities, drivers, and other software into a user deliverable. Often available as a free download or in a low-cost CDROM package. Popular distributions include Debian, Red Hat, Slackware, SUSE, TurboLinux and others. Debian Package Manager (Dpkg) A packaging and installation tool for Internet downloads, included with Debian Linux but compatible with other distributions. It produces files with a .DEB extension. Similar to RPM.
E
Emacs A popular text editor. Error Checking and Correction (ECC) ECC codes provide single bit error correction and double bit error detection. Single bit error will be corrected before forwarding to the processor.
D
Daemon A background process of the operating system that usually has root security level permission. A daemon usually lurks in the background until something triggers it into activity, such as a specific time or date, time interval, receipt of e-mail, and so forth. Desired resources The amount of resources that you would like for the partition if the resources are available. Desired resources are what you would like to have for normal operations of the partition. Desktop The operating system user interface, which is designed to represent an office desk with objects on it. Rather than physical telephones, lamps, in/out baskets, and so forth, the operating system desktop uses program and data icons, windows, taskbars, and the like. There are many different desktop environments available for Linux, including KDE, GNOME, and X11, that can be installed by a user. (Also, see GUI, Window manager and X Window System.) Device Driver A program that serves as an intermediary between the operating system and a device (ports, drives, monitors, printers, and so forth) defining to the operating system what capabilities the device has and translating the
F
Fabric Controller Distributed Switch Built into each POWER processor, this interface provides high speed communication between processors. Filesystem A set of programs that tells an operating system how to access and interpret the contents of a disk or tape drive or other storage medium. Common file systems include: FAT and FAT-32 (DOS/Windows), EXT2/3, NFS, Reiser, and others. Filter A program that reads data (from a file, program output, or command line entry) as input, processes it according to a set of predefined conditions (for example, sorted alphabetically), and outputs the processed data. Some filters include Awk, Grep, Sed and Sort. Finger A UNIX/Linux command that provides information about users that are logged on. Foreground Process In a multitasking operating system, such as UNIX/Linux, the foreground process is the program that the user is interacting with at the present time (for example, data entry). Different programs can be in the foreground at different times as the user jumps between them. In a tiered windowing environment, it is the topmost window.
X-6
Student Notebook
Free Berkeley Software Distribution (FreeBSD) Similar to Linux in that it includes many GNU programs and runs many of the same packages as Linux. However, some kernel functions are implemented differently. (Also, see BSD UNIX.) File Transfer Protocol (FTP) A method of transferring files to and from other computers often software repositories.
H
Hardware Management Console (HMC) This device connects managed systems, and provides a variety of services, including partition management, virtual console support, and troubleshooting applications. Home Directory The directory the user is placed in after logging on. Hyper Text Markup Language (HTML) The standard markup language for designing Web pages. Markup tags, or formatting commands, allow the Web page designer to specify highlighting, position and graphics, create hyperlinks, and so forth. Hyper Text Transport Protocol (HTTP) The set of guidelines created for requesting and sending HTML-based Web pages. Hypervisor Firmware that enables partitioning to occur on the pSeries systems. The three primary functions of the hypervisor are: Virtual Memory Management (VMM) of TCE tables, Debug register/memory access, and virtual console support. Hypervisor Page Tables Used to map physical memory pages to virtual memory pages. Each partition needs 1/64th of its memory size for page table space in memory.
G
GNU C Compiler (GCC) A high-quality C compiler governed by the GPL. GNU Image Manipulation Program (GIMP) A popular image editor/paint program for Linux. GNU Network Object Model Environment (GNOME) One of several user interfaces (window managers) for Linux, built with Gtk. For more on GNOME, go to www.gnome.org. (Also, see AfterStep, Enlightenment, KDE, and X Window System.) GNUs Not Unix (GNU) Project An effort of the Massachusetts Institute of Technology (MIT) Free Software Foundation (FSF) to develop and promote alternatives to proprietary UNIX implementations. GNU software is licensed under the GPL. GNU/Linux Same as Linux. So-called because many of the components included in a Linux distribution are GNU tools. GNU General Public License (GPL) A common usage and redistribution license. Global Regular Expression and Print (Grep) A tool that searches files for a string of text and outputs any line that contains the pattern. Grand Unified Boot Loader (GRUB) A Multiboot boot loader. Gtk/Gtk+ (GIMP ToolKit) A powerful, fast open source graphics library for the X Window System on UNIX/Linux, used by programmers to create buttons, menus, and other graphical objects. (Also, see GNOME, Motif and Qt.) Graphical User Interface (GUI) The collection of icons, windows, and other onscreen graphical images that provide the users interaction with the operating system. (Also, see Desktop and Window manager.) GX Bus The connection to I/O drawers is the RIO interface. There are GX card slots with GX buses to interface with the I/O drawers. GNU zip (Gzip) The original file compression program for UNIX/Linux. Recent versions produce files with a .gz extension. (A .z or .Z extension indicates an older version of Gzip.) Compression is used to compact files to save storage space and reduce transfer time. (When combined with Tar, the resulting file extensions may be .tgz, .tar.gz, or .tar.Z.)
I
Init The first process to run immediately after the operating system loads. It starts the system in single-user mode or spawns a shell to read the startup files, and opens ports designated as login ports. I/O Drawer A subsystem connected to the pSeries system that typically contains I/O slots and disks. Inter-Processor Bus Communication path between processor cores within the MCM. Traffic is directrouted from processor to processor via this bus.
J
Java An object-oriented programming language developed by Sun Microsystems to be operating system-independent. Java is often used on Web servers. Java applications and applets are sometimes offered as downloads to run on users systems. Java programming can produce applications, or smaller Java applets. Java is a somewhat simplified version of the C++ language and is normally interpreted rather than compiled. (Also, see JIT Compiler.) Java Applets Small Java programs that are embedded in a Web page and run within a browser, not as a stand-alone application. Applets cannot access some resources on the local computer, such as files and serial devices (modems, printers, and so forth), and generally cannot communicate with other computers across a network.

Glossary
X-7
Student Notebook
JavaBeans A component architecture for the Java language. JavaBeans components are called Beans. JavaScript A cross-platform World Wide Web scripting language, vaguely related to Java. It can be used as a server-side scripting language, as an embedded language in server-parsed HTML, and as an embedded language for browsers. Java Development Kit (JDK) A Java programming toolkit from Sun, IBM or others, available for UNIX/ Linux and other operating systems. Journaled/Journaling File System (JFS) A file system that includes built-in backup/recovery capabilities. Changes to the index are written to a log file before the changes take effect so that if the index is corrupted (by a power failure during the index write, for example), the index can be rebuilt from the log, including the changes. Just-In-Time (JIT) Compiler A compiler for the Java language that allows interpreted Java programs to be automatically compiled into native machine language on the fly for faster performance of the program. Some JVMs include a JIT compiler. Journaling Same as logging. Writing information to a journal (log) file as a method of tracking changes. Java Virtual Machine (JVM) A Java runtime environment, required for the running of Java programs, which includes a Java interpreter. A different JVM is required for each unique operating system (Linux, Windows XP, and so forth), but any JVM can run the same version of a Java program.
device drivers, applications, a user interface and other tools that generally can be compiled and run on other UNIX operating systems as well. LoadLeveler An IBM application that dispatches processes over the entire pool of networked systems to maximize available resources. Logical Partition A method of dividing a server into smaller processing units. These units can be considered small servers. Logical Partitioning provides for flexible configuration of physical resources.
M
Macro set of instructions stored in an executable form. Macros may be application specific (such as a spreadsheet or word processing macro that performs specific steps within that program) or general-purpose (for example, a keyboard macro that types in a user ID when Ctrl-U is pressed on the keyboard). Man The UNIX/Linux command for reading online manual pages. Managed System A term used for the entire pSeries system that is running partitions. Master Boot Record (MBR) The first physical sector on a bootable disk drive. The place where the system BIOS looks when the computer is first booted, to determine which partition is currently active (bootable), before reading that partitions first (boot) sector and booting from the partition. Multipurpose Internet Mail Exchange (MIME) A communications protocol that allows text e-mail messages to include non-textual (graphics, video or audio, for example) data. Minimum resources The smallest amount of CPU and memory resources that a partition can be activated with. This value is set when configuring a partition. Motif A powerful proprietary graphics library for UNIX/Linux, developed by the Open Software Foundation (OSF) and used by programmers to create buttons, menus and other graphical objects for the X Window System. (Also, see Gtk/Gtk+.) Mount Identify a disk drive to the file system before use. Multitasking The ability of an operating system to run more than one program, or task, at a time. A cooperative multitasking OS, like Windows 95/98, requires one application to voluntarily free up resources upon request so another application can use it. A preemptive multitasking OS, such as UNIX/Linux, Windows NT/2000, or Windows XP, frees up resources when ordered to by the operating system, on a time-slice basis, or a priority basis, so that one application is unable to hog resources when they are needed by another program. Multithreading The ability of an operating system to concurrently run programs that have been divided into subcomponents, or threads. Multithreading, when done correctly, offers better utilization of
K
K Desktop Environment (KDE) One of several user interfaces (window managers) for Linux, built with Qt. For more on KDE, go to www.kde.org. (Also, see, GNOME and X Window System.) Kernel The core of the operating system, upon which all other components rely. The kernel manages such tasks as low-level hardware interaction and the sharing of resources, including memory allocation, input/output, security, and user access. Korn Shell An enhanced version of the Bourne Shell, including extensive scripting support and command line editing. It supports many scripts written for the Bourne Shell. (Also, see Bash.)
L
Linux Loader (LILO) A popular partition boot manager utility, capable of booting to operating systems other than Linux. It is not file systemspecific. Linux An open source UNIX-like operating system, originally begun by Linus Torvalds. Linux really refers to only the operating system kernel, or core. More than 200 people have contributed to the development of the Linux kernel. The rest of a Linux distribution consists of various utilities,
Student Notebook
processors and other system resources. Multithreaded programming requires a multitasking/multithreading operating system, such as UNIX/Linux, Windows NT/2000, or Windows XP, capable of running many programs concurrently. A word processor can make good use of multithreading, because it can spell check in the foreground while saving to disk and sending output to the system print spooler in the background. (Also, see Thread.) Multi-Chip Module (MCM) A single assembly containing four POWER4 processor chips (providing eight POWER4 processors in standard configuration, and four POWER4 processors in HPC configuration).
N
Newbie Someone new to the Internet, computers in general, or Linux specifically (for example, a Linux newbie). Network Installation Manager (NIM) A utility included with AIX, NIM allows you to load AIX (either via initial installation or mksysb), or diagnostics over a network interface from a server. Network File System (NFS) A file system that allows the sharing of files across a network or the Internet. Non Uniform Memory Architecture (NUMA) A type of parallel processing architecture in which each processor has its own local memory but can also access memory owned by other processors. It's called non-uniform because the memory access times are faster when a processor accesses its own memory than when it accesses memory from another processor.
O
Operator Panel A control point for pSeries servers, providing a display, power button, and reset button. With the pSeries system running partitions, the display functions are actually displayed on the HMC.
P
Pluggable Authentication Modules (PAM) A replaceable user authentication module for system security, which allows programs to be written without knowing which authentication scheme will be used. This allows a module to be replaced later with a different module without requiring rewriting the software. Parallel System Support Programs (PSSP) A collection of utilities used in managing RS/6000 SP models, and pSeries clusters. Partition A contiguous section of a disk drive that is treated by the operating system as a physical drive. Thus, one disk drive can have several drive letters assigned to it.
Partition A defined grouping of resources (CPU, memory, I/O devices) that operates as an independent system. Partition Profile A named configuration of resources for a particular partition.A partition may have multiple partition profiles. Portable Document Format (PDF) Binary files created with Adobe Acrobat or other programs capable of producing output in this format. Used for producing operating system-independent documents, which can be viewed using Acrobat Reader or other programs, including Web browsers equipped with an Acrobat Reader plug-in. Practical Extraction and Report Language (PERL) A common scripting/programming language. It is often used on UNIX/Linux Web servers for generating CGI scripts. Permission The authority to read and write files and directories, and execute programs. Varying permission levels can be assigned by the Superuser, or root operator, on a file-by-file, directory-by-directory basis or by account name (User ID). Pretty Good Privacy (PGP) A high-security, publickey data encryption program for UNIX/Linux and other operating systems. Physical Address The physical location that a resources occupies is assigned an address. This address is used in identifying that resource to a managed system (example: 1st I/O drawer has a physical address of U1.9, representing its location in the system rack). Physical Partitioning (PPAR) A method of dividing a server into smaller processing units. These units can be considered small servers. This division is accomplished via physical boundaries (building blocks). Piping Symbol The | keyboard character (the ShiftBackslash character above the Enter key on a typical 101-key keyboard). It is often used to feed the output from one command or program to another. For example, history | grep mcopy sends the contents of the .bash_history file (via the history command) to the grep program, searching for the string mcopy. (Also, see Append Symbol and Redirection Symbol.) Planar A hardware part that has (in one or more planes) logic paths, low-voltage distribution paths, or grounding paths of a section of a machine. This is often referred to as a logic board. Port/Ported/Porting The process of taking a program written for one operating system platform and modifying it to run on another OS with similar functionality. There is generally little or no attempt to customize the program to take advantage of the unique capabilities of the new operating system, as opposed to optimizing an application for a specific operating system. Portable A term referring to software that is designed to be use on more than one operating system with only minor modifications and recompilation.
Glossary X-9

Student Notebook
Portable Operating System Interface for uniX (POSIX) A set of programming interface standards governing how to write application source code so that the applications are portable between operating systems. POSIX is based on UNIX and is the basis for the X/Open specification of The Open Group. PostScript A page description language developed by Adobe Systems that tells a printer how to display text or graphics on a printed page. PostScript Fonts A wide variety of fonts that can be used with OS/2, MS Windows and the X Window System. Font files include those with .afm, .pfa and .pfb extensions. Sometimes called Adobe Type 1 fonts, or ATM (Adobe Type Manager) fonts. PostScript fonts typically require a PostScriptcompatible printer. (Also, see BDF Fonts and TrueType Fonts.) Process An executing program. (Also, see Multitasking and Multithreading.) Public Domain Software that is available to be used and modified by anyone, for any purpose, and may even be incorporated for distribution in commercial software. Public domain software is not copyrighted, and no rights are retained by the author. Public Key Encryption A method of data encryption that involves two separate keys: a public key and a private key. Data encrypted with the public key can be decrypted only with the private key and vice versa. Typically, the public key is published and can be used to encrypt data sent to the holder of the private key, and the private key is used to sign data. Python An object-oriented p-code programming language.
Remote I/O (RIO) The connection to I/O enclosures is the RIO interface, operating at 500 MB/sec. Remote I/O Converged Service Processor (RIO/ CSP) The initial RIO book installed also contains the Service Processor for the managed system. RPM Package Manager (RPM) A packaging and installation tool for Internet downloads, included with some Linux distributions. It produces files with a .RPM extension. Similar to Dpkg.
S
Service Agent (SA) The call home function for hardware serviceable events. SA runs as a client on partitions, and reports to an SA server on the HMC. Service Focal Point A system infrastructure which manages serviceable event information for the system building blocks. This infrastructure makes it easier to manage events in a complex system. Service Processor (SP) A logic board containing service tools used in stem diagnostics. The SP provides access to these tools before system power is activated. (bootlist, power management, SP error logs, firmware installation) Secure Socket Layer (SSL) A protocol developed by Netscape for transmitting private documents via the Internet. SSL works by using a public key to encrypt data that's transferred over the SSL connection. Shell A text-mode window containing a command line interface to the operating system. Shell Prompt The user input area of a shell. Whereas in a DOS shell the command prompt is designated by a Greater Than (>) symbol, in Linux it is usually a Percent (%) symbol, Dollar sign ($) or other special character, depending on the shell used. (Also, see Command Prompt.) Shell Script A script designed to be run automatically when a shell is started. Symmetrical Multi-Processing (SMP) A computer architecture that provides fast performance by making multiple CPUs available to complete individual processes simultaneously. Unlike asymmetrical processing, any idle processor can be assigned any task, and additional CPUs can be added to improve performance and handle increased loads. SMP uses a single operating system and shares common memory and disk input/output resources. System Management Services (SMS) Firmware layer that provides access to NVRAM functions on RS/6000 and pSeries systems. You can modify a bootlist, install system firmware updates, and access some diagnostic error logs that are maintained by SMS. Secure SHell (SSH) Secure Shell is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over insecure channels. SSH protects a network
Q
Queue (Sometimes incorrectly spelled Que.) A list of tasks awaiting execution, as in the print queue.
R
Redundant Array of Independent/Inexpensive Disks/Devices (RAID) A method of providing data redundancy, improved performance and/or quick data recoverability from disk crashes, by spreading or duplicating data across multiple disk drives. Commonly used RAID types include RAID 0 (Data Striping), RAID 1 (Disk Mirroring) and RAID 5 (Striping with Distributed Parity). RAID configurations typically require SCSI disk drives (not IDE/EIDE) and may require identical drives (same capacity, brand, and so forth). RAID arrays appear to the operating system as a single device.rexec An AIX command that executes commands one at a time on a remote host. Required resources A term refers to I/O slots that a partition requires to function. When configuring a partition, you can define I/O slots as being required or desired.
Student Notebook
from attacks such as IP spoofing, IP source routing, and DNS spoofing. System Profile A system profile is a named set of partition profiles. When you boot the managed system, you can choose to boot a particular system profile.
Virtual Memory The process of using a portion of disk space as a temporary storage area for memory. Synonymous with Swap.
W
Web-based System Manager (WebSM) A GUI application that provides system management tasks in an easy-to-navigate fashion. Written in Java, this is a high portable tool, and plays a vital role in pSeries system administration. WorkLoad Manager (WLM) An application for managing given workloads on a single instance of AIX. This utility provides a simple management interface for handling CPU and memory allocation to a given population of users.
T
Trivial File Transfer Protocol (TFTP) A simplified version of FTP without authentication or many other basic features of FTP. Thread A small piece of programming that acts as an independent subset of a larger program, also called a process. A multithreaded program can run much faster than a monolithic, or singlethreaded, program because several, or even many, different tasks can be performed concurrently, rather than serially (sequentially). Also, threads within a single application can share resources and pass data back and forth among themselves. Touch A command that changes the date/time stamp of a file without affecting the contents. Translation Control Entries (TCE) TCE memory is used to translate the I/O addresses to system memory addresses. This is a global amount of memory that is not based on the number of partitions. This memory is allocated for the total number of I/O slots regardless of whether theyre actually used or not. TrueType Fonts A wide variety of fonts designed to be printer-independent, unlike PostScript fonts. Available for the Apple Macintosh and Windows. Not commonly used with UNIX/Linux. (Also, see BDF Fonts and PostScript Fonts.) Tux The name of the fictional Linux penguin mascot.
X
X Window System A graphical windowing environment for UNIX. The underlying programming required by many user interfaces. (Also, see Desktop, Window Manager, and XFree86.) X11 Version 11 of the X Window System. X Display Manager (XDM) User-friendly login front end for the X Window System. Often used in a cyber caf or campus environment where users who are not familiar with UNIX need occasional access. XFree86 A version of the X Window System for Linux. Used by GNOME, KDE and other Linux user interfaces/window managers. eXtensible Hyper Text Markup Language (XHTML) An enhanced version of HTML that supports programmer-defined extensions like XML. eXtensible Markup Language (XML) A powerful new markup language for designing Web pages; an alternative to the older HTML, allowing programmers to define their own markup tags, or formatting commands.
U
Universal Emergency Power Off (UEPO) Provides external switch that shuts off all power in a pSeries system. Universal Time Constant (UTC) A time scale that couples Greenwich Mean Time, which is based solely on the Earth's inconsistent rotation rate, with highly accurate atomic time. When atomic time and Earth time approach a one second difference, a leap second is calculated into UTC. UNIX UNIX began as a proprietary operating system developed by Bell Laboratories in the 1960s. It eventually spawned a number of mutually incompatible commercial versions from such companies as Apple (Mac OS X), Digital (Digital UNIX), Hewlett-Packard (HPUX), IBM (AIX), NeXT (NeXTSTEP) and others.
Y Z
V
Vital Product Data (VPD) Hardware and software components contain information to assist in tracking, troubleshooting, and licensing. VPD information is used to identify system resources.
Glossary
X-11
Student Notebook
V5.2
Student Notebook
IX
Index
Symbols
$DISPLAY 5-19 $HOME/.toprc 10-19 %packages 1-14 %post 1-14 %pre 1-14 .discinfo 4-32 .rpm 4-7 .rpmorig file 4-12 .rpmsave file 4-12 .Xauthority 5-20 /boot/grub/menu.lst 2-9 /dev/dsp 7-13 /dev/lp0 7-12 /dev/psaux 7-12 /dev/shm 9-33 /dev/ttyS0 7-8 /etc/anacrontab 11-10, 11-12 /etc/at.allow 11-16 /etc/at.deny 11-16 /etc/cron.allow 11-5 /etc/cron.deny 11-5 /etc/crontab 11-9 /etc/cups/classes.conf 3-19 /etc/cups/client.conf 3-20 /etc/cups/cups.conf 3-22 /etc/cups/cupsd.conf 3-19 /etc/cups/printers.conf 3-20 /etc/fstab 9-21, 9-23, 9-25, 9-33, 9-37, 10-7 /etc/group 13-19, 14-6 /etc/gshadow 13-11, 13-19 /etc/init.d/boot 2-19 /etc/init.d/rc 2-19 /etc/inittab 2-18, 2-29, E-29 /etc/issue 13-20 /etc/login.defs 13-11, 13-12 /etc/logrotate.conf 6-12 /etc/motd 13-21 /etc/nologin 14-11 /etc/passwd 13-16, 14-6 /etc/rc.d/rc 2-19 /etc/rc.d/rc.sysinit 2-19 /etc/securetty 14-11 /etc/security 14-13 /etc/sendmail.cf 4-17 /etc/shadow 13-11, 13-12, 13-17, 14-6 /etc/skel 13-13 /etc/smartd.conf 8-14 /etc/sudoers 14-24, 14-25 /etc/syslog.conf 6-7 /etc/syslogd.conf 6-4 /proc 10-11, 10-28
/proc//maps 10-10, 10-31 /proc//status 10-10, 10-29 /proc/lvm 8-33 /proc/meminfo 10-10, 10-13, 10-14, 10-15 /proc/sys E-33 /sbin/hotplug 7-15 /sbin/init E-29 /var/adm/backup/rpmdb 4-10 /var/lib/rpm 4-9, 4-10, 4-17 /var/log/lastlog 14-26 /var/log/messages 14-26, 15-5 /var/log/secure 14-26 /var/log/wtmp 14-26 /var/run/nscd/passwd 10-32 /var/run/umtp 14-27 /var/spool 3-13 __db.001 4-10 __db.002 4-10 __db.003 4-10
A
Access Control List 9-17 ACL. See Access Control List adduser 13-12 administrator policy D-9 air conditioning C-10 Air conditioning capacity C-11 air fans C-15 AIX 8-33 alsaconf 7-13 anaconda-ks.cfg 1-14 anacron 11-10 at 11-13 -d option 11-16 -l option 11-16 ATAPI 8-12 atd 11-13 atime 9-12 atq 11-16 atrm 11-16 authconfig 3-5, 14-12 authentication 14-3 authorization 14-4
B
B+ trees 9-18 Basenames 4-9 bash 2-27 Basic Input Output System batch 11-15
2-4
Index
X-13
Student Notebook
bin/bash E-29 binary RPM 4-22 binary trees 9-18 BIOS. See Basic Input Output System block device 7-3, 8-4 boot device 2-4 boot loader 2-5, E-6 British Thermal Units C-11
C
carbon monoxide C-12 CardBus 7-15 cardmgr 7-15 cat 10-29, E-33 cd 14-17 CD-ROM 1-7 character device 7-3 chattr 9-29 chgrp 14-18 chmod 14-18 chown 14-18 chroot 15-18, 15-19, 15-22, 15-25 circuit breakers C-8 cleaning C-15 computer room C-4 Conflictname 4-9 console 7-3 convertquota 9-36 core file 15-9 cpio 4-3, 12-10, 12-14 Cron 11-4 crond 11-4 crontab 11-4, 11-8 -e option 11-8 -l option 11-8 -r option 11-8 crypt 13-17 ctime 9-12 Ctrl-Alt-Backspace 5-14 Ctrl-Alt-Delete 2-19, 2-29 CUPS 3-16 cups-config-daemon 3-19 cupsd 3-18, 3-19, 3-22, 3-26 cups-lpd 3-18, 3-19 cupsys-client 3-20 curses 3-4
depmod E-25, E-31 dictionary attack 13-10, 14-11 diesel generator C-9 diff E-13 dig 4-15 directory 9-14 Dirnames 4-9 Disk Druid 8-17 -display 5-19 display manager 2-29 dmesg 2-12, 8-12, E-24 double indirect block 9-13 dump 9-22, 12-10, 12-15 DVD 1-7
E
e2label 9-29 echo E-33 edquota 9-38 EEPROM 2-4 E-IDE 8-11 electric power C-8 encryption 8-20 exit 15-22, 15-25 ext2 9-9, 9-28 ext3 2-13, 9-9, 9-28 extended partition 8-15
F
fdformat 8-10 fdisk 8-17, 10-7, 15-24 file 9-4, 14-16 Filemd5s 4-9 filesystem 9-4 find 14-17 fips 8-17 fire detection C-12 fire suppression C-12 Firefox 3-11 free 10-10, 10-15, 10-16, 10-17 freeramdisk 8-18 fsck 9-18, 9-22, 9-26, 15-14, E-29 -y option 9-27 ftp 14-6 full backup 12-5 fuses C-8
D
data backup 12-5 Data block 9-10 data block 9-14 dd 10-9, 12-10, 12-16 debugfs 9-29 debugreiserfs 9-31
G
galeon 3-11 gdb 15-10 gdm 2-19, 5-15, 5-25 getty 2-19 GID 13-3, 13-16
Student Notebook
gnorpm 4-31 GNU 4-4 grace period 9-34 grep 6-14 -v option 6-15 ground C-14 Group 4-9 Group ID 13-3 GRUB 2-5 grub 2-7 grub-install 2-7 gzip 4-10
Journaling
9-17
K
kdeprint 3-20 kdm 2-19, 5-15, 5-25 kernel 2-11, E-3 kernel modules 2-13, E-16 kerneld E-26 Kickstart 1-14 klogd daemon 6-4 konqueror 3-11 kpackage 4-31 kprint 3-16 kprinter 3-26 ks.cfg file 1-14 ksconfig 1-14 KVM switches 7-10
H
halt 2-29, 15-25 Hard disks 8-11 Hard limit 9-34 Hardware RAID 8-39 Hardware-HOWTO 2-12 hotplug 7-15 humidity C-10 Hummingbird eXceed 5-8
L
Labels 9-18 last 14-26 lastlog 14-26 less 14-16 LILO 2-5 linuxrc 2-14 logcheck 6-15 logdigest 6-15 logger 6-9 logical partition 8-15 Logical Volume Management 8-21 Logical Volumes 8-22 login 14-6 logrotate 6-11, 6-12 logsurfer 6-15 logwatch 6-15 loop device 8-19 losetup 8-20 lp 3-16 lpadmin 3-20, 3-21 LPD 3-16, 3-17, 3-18, 3-19 lpr 3-16 LPRng 3-15 ls -l option 7-4 lsdev 7-19 lseek 9-18 lsmod E-25 Lucent winmodem 7-9 lvcreate 8-24, 8-27 lvdisplay 8-27 lvextend 8-30 LVM 2-13 LVM metadata 8-31 LVM. See Logical Volume Management
Index X-15
I
IBM MWave 7-9 IDE 8-11 immutable 9-18 incremental backup 12-5 Indirect block 9-10 indirect block 9-12 init 2-19, 2-22, 2-27, 5-15, 10-29 Initial RAM Disk 2-14 Initial Root Disk 2-14 initial root disk E-17 initrd 8-33, 8-50 Inode 9-10 inode 9-12, 9-14 inode block 9-10 insmod E-25 Installtid 4-9 internal modems 7-9 Internet Explorer 3-11 Intrusion Detection Systems 4-17 IPP 3-15, 3-16, 3-17, 3-18, 3-19 iptables 3-6 ISDN cards 7-9 ISO images 8-19 iso9660 9-20
J
JETDIRECT 3-17, 3-18 JFS 2-13, 9-9 Joules C-11

Student Notebook
lvm-mod 8-33 lvremove 8-27, 8-30 LX07 7-8
M
man 3-4, 10-12, 10-16, 10-19, 10-23, 10-27 -k option 4-15 Master Boot Record 2-4, 2-5 master boot record 8-15 MBR. See Master Boot Record MD5 13-17 MD5 checksum 4-16 Memory chips C-14 mgetty 7-10 mkbootdisk 15-12 mke2fs 9-19 -j option 9-28 mkfs 9-19 mkinitrd E-17 mkjfs 9-19 mkpasswd 13-15 mkreiserfs 9-19 mkswap 10-7, 10-8, 10-9 modinfo E-26, E-32 modprobe E-25, E-31 more 14-26 mount 8-19, 9-20, 9-21, 14-15, E-29 -o option 8-19, 9-20 -t option 9-20 mount point 9-6 mouse 7-12 mozilla 3-11 mtime 4-17, 9-12 multiport cards 7-8 MWave 7-9
N
Name 4-9 NCP 3-17, 3-18 netconfig 3-6 netscape 3-11 network install server 1-8, 1-9 network installation 1-7 nslookup 4-15 ntsysv 3-6 null device 7-3 null-modem cable 7-10
PAM 14-5, 14-13 parted 8-17 partition table 2-5, 8-17 partitioning 8-15 PartitionMagic 8-17 passwd 3-3, 13-15, 14-14, 15-18, 15-19 password 13-3, 14-11 password aging 13-11 patch E-13 patch files E-12 Paul Vixie 11-4 PCMCIA 7-15, 7-17 permission bits 14-16 Physical Extents 8-21 Physical Volume 8-21 pico 4-15 pivot_root 2-14 Pluggable Authentication Modules 14-5 poll_ppd_base 3-21 POSIX 9-33 poweroff 2-29 prefdm 2-19 primary group 13-7 primary partitions 8-15 printer queue 3-13 pristine sources 4-20, 4-22 procedure handbook D-12 Processor Address Extensio 10-4 procinfo 10-10, 10-11, 10-12 protected mode 2-12 Providename 4-9 Provideversion 4-9 ps 10-10, 10-25, 10-26, 10-27, 10-29 PTE 10-4 Pubkeys 4-10 pvcreate 8-24, 8-25 pvdisplay 8-25 pvmove 8-25, 8-29
Q
Quota 9-34 quota 9-40 quotacheck 9-37 quotaon 9-36, 9-37
R
rack-mounted C-6 RAID 2-13 RAID-0 8-36 RAID-1 8-37 RAID-4 8-37 RAID-5 8-37 raidhotadd 8-49 raidhotremove 8-49
O
opera
3-11
P
Packages
4-9 X-16 Linux System Administration I
Student Notebook
RAID-Linear 8-36 raidsetfaulty 8-46 raidtools 8-39 RAM disk 8-18 random number generator 7-3 rc 2-21, 2-25 reboot 2-29 Red Hat Network 4-35 Red Hat Package Manager 4-4 Redundant Array of Inexpensive Disks 8-34 ReiserFS 2-13, 9-9, 9-30 reiserfsck 9-31 reject files E-13 remount E-29 repquota 9-40 Requirename 4-10 Requireversion 4-10 resize_reiserfs 9-31 resize2fs 9-29 restore 12-15 rhnsd 4-35 rm 14-16 rmmod E-25 rpm 4-5, 4-8, 4-10, 4-12, 4-13, E-7, E-9 -a option 4-14 -c option 4-15 --checksig option 4-18, 4-19 -d option 4-15 -e option 4-13 -F option 4-12, 4-33 -f option 4-14 -h option 4-12 -i option 4-11, 4-14 --import option 4-18 -l option 4-15 --nodeps option 4-12, 4-13 -p option 4-14 -q option 4-14 -qdf options 4-15 -qif options 4-15 -qila options 4-15 -s option 4-15 -U option 4-12 -V option 4-16, 4-17 -v option 4-12 RPM Package Manager 4-3, 4-4 RPM. See RPM Package Manager rpm2cpio 4-8 rpmbuild 4-8, 4-21, 4-28 -bb option 4-21 rpmqpack 4-8
S
script D-9 SCSI 2-13, 8-12
SCSI ID 8-12 scsi_info 8-12 security policy D-11 Self Monitoring and Reporting Technology 8-13 Self-Referencing Acronym 4-4 sendmail 4-17 serial terminal 7-3 serial terminals 7-10 service 2-25 Session Manager 5-15 setserial 7-9 setup 3-5, 3-8 SGID 14-17, 14-18 Sha1header 4-10 shadow password suite 13-11 Shared Memory Filesystem 9-33 shutdown 2-19, 2-29 Sigmd5 4-10 sine wave C-9 single 2-27 Single-User Mode 2-27 SMART 8-13 smartctl 8-13 -a option 8-13 -x option 8-13 smartd 8-14 smartd.conf 8-14 smartmontools 8-13 SMB 3-17, 3-18 Smoke detectors C-12 snapshot 8-32 Soft limit 9-34 Software RAID 8-39 sound card 7-13 Source RPM 4-20 spare disks 8-51 sparse files 9-18 SPEC file 4-22, 4-23 %doc identifier 4-27 changelog section 4-27 files section 4-27 install section 4-26 preamble section 4-25 prep section 4-26 SRA. See Self-Referencing Acronym ssh 3-4 stand-alone C-6 startx 5-12 statm 10-29 Sticky Bit 14-17 sticky bit 14-18 striping 8-28 su 14-15, 14-21, 14-23 sudo 14-15, 14-24, 14-25 SUID 14-17, 14-18 Sun Microsystems 14-5
Index X-17
Student Notebook
Superblock 9-10 superblock 9-11 Surge Arresters C-9 swap space 8-51 swapoff 10-8, 10-9 swapon 10-7, 10-9 swatch 6-15 Symbolic link 4-17 sysctl E-33 syslog daemon 6-4 syslogd -r option 6-8 syslogd daemon 6-4 System Administration Tools 3-3 system backup 12-5 system-config-authentication 3-7 system-config-boot 3-7 system-config-date 3-7, 3-8 system-config-display 3-6, 3-8 system-config-httpd 3-8 system-config-keyboard 3-6, 3-8 system-config-kickstart 3-8 system-config-language 3-8 system-config-lvm 3-8 system-config-mouse 3-8 system-config-netboot 3-8 system-config-network 3-7, 3-8 system-config-nfs 3-8 system-config-packages 3-8, 4-8, 4-31, 4-32 system-config-printer 3-8, 3-20, 3-23 system-config-printer-tui 3-6 system-config-rootpassword 3-8 system-config-samba 3-8 system-config-securitylevel 3-8 system-config-securitylevel-tui 3-6 system-config-services 3-8 system-config-sound 3-7 system-config-soundcard 3-8 system-config-time 3-7, 3-8 system-config-users 3-8 system-install-packages 4-8
U
UID 13-3, 13-16 ulimit 15-10 umask 14-19 umount 9-25 Uninterruptable Power Supplies C-9 UNIX socket 5-7, 6-4 up2date 4-35 UPS. See Uninterruptable Power Supply usbmodules 7-19 usbview 7-19 user account 13-5 user ID 13-3 user policy D-5, D-7 User Private Groups 13-8 useradd 3-3, 13-12 userdel 13-12 usermod 3-3, 13-12
V
VFS. See Virtual Filesystem Switch vgcfgbackup 8-31 vgcfgrestore 8-31 vgchange 8-26 vgcreate 8-24, 8-26 VGDA 8-25 vgdisplay 8-26 vgextend 8-29 vgreduce 8-29 vgremove 8-26 vi 14-16, 14-25 virtual filesystem 9-6 Virtual Filesystem Switch 9-7 visudo 14-25 vmstat 10-10, 10-21, 10-22, 10-23, 10-24 Volt C-9 Volume Group 8-21 Volume Group Descriptor Area 8-25, 8-31
W
wall 6-4, 6-8 Watt C-8, C-11 Webmin 3-10 Webmin installation 3-11 which 4-15 who 14-26, 14-27 window manager 5-5 winmodems 7-9 write 6-4, 6-8 WRQ Reflection X 5-8
T
tail 14-26 tar 4-3, 12-10, 12-11 telnet 3-4, 14-22 temperature C-10 timeconfig 3-6 ton C-11 toolbox C-15 top 10-10, 10-18, 10-19, 10-20, 10-29 Triggername 4-10 triple indirect block 9-13 tripwire 4-17 tune2fs 9-28
X
X server
5-5 Copyright IBM Corp. 2001, 2009
Student Notebook
X station 5-5 X Window System 5-3 xauth 5-20 xbanner 5-6 xcalc 5-6 xdm 2-19, 5-15, 5-24 xedit 5-6 xeyes 5-6 XFree86 5-9 XFS 9-9 xhost 5-20 xterm 5-5
Y
yast 3-20, 3-25, 4-31, 7-13, E-7 Yast Online Update 4-36 yast2 4-8, 4-32, E-7 Yellowdog Updater, Modified 4-33 you 4-36 yum 4-33, 4-34 yum-arch 4-33

Index
X-19
Student Notebook
V5.2
backpg
Back page

IUTXE Lx30stud

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

IUTXE Lx30stud

Transféré par

Droits d'auteur :

Formats disponibles

V5.

Linux System Administration I: Implementation

IBM certified course material

Linux System Administration I

Copyright IBM Corp. 2001, 2009

Linux System Administration I

Copyright IBM Corp. 2001, 2009

Copyright IBM Corp. 2001, 2009

Linux System Administration I

Copyright IBM Corp. 2001, 2009

Linux System Administration I

Copyright IBM Corp. 2001, 2009

Linux System Administration I

Copyright IBM Corp. 2001, 2009

Distribution naming conventions

xviii Linux System Administration I

Copyright IBM Corp. 2001, 2009

Linux Professional Institute statement

Copyright IBM Corp. 2001, 2009

Linux System Administration I

Copyright IBM Corp. 2001, 2009

Unit 1. Advanced Linux installation

What you should be able to do

How you will check your progress

Copyright IBM Corp. 2001, 2009

Unit 1. Advanced Linux installation

Copyright IBM Corporation 2009

Figure 1-1. Unit objectives

Linux System Administration I

Copyright IBM Corp. 2001, 2009

Installing Linux: Review

Copyright IBM Corporation 2009

Figure 1-2. Installing Linux: Review

Check for updated information

Linux System Administration I

Copyright IBM Corp. 2001, 2009

Disk partitioning: Review

Master Boot Record (MBR) Partition table MS Windows

Linux / Linux /home Linux swap

Figure 1-3. Disk partitioning: Review

Copyright IBM Corp. 2001, 2009

Unit 1. Advanced Linux installation

Linux System Administration I

Copyright IBM Corp. 2001, 2009

Copyright IBM Corporation 2009

Figure 1-4. Network installations

Linux System Administration I

Copyright IBM Corp. 2001, 2009

Network install server: Overview

For example: /export/rhel51s, /export/fedo8, /export/suse10sp1, ... Method

Copyright IBM Corporation 2009

Figure 1-5. Network install server: Overview

Notes: Image server

1-10 Linux System Administration I

Copyright IBM Corp. 2001, 2009

Network install server: Configuration

Copyright IBM Corporation 2009

Figure 1-6. Network install server: Configuration

Copyright IBM Corp. 2001, 2009

Unit 1. Advanced Linux installation

1-12 Linux System Administration I

Copyright IBM Corp. 2001, 2009