IUTXE_lx30stud

V5.2

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™

AT® Chipkill™ eServer™ i5/OS®

LoadLeveler® Notes® OS/390® POWER4™ RS/6000® System i™ System p5™ System z9® z9™ 400®

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 customer’s ability to evaluate and integrate them into the customer’s operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will result elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.

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

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.

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

© Copyright IBM Corp. 2001, 2009 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

Contents

v

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

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

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 © Copyright IBM Corp. 2001, 2009 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

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

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

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 © Copyright IBM Corp. 2001, 2009 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

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

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

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 © Copyright IBM Corp. 2001, 2009 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

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

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.

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™

AT® Chipkill™ eServer™ i5/OS®

LoadLeveler® Notes® OS/390® POWER4™ RS/6000® System i™ System p5™ System z9® z9™ 400®

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. © Copyright IBM Corp. 2001, 2009 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

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

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.

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 © Copyright IBM Corp. 2001, 2009 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

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

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.

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 © Copyright IBM Corp. 2001, 2009 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

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

© Copyright IBM Corp. 2001, 2009

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

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

© Copyright IBM Corp. 2001, 2009

Certification information

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

xix

Student Notebook

xx

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.

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

© Copyright IBM Corp. 2001, 2009

Unit 1. Advanced Linux installation

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

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

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.

V5.2 Student Notebook

Uempty

Installing Linux: Review • • • • •

Documentation Hardware requirements System resources Installation resources Check for updated information

© Copyright IBM Corporation 2009

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

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

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 system’s 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

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.

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

Linux / Linux /home Linux swap

sda1: First primary partition holds a Microsoft Windows filesystem

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 © Copyright IBM Corporation 2009

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 1

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

© Copyright IBM Corp. 2001, 2009

Unit 1. Advanced Linux installation

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

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

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.

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

© Copyright IBM Corporation 2009

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 © Copyright IBM Corp. 2001, 2009

Unit 1. Advanced Linux installation

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

1-7

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

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.

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

© Copyright IBM Corporation 2009

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. © Copyright IBM Corp. 2001, 2009

Unit 1. Advanced Linux installation

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

1-9

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

© Copyright IBM Corp. 2001, 2009

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

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

© Copyright IBM Corporation 2009

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/,

© Copyright IBM Corp. 2001, 2009

Unit 1. Advanced Linux installation

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

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.

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

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 © Copyright IBM Corporation 2009

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 root’s home directory in a file /root/anaconda-ks.cfg. To create a kickstart file from scratch, use the system-config-kickstart utility. © Copyright IBM Corp. 2001, 2009

Unit 1. Advanced Linux installation

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

1-13

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 Fedora’s method of automating installations. It involves creating a ks.cfg file, which contains three sections: - The first section, which starts at the top of the file, contains the answers to all questions of the installation process. For instance, if the statement lang en_US is present in the kickstart file, the question “What language do you want to use during the installation process?” will not be asked, 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.

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

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 . . . © Copyright IBM Corporation 2009

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 © Copyright IBM Corp. 2001, 2009

Unit 1. Advanced Linux installation

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

1-15

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.

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

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

© Copyright IBM Corporation 2009

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 that’s 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. © Copyright IBM Corp. 2001, 2009

Unit 1. Advanced Linux installation

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

1-17

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.

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

V5.2 Student Notebook

Uempty

AutoYaST example false true /boot/message 0 1 /dev/hda7,/dev/hda 8 piix processor thermal . . . © Copyright IBM Corporation 2009

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.

© Copyright IBM Corp. 2001, 2009

Unit 1. Advanced Linux installation

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

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?

© Copyright IBM Corporation 2009

Figure 1-11. Checkpoint

LX036.0

Notes: Write down your answers here:

1. 2. 3.

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

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

© Copyright IBM Corporation 2009

Figure 1-12. Exercise 1: Advanced Linux installation

LX036.0

Notes:

© Copyright IBM Corp. 2001, 2009

Unit 1. Advanced Linux installation

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

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.

© Copyright IBM Corporation 2009

Figure 1-13. Unit summary

LX036.0

Notes:

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

V5.2 Student Notebook

Uempty

Unit 2. Startup and shutdown What this unit is about This unit teaches you how the startup process of a Linux system actually works and how to shut down a Linux system properly.

What you should be able to do 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

How you will check your progress 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

© Copyright IBM Corp. 2001, 2009

Unit 2. Startup and shutdown

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

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

© Copyright IBM Corporation 2009

Figure 2-1. Unit objectives

LX036.0

Notes:

2-2

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.

V5.2 Student Notebook

Uempty

Linux startup flow power on BIOS Hardware boot boot loader

Software boot

Low level initialization of important hardware (disk, CPU, VGA adapter...) Usually GRUB

Linux kernel and initrd

Full initialization of all hardware

init

Runs boot scripts and starts system services

system ready © Copyright IBM Corporation 2009

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.

© Copyright IBM Corp. 2001, 2009

Unit 2. Startup and shutdown

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

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

© Copyright IBM Corporation 2009

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

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.

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) © Copyright IBM Corporation 2009

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.

© Copyright IBM Corp. 2001, 2009

Unit 2. Startup and shutdown

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

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

© Copyright IBM Corporation 2009

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

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.

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.

© Copyright IBM Corp. 2001, 2009

Unit 2. Startup and shutdown

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

2-7

Student Notebook

GRUB startup sequence MBR

contains stage1

addresses stage1_5 (CHS)

Stage 1

filesystem driver, loads (hd0,3)/grub/stage2

Stage 1_5

Configuration: /boot/grub/menu.lst loads for example, (hd0,3)/vmlinuz or Windows via "chainloading"

Stage 2

© Copyright IBM Corporation 2009

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

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.

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

© Copyright IBM Corporation 2009

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

timeout=5

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.

© Copyright IBM Corp. 2001, 2009

Unit 2. Startup and shutdown

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

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.

2-10 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.

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. 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 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000017ee06c0 (usable) BIOS-e820: 0000000017ee06c0 - 0000000017ee66c0 (ACPI data) BIOS-e820: 0000000017ee66c0 - 0000000017eee700 (ACPI NVS) BIOS-e820: 0000000017eee700 - 0000000018000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) 0MB HIGHMEM available. 382MB LOWMEM available. found SMP MP-table at 0009fe00 On node 0 totalpages: 98016 © Copyright IBM Corporation 2009

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

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

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.

2-12 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.

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 © Copyright IBM Corporation 2009

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.

© Copyright IBM Corp. 2001, 2009

Unit 2. Startup and shutdown

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

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 kernel’s 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.

2-14 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.

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 © Copyright IBM Corporation 2009

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 © Copyright IBM Corp. 2001, 2009

Unit 2. Startup and shutdown

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

2-15

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.d (SUSE) or /etc/rc.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 2-16 Linux System Administration I

last=S © Copyright IBM Corp. 2001, 2009

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

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.

© Copyright IBM Corp. 2001, 2009

Unit 2. Startup and shutdown

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

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

# 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

SLES

The default runlevel is 3

# Default runlevel id:3:initdefault:

Always run /etc/rc.d/rc.sysinit (RHEL) or /etc/init.d/boot (SLES)

# 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

Run /etc/rc.d/rc (RHEL) or /etc/init.d/rc (SLES) with the runlevel as parameter

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

© Copyright IBM Corporation 2009

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.

2-18 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.

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 getty’s 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. © Copyright IBM Corp. 2001, 2009

Unit 2. Startup and shutdown

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

2-19

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.

2-20 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.

V5.2 Student Notebook

Uempty

Starting services (System V init style) /etc/rc.d/rc 3 (RHEL/Fedora) /etc/init.d/rc 3 (SLES)

init

/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

© Copyright IBM Corporation 2009

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

This directory is a symlink to /etc/init.d/rc.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 . In that case, it might be necessary to stop services, for instance when switching from a multiuser to a single-user runlevel. 3

© Copyright IBM Corp. 2001, 2009

Unit 2. Startup and shutdown

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

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

4

Depends on the distribution used.

2-22 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.

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

© Copyright IBM Corporation 2009

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. That’s why several tools exist for this: - chkconfig command - system-config-services (RHEL/Fedora) - yast (SLES)

5

In some UNIX variants, you are actually required to do this.

© Copyright IBM Corp. 2001, 2009

Unit 2. Startup and shutdown

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

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

2-24 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.

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:

SLES # rcatd restart Shutting down service at daemon Starting service at daemon

[ OK ] [ OK ]

done done

© Copyright IBM Corporation 2009

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

© Copyright IBM Corp. 2001, 2009

Unit 2. Startup and shutdown

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

2-25

Student Notebook

For example, to restart the atd daemon: # service atd restart (RHEL/Fedora) # rcatd restart (SLES)

2-26 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.

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

© Copyright IBM Corporation 2009

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.

© Copyright IBM Corp. 2001, 2009

Unit 2. Startup and shutdown

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

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

2-28 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.

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

© Copyright IBM Corporation 2009

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.

© Copyright IBM Corp. 2001, 2009

Unit 2. Startup and shutdown

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

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

© Copyright IBM Corporation 2009

Figure 2-17. Checkpoint

LX036.0

Notes: Write down your answers here:

1.

2.

2-30 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.

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

© Copyright IBM Corporation 2009

Figure 2-18. Exercise 2: Startup and Shutdown

LX036.0

Notes:

© Copyright IBM Corp. 2001, 2009

Unit 2. Startup and shutdown

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

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

© Copyright IBM Corporation 2009

Figure 2-19. Unit summary

LX036.0

Notes:

2-32 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.

V5.2 Student Notebook

Uempty

Unit 3. System administration tools What this unit is about This unit gives you an overview of the different integrated system administration tools that might be available on your distribution.

What you should be able to do 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

How you will check your progress Accountability: • Checkpoint questions • Exercise

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

© Copyright IBM Corp. 2001, 2009

Unit 3. System administration tools

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

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

© Copyright IBM Corporation 2009

Figure 3-1. Unit objectives

LX036.0

Notes:

3-2

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.

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?

© Copyright IBM Corporation 2009

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 user’s password (passwd command) © Copyright IBM Corp. 2001, 2009

Unit 3. System administration tools

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

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

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

V5.2 Student Notebook

Uempty

RHEL/Fedora setup • Menu-based front end for various tools that are part of the text-based installation

© Copyright IBM Corporation 2009

Figure 3-3. RHEL/Fedora setup

LX036.0

Notes: Introduction The command setup is Red Hat’s/Fedora’s 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

© Copyright IBM Corp. 2001, 2009

Unit 3. System administration tools

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

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:

Keyboard configuration

/usr/bin/system-config-keyboard --text This menu selection configures the network. It calls the text menu command:

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

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.

V5.2 Student Notebook

Uempty

RHEL/Fedora system-config-*

system-config-network system-config-time system-config-soundcard

© Copyright IBM Corporation 2009

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

© Copyright IBM Corp. 2001, 2009

Unit 3. System administration tools

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

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

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)

system-config-packages

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

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.

V5.2 Student Notebook

Uempty

SUSE YaST

© Copyright IBM Corporation 2009

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. © Copyright IBM Corp. 2001, 2009

Unit 3. System administration tools

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

3-9

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

© Copyright IBM Corporation 2009

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.

3-10 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.

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

© Copyright IBM Corporation 2009

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.

© Copyright IBM Corp. 2001, 2009

Unit 3. System administration tools

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

3-11

Student Notebook

Webmin screenshot

© Copyright IBM Corporation 2009

Figure 3-8. Webmin screenshot

LX036.0

Notes: Introduction This is an example screenshot of Webmin.

3-12 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.

V5.2 Student Notebook

Uempty

Users, printer queues, printers

Queue “bulk”

Queue “color”

© Copyright IBM Corporation 2009

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 © Copyright IBM Corp. 2001, 2009

Unit 3. System administration tools

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

3-13

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

© Copyright IBM Corporation 2009

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.

3-14 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.

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.

© Copyright IBM Corp. 2001, 2009

Unit 3. System administration tools

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

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

© Copyright IBM Corporation 2009

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.

3-16 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.

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

© Copyright IBM Corp. 2001, 2009

Unit 3. System administration tools

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

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

Printer filter

BSD commands (lpr, ...) System V commands (lp, ...)

Backends kdeprint © Copyright IBM Corporation 2009

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

3-18 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.

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 . . . Order Deny,Allow Deny From All Allow From 127.0.0.1 AuthType None 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. © Copyright IBM Corp. 2001, 2009

Unit 3. System administration tools

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

3-19

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

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

3-20 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.

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 © Copyright IBM Corporation 2009

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

© Copyright IBM Corp. 2001, 2009

Unit 3. System administration tools

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

3-21

Student Notebook

CUPS configuration with a browser • Use URL http://localhost:631

© Copyright IBM Corporation 2009

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 directive in the /etc/cups/cups.conf file to allow specific IP addresses to utilize this CUPS administration interface. 3-22 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.

V5.2 Student Notebook

Uempty

CUPS configuration with system-config-printer • system-config-printer: Standard printer configuration tool with RHEL/Fedora

© Copyright IBM Corporation 2009

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.

© Copyright IBM Corp. 2001, 2009

Unit 3. System administration tools

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

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.

3-24 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.

V5.2 Student Notebook

Uempty

CUPS configuration with yast • yast: Text/GUI based tool that has a configuration module for printers on SLES

© Copyright IBM Corporation 2009

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.

© Copyright IBM Corp. 2001, 2009

Unit 3. System administration tools

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

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

© Copyright IBM Corporation 2009

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.

3-26 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.

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? © Copyright IBM Corporation 2009

Figure 3-18. Checkpoint

LX036.0

Notes: Write down your answers here:

1. 2. 3. 4.

© Copyright IBM Corp. 2001, 2009

Unit 3. System administration tools

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

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.

© Copyright IBM Corporation 2009

Figure 3-19. Exercise 3: System administration tools

LX036.0

Notes:

3-28 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.

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.

© Copyright IBM Corporation 2009

Figure 3-20. Unit summary

LX036.0

Notes:

© Copyright IBM Corp. 2001, 2009

Unit 3. System administration tools

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

3-29

Student Notebook

3-30 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.

V5.2 Student Notebook

Uempty

Unit 4. Package management What this unit is about This unit teaches you how to use the most common packaging tool on a Linux system, the Red Hat/RPM Package Manager (RPM).

What you should be able to do 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

How you will check your progress Accountability: • Checkpoint questions • Exercise

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

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

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

© Copyright IBM Corporation 2009

Figure 4-1. Unit objectives

LX036.0

Notes:

4-2

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.

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)

© Copyright IBM Corporation 2009

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. © Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

4-3

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

© Copyright IBM Corporation 2009

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, that’s a self-referencing acronym (SRA), just like GNU.

4-4

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.

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

© Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

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

© Copyright IBM Corporation 2009

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

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.

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

© Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

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)

© Copyright IBM Corporation 2009

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

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.

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)

© Copyright IBM Corporation 2009

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

© Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

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

4-10 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.

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: ##################################################

© Copyright IBM Corporation 2009

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 © Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

4-11

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.

4-12 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.

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)

© Copyright IBM Corporation 2009

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.

© Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

4-13

Student Notebook

RPM querying • Queries the contents of an installed RPM • Basic syntax: – rpm -q package-name

• Options: -a -f -p -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

© Copyright IBM Corporation 2009

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 Queries which package contains . -p Queries the (not yet installed) . Displays all package information: name, version, release, install date, group, size, -i summary, description, build information and so forth. 4-14 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.

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

© Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

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 © Copyright IBM Corporation 2009

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? 4-16 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.

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.

© Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

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) © Copyright IBM Corporation 2009

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. 4-18 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.

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.

© Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

4-19

Student Notebook

RPM philosophy developer

distributor

application.tar.gz

application.tar.gz patches

SPEC file

sample config files application.src.rpm

application.sparc.rpm

application.i386.rpm

application.s390.rpm

rpmbuild –bb on sparc

rpmbuild -bb on i386

rpmbuild –bb on s390

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

© Copyright IBM Corporation 2009

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.

4-20 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.

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.

© Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

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

© Copyright IBM Corporation 2009

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

4-22 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.

V5.2 Student Notebook

Uempty

- The install and uninstall scripts are scripts that are executed on the user’s 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.

© Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

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:

hello-1.2/README:

#include main() { printf("Hello, World!\n"); }

hello-1.2/Makefile: all: hello hello: hello.c gcc -o hello hello.c

(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

clean: rm -f hello

install: hello install -d $(DESTDIR)/usr/bin install -s -m 0755 -o root -g root hello $(DESTDIR)/usr/bin/hello © Copyright IBM Corporation 2009

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, you’ve 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 4-24 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.

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 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!

© Copyright IBM Corporation 2009

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.

© Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

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 - Made compatible with FedoC4/RHEL/SLES9 * Tue Mar 09 2004 - version 1.1 - John Doe - Made to work under RPM v4 * Tue Jul 20 1999 - version 1.0 - John Doe - Initial release

© Copyright IBM Corporation 2009

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 don’t need to specify any commands at all: Just specifying %setup will do. - In the build phase, the commands required to build the program are executed. In most cases, a package 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 we’re installing our package relative to ${BUILDROOT}. This prevents conflicts with existing packages on our system. 4-26 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.

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/. The changelog section is not required but can be very useful. It contains a list of changes made to the SPEC file.

© Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

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 # 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

© Copyright IBM Corporation 2009

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 4-28 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.

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.

© Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

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/ • 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

© Copyright IBM Corporation 2009

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/. The binary RPM can then be queried, installed, and deinstalled as any other RPM.

4-30 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.

V5.2 Student Notebook

Uempty

Integrated package management

system-config-packages

yast (install and remove software)

system-install-packages © Copyright IBM Corporation 2009

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. © Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

4-31

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, Don’t 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.

4-32 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.

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]

© Copyright IBM Corporation 2009

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

© Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

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.

4-34 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.

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)

© Copyright IBM Corporation 2009

Figure 4-21. Keeping up-to-date (Red Hat)

LX036.0

Notes: Introduction Red Hat’s solution for keeping your systems up to date is called the Red Hat Network. For this to work, you need to create an account on http://rhn.redhat.com, and register your systems with 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.

© Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

4-35

Student Notebook

Keeping up-to-date (SUSE Linux) • YaST Online Update (you): Program that downloads/installs patches from any SUSE mirror

© Copyright IBM Corporation 2009

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.

4-36 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.

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

© Copyright IBM Corporation 2009

Figure 4-23. Checkpoint

LX036.0

Notes: Write down your answers here:

1. 2. 3.

© Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

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

© Copyright IBM Corporation 2009

Figure 4-24. Exercise 4: Packaging tools

LX036.0

Notes:

4-38 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.

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.

© Copyright IBM Corporation 2009

Figure 4-25. Unit summary

LX036.0

Notes:

© Copyright IBM Corp. 2001, 2009

Unit 4. Package management

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

4-39

Student Notebook

4-40 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.

V5.2 Student Notebook

Uempty

Unit 5. X Window system What this unit is about The unit teaches you how to use and configure the X Window system.

What you should be able to do 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

How you will check your progress Accountability: • Checkpoint questions • Exercise

References Linux man pages The X.org Foundation, http://x.org/ SUSE Linux 10 Administration Guide Red Hat Enterprise Linux V5 Administration Guide

© Copyright IBM Corp. 2001, 2009

Unit 5. X Window system

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

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

© Copyright IBM Corporation 2009

Figure 5-1. Unit objectives

LX036.0

Notes:

5-2

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.

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

© Copyright IBM Corporation 2009

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

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

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

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.

V5.2 Student Notebook

Uempty

X client/server architecture The X Station

X server

Window manager

Client-App 1

Client-App n

Host-1 Client-App z

Host-z

© Copyright IBM Corporation 2009

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

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

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

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.

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

© Copyright IBM Corporation 2009

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.

© Copyright IBM Corp. 2001, 2009

Unit 5. X Window system

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

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

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.

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

© Copyright IBM Corporation 2009

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.

© Copyright IBM Corp. 2001, 2009

Unit 5. X Window system

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

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

© Copyright IBM Corporation 2009

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 you’ve got an LCD panel, use one of these descriptions. 5-10 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.

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.

© Copyright IBM Corp. 2001, 2009

Unit 5. X Window system

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

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

© Copyright IBM Corporation 2009

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 it’s not really relevant how each distribution does this. Most Linux systems will employ a display manager (covered in the next visual), which allows you to choose your window manager. 5-12 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.

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.

© Copyright IBM Corp. 2001, 2009

Unit 5. X Window system

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

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

© Copyright IBM Corporation 2009

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.

5-14 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.

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)

© Copyright IBM Corporation 2009

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 user’s 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).

© Copyright IBM Corp. 2001, 2009

Unit 5. X Window system

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

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

© Copyright IBM Corporation 2009

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

5-16 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.

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.

© Copyright IBM Corp. 2001, 2009

Unit 5. X Window system

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

5-17

Student Notebook

X applications networked

Xorg

xeyes

Window Mgr

Application Host (hostname host)

TCP/IP Network

X Station (hostname xstation)

© Copyright IBM Corporation 2009

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

5-18 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.

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 © Copyright IBM Corporation 2009

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.

© Copyright IBM Corp. 2001, 2009

Unit 5. X Window system

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

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

5-20 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.

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

© Copyright IBM Corp. 2001, 2009

Unit 5. X Window system

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

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

© Copyright IBM Corporation 2009

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.

5-22 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.

V5.2 Student Notebook

Uempty

X sessions networked

Xorg

xeyes Window Mgr

TCP/IP Network

Host

X Station

© Copyright IBM Corporation 2009

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.

© Copyright IBM Corp. 2001, 2009

Unit 5. X Window system

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

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

© Copyright IBM Corporation 2009

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.

5-24 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.

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

© Copyright IBM Corp. 2001, 2009

Unit 5. X Window system

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

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

© Copyright IBM Corporation 2009

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

5-26 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.

V5.2 Student Notebook

Uempty

Checkpoint 1.

What is the function of X.org? ______________________________________________

2.

What is the function of a window manager? ______________________________________________

3.

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

© Copyright IBM Corporation 2009

Figure 5-17. Checkpoint

LX036.0

Notes: Write down your answers here:

1.

2.

3.

© Copyright IBM Corp. 2001, 2009

Unit 5. X Window system

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

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

© Copyright IBM Corporation 2009

Figure 5-18. Exercise 5: X window system

LX036.0

Notes:

5-28 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.

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

© Copyright IBM Corporation 2009

Figure 5-19. Unit summary

LX036.0

Notes:

© Copyright IBM Corp. 2001, 2009

Unit 5. X Window system

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

5-29

Student Notebook

5-30 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.

V5.2 Student Notebook

Uempty

Unit 6. Logging What this unit is about This unit teaches you how to use logging.

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

How you will check your progress 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

© Copyright IBM Corp. 2001, 2009 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

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

© Copyright IBM Corporation 2009

Figure 6-1. Unit objectives

LX036.0

Notes:

6-2

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.

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. © Copyright IBM Corporation 2009

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 administrator’s 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.

© Copyright IBM Corp. 2001, 2009 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

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

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.

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

• Priority identifies the importance – – – – – –

panic crit warm info debug ...

• For a complete list, see man syslog.conf

© Copyright IBM Corporation 2009

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) © Copyright IBM Corp. 2001, 2009 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

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

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.

V5.2 Student Notebook

Uempty

/etc/syslog.conf • RHEL/Fedora example: kern.warn *.info;mail.none;authpriv.none;cron.none

/dev/tty10 /var/log/messages

mail.*

/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); };

© Copyright IBM Corporation 2009

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.

© Copyright IBM Corp. 2001, 2009 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

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

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.

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!

© Copyright IBM Corporation 2009

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. © Copyright IBM Corp. 2001, 2009 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

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

© Copyright IBM Corporation 2009

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.

6-10 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.

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

© Copyright IBM Corp. 2001, 2009 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

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 } © Copyright IBM Corporation 2009

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.

6-12 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.

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.

© Copyright IBM Corp. 2001, 2009 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

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

© Copyright IBM Corporation 2009

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 vi’s search capability) for interesting items. This is typically done when you are looking for something specific, such as all the actions of a particular user. Searching for specific items like this is called a positive search. 6-14 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.

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 administrator’s world. It is highly configurable and is capable of performing real-time logfile analysis: you’ll hear of any problems only a few seconds after the log lines are added to the logfile instead of having to wait for a scheduled logfile analysis.

© Copyright IBM Corp. 2001, 2009 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

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 don’t submit a report if there’s nothing to report. That means that not receiving a report may have two causes: - There is nothing to report - Your e-mail subsystem is broken or disabled Beware 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.

6-16 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.

V5.2 Student Notebook

Uempty

Checkpoint 1.

The ______________ receives all logging requests and forwards it to the right destination, depending on priority and facility.

2.

What does the logger command do? ______________________________________________

3.

The logrotate command a) b) c)

Creates new log files Rotates the log files Deletes log files

© Copyright IBM Corporation 2009

Figure 6-9. Checkpoint

LX036.0

Notes: Write down your answers here:

1. 2. 3.

© Copyright IBM Corp. 2001, 2009 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

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

© Copyright IBM Corporation 2009

Figure 6-10. Exercise 6: Logging

LX036.0

Notes:

6-18 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.

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.

© Copyright IBM Corporation 2009

Figure 6-11. Unit summary

LX036.0

Notes:

© Copyright IBM Corp. 2001, 2009 Course materials may not be reproduced in whole or in part without the prior written permission of IBM.

Unit 6. Logging

6-19

Student Notebook

6-20 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.

V5.2 Student Notebook

Uempty

Unit 7. Character devices, PCMCIA, and USB What this unit is about This unit describes character devices and the workings of the Personal Computer Memory Card International Association (PCMCIA) and Universal Serial Bus (USB) subsystems.

What you should be able to do 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

How you will check your progress 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.

© Copyright IBM Corp. 2001, 2009

Unit 7. Character devices, PCMCIA, and USB

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

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

© Copyright IBM Corporation 2009

Figure 7-1. Unit objectives

LX036.0

Notes:

7-2

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.

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

© Copyright IBM Corporation 2009

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 doesn’t: a character device can only be read from and written to serially. A lot of devices in Linux are character devices: - The console itself - Any serial terminals that are attached to the system. (A serial terminal is a combination of monitor and keyboard, which is attached via a serial cable to a serial port.) - Printers - Sound cards - The random number generator - The null device, which is typically used to discard unwanted data © Copyright IBM Corp. 2001, 2009

Unit 7. Character devices, PCMCIA, and USB

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

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

© Copyright IBM Corporation 2009

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

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.

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

© Copyright IBM Corporation 2009

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 don’t 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

© Copyright IBM Corp. 2001, 2009

Unit 7. Character devices, PCMCIA, and USB

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

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 0’s. 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.

/dev/random

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.

7-6

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.

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.

© Copyright IBM Corp. 2001, 2009

Unit 7. Character devices, PCMCIA, and USB

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

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. © Copyright IBM Corporation 2009

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

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.

V5.2 Student Notebook

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

Uempty

- 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 you’ve got an external ISDN modem.

1

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

© Copyright IBM Corp. 2001, 2009

Unit 7. Character devices, PCMCIA, and USB

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

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. © Copyright IBM Corporation 2009

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

V5.2 Student Notebook

Uempty

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

© Copyright IBM Corp. 2001, 2009

Unit 7. Character devices, PCMCIA, and USB

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

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)

© Copyright IBM Corporation 2009

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.

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

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

© Copyright IBM Corporation 2009

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

© Copyright IBM Corp. 2001, 2009

Unit 7. Character devices, PCMCIA, and USB

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

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.

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

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 © Copyright IBM Corporation 2009

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.

© Copyright IBM Corp. 2001, 2009

Unit 7. Character devices, PCMCIA, and USB

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

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.

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

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 > Plug in a USB Mouse here