toc

Team LiB
Next Section

Official Red Hat Linux System Administrator's Guide
Official Red Hat Linux System Administrator's Guide
by The Red Hat Documentation Team ISBN:0764516957
Hungry Minds © 2003 (513 pages)

Your single official source for documentation, instruction, and answers about Red Hat Linux 8, this resource delivers all the know-how you need to manage Linux networks and systems, troubleshoot problems, and provide optimum client service.

Table of Contents
 | Official Red Hat Linux Administrator’s Guide
 | Foreword
 | Introduction
 | Part I - Essential Information
 | Chapter 1 | - | Kickstart Installations
 | Chapter 2 | - | Boot Process, init, and Shutdown
 | Chapter 3 | - | GRUB
 | Chapter 4 | - | Red Hat Linux File System
 | Chapter 5 | - | Gathering System Information
 | Part II - Basic System Administration
 | Chapter 6 | - | General System Configuration
 | Chapter 7 | - | Users and Groups
 | Chapter 8 | - | Printer Configuration
 | Chapter 9 | - | X Servers and Clients
 | Chapter 10 | - | Automated Tasks
 | Chapter 11 | - | Redundant Array of Independent Disks (RAID)
 | Chapter 12 | - | Kernel Management
 | Part III - Network Administration
 | Chapter 13 | - | Network Configuration
 | Chapter 14 | - | Network Scripts
 | Chapter 15 | - | Dynamic Host Configuration Protocol (DHCP)
 | Chapter 16 | - | BIND Configuration
 | Chapter 17 | - | Lightweight Directory Access Protocol (LDAP)
 | Chapter 18 | - | Email
 | Chapter 19 | - | Apache HTTP Server Configuration
 | Chapter 20 | - | Network File System (NFS) and Samba
 | Part IV - Security
 | Chapter 21 | - | Controlling Access to Services
 | Chapter 22 | - | Basic Firewall Configuration
 | Chapter 23 | - | Kerberos
 | Chapter 24 | - | OpenSSH
 | Chapter 25 | - | Pluggable Authentication Modules (PAM)
 | Chapter 26 | - | Tripwire
 | Part V - Appendixes
 | Appendix A | - | Installing Red Hat Linux
 | Appendix B | - | Rescue Mode
 | Appendix C | - | General Parameters and Modules
 | Index
 | List of Figures
 | List of Tables
 | List of Listings

Team LiB
Next Section


backcover

Team LiB

Back Cover

Red Hat sealed and approved! Compiled by Red Hat’s own documentation team and reviewed by a Red Hat qualified technical expert, this comprehensive, authoritative guide delivers all the know-how you need to manage Linux networks and systems, troubleshoot problems, and provide optimum client service.

You’ll find in-depth coverage of creating network scripts, configuring Apache and Samba, Kickstart installations, and managing major protocols such as SSH, LDAP, DHCP, and BIND. Learn what you need to know about Red Hat Linux 8 exclusives like GRUB and ext3 and get extensive information on topics most Linux guides doesn’t even address, like Tripwire, PAM, Samba, and RAID.

This guidebook is your single official source for documentation, instruction, and answers about Red Hat Linux 8.

Proven Red Hat Linux Administration Solutions

  • Understand the pros and cons of Kerberos 5 and configure both server and client
  • Upgrade the kernel and learn about working with kernel modules
  • Add SMB, NCP, and JetDirect printers, modify existing printers, and configure the CUPS system
  • Manage console access and use xinetd to control access to services
  • Configure, enhance, and maintain an Apache secure server
  • Select, configure, and update appropriate security installations
  • Troubleshoot NFS, /proc, ext3, and the Red Hat Linux File System
  • Add packages and maintain Red Hat Linux with regular updates

Team LiB


Official Red Hat Linux Administrator's Guide

Team LiB

Official Red Hat Linux Administrator’s Guide

Contributors:

Sandra A. Moore • Tammy Fox • Johnray Fuller • John Ha
Edward C. Bailey • Joe Merlino • Kate Wrightson

Wiley Publishing, Inc.

Official Red Hat® Linux® Administrator’s Guide

Published by
Wiley Publishing, Inc.
10475 Crosspoint Boulevard
Indianapolis, IN 46256
www.wiley.com

Copyright © 2003 by Red Hat, Inc.

Published by Wiley Publishing, Inc., Indianapolis, Indiana

Published simultaneously in Canada

2002110252

ISBN: 0-7645-1695-7

Manufactured in the United States of America

10 9 8 7 6 5 4 3 2 1

1B/RU/RQ/QS/IN

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4744. Requests to the Publisher for permission should be addressed to the Legal Department, Wiley Publishing, Inc., 10475 Crosspoint Blvd., Indianapolis, IN 46256, (317) 572-3447, fax (317) 572-4447, E-Mail: permcoordinator@wiley.com.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

For general information on our other products and services or to obtain technical support, please contact our Customer Care Department within the U.S. at (800) 762-2974, outside the U.S. at (317) 572-3993 or fax (317) 572-4002.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books.

Trademarks: Wiley, the Wiley Publishing logo and related trade dress are trademarks or registered trademarks of Wiley Publishing, Inc., in the United States and other countries, and may not be used without written permission. Red Hat is a trademark or registered trademark of Red Hat, Inc. Linux is a trademark or registered trademark of Linus Torvalds. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any product or vendor mentioned in this book.

Credits

Acquisitions Editor
Debra Williams Cauley

Project Editor
Eric Newman

Writers
Joe Merlino
Kate Wrightson

Editorial Manager
Mary Beth Wakefield

Vice President & Executive
Group Publisher
Richard Swadley

Vice President and Publisher
Joseph B. Wikert

Executive Editorial Director
Mary Bednarek

Project Coordinator
Dale White

Proofreader
Luann Rouff

Indexer
Johnna VanHoose Dinse

Cover Design
Michael J. Freeland

Red Hat Press Documentation Team

Sandra A. Moore, Product Documentation Manager and Technical Writer

Tammy Fox, Product Documentation Technical Lead and Technical Writer

Johnray Fuller, Technical Writer

John Ha, Technical Writer

Edward C. Bailey, Technical Writer

Red Hat Press Liaisons

Lorien Golaski

Chris Grams

Special Red Hat Assistance

Kathleen Langhi

Jeremy Hogan

Jonathan Opp


Foreword

Though Red Hat has been developing, contributing, and maintaining documentation since the early days, there has never been an Official Red Hat Linux Administrator’s Guide until now. Perhaps that is because just a few years ago, running Linux was a very personal decision, and the documentation one needed (beyond the source, of course) was an installation guide and perhaps a user’s guide. Today, Linux can do more than ever before, and it is being used in more ways by more people than ever before. For those who need or want to do more than just run an “out-of-the-box” configuration (or for those who want to make new “out-of-the-box” configurations that they can distribute to their users or customers), this is the guide that brings together, in one place, the knowledge Red Hat has gained in (1) talking directly with developers of key packages, (2) working with partners and customers who have deployed (or tried to deploy) particular solutions, and (3) our own experience of building an enterprise infrastructure using Red Hat Linux and other open-source technologies.

Which tool is better, a screwdriver or a hammer? A ball-peen hammer or a sledgehammer? What metal is best — steel, aluminum, or titanium? Which wood is best — balsa wood, oak, or angelique? Should you buy a mahogany log, get a pre-cut board, or grow your own? Of course, the answer to all these questions is “it depends on the job to be done, the resources, and time available.” With over 1,400 packages, Red Hat Linux 8.0 is both a tool chest and a warehouse, providing the tools and materials necessary to turn ordinary PCs into firewalls, file and print servers, Web servers, file servers, desktops, point-of-sale terminals, and more. This Administrator’s Guide provides an outline and an index to help administrators configure, customize, deploy, and manage Red Hat Linux with customer-proven approaches to real-world problems.

This book owes much to the open-source approach that Red Hat has embraced and has come to represent. First, without the open-source community, there would be no Red Hat Linux to document. Second, without their amazing and prolific technology innovations, there would not be anything really complex or interesting to document. Third, without the variety of solutions that the open-source community has developed in response to the variety of real-world problems to be solved, there would not be a need to talk about the finer points of why one should use one approach over another. Fourth, without the large number of users making Red Hat Linux do things we could never have imagined, there wouldn’t be a need to document corner cases, provide advice about what not to do, and come up with better ways of describing what users should do, and why. Finally, without Red Hat’s commitment to use its own software in the ways that we recommend it to customers, we would not have found the hundreds of minor errors or omissions in our own documentation that users were too polite (or too lazy) to report to us.

In a sense, therefore, this book is to Linux documentation what Red Hat Linux is to all open-source software: a collection, packaged and organized for easy use, necessarily limited but not necessarily limiting, and then rigorously tested until we are satisfied with the consistency of the product. With Red Hat Linux, you have the best Linux distribution we know how to make. With this Administrator’s Guide, you will know how to make Red Hat Linux the best distribution for you.

Michael Tiemann
CTO, Red Hat


Introduction

Welcome to the Official Red Hat Linux Administrator’s Guide! From installation to navigation and instructions on performing common tasks, this book is designed to help intermediate and advanced Linux administrators get up and running with Red Hat Linux 8.0.

If you need more basic coverage of Red Hat Linux, see the companion book to this one: the Official Red Hat Linux User’s Guide (Red Hat Press/Wiley, 2003).

Conventions Used in This Book

As you read this book, you will see that certain words are represented in different fonts and styles. These conventions are designed to help you easily navigate the book so that you can find whatever you need fast. The following sections discuss the major typographical conventions used in this book.

Commands and File Names

Linux commands (and other operating system commands, when used) are typed in bold, as in boot: linux console=device. This style indicates that you can type the word or phrase on the command line and press Enter to invoke a command.

File names, directory names, and paths are shown in a monospaced font to visually set them apart from normal text: for example, /test/new/RedHat.

Computer Output

Computer output is displayed by the computer as text on the command line. You will see this output — which includes responses to commands you typed in, error messages, and interactive prompts for your input during scripts or programs — displayed in a monospaced font against a gray background, as follows:

$ ls
Desktop axhome logs paulwesterberg.png
Mail backupfiles mail reports

User Input

As explained above, text that the user has to type (either on the command line, or into a text box on a GUI screen) is displayed in bold font: for example, “To boot your system into the text-based installation program, type text at the boot prompt.”


Navigational Callouts

Throughout this book, we use several methods of calling out important or otherwise noteworthy information. In order of how critical the information is to your system, these items are marked as Note, Tip, Warning, and Cross-Reference. Following are examples of each of these items.

Note

Remember that Linux is case-sensitive. In other words, a rose is not a ROSE is not a rOsE.
Tip

The directory /usr/share/doc contains additional documentation for packages installed on your system.
Warning

If you choose not to partition manually, a server installation will remove all existing partitions on all installed hard drives. Do not choose this installation class unless you are sure you have no data you need to save.
CROSS-REFERENCE

See Chapter 3 for information on how to edit the /boot/grub/grub.conf file.


How This Book Is Organized

The chapters and appendixes in this book are grouped by topic into five parts. The following sections give you a brief description of each of the book’s parts.

Part I: Essential Information

This part of the book contains basic information about working with Red Hat Linux 8.0. The topics include installation, the boot process, shutdown, boot loaders (both LILO and GRUB), the file system, and gathering essential system information. Whether you are new to Linux or upgrading from a previous version of Red Hat Linux, the information in this section will explain basic concepts and introduce new features exclusive to Red Hat Linux 8.0.

Part II: Basic System Administration

Part II contains information needed by new system administrators or those who have not worked on a Red Hat Linux system before, as well as information about new administrative features in Red Hat Linux 8.0. In this section, you will find chapters on system configuration, user and group management, printers, automated task scheduling, RAID arrays, the X Window System, and kernel management.

Part III: Network Administration

Part III introduces the many elements of network management. In this part, you will find chapters on network configuration and scripting, DHCP, BIND, and LDAP, as well as critical user services like email, the Apache Web server, and NFS/Samba file sharing. Red Hat Linux 8.0 ships with all these services, and these chapters show how to configure each service to suit your network and organizational needs.

Part IV: Security

Every system administrator is concerned about security, no matter how small the system. As cracker sophistication increases, new tools are devised to keep systems safe and secure. This section of the book contains chapters introducing the most powerful security tools, including firewalls, Kerberos 5, SSH, PAM, and Tripwire.

Part V: Appendixes

This part of the book contains useful reference information that will help you administer your Red Hat system. Here, you will find information on installing Red Hat Linux 8.0, how to work with rescue mode, and how to define general parameters and modules useful when working with Red Hat Linux.


Where to Go from Here

Many good resources are available on the Internet. Because technical data changes so rapidly, the Internet is often the most effective way to get new ideas and information out to the community. The following sections provide you with good online resources for Linux-related information.

Linux Websites

Following are a few recommended websites about Red Hat Linux. (Note that some sites will discuss other Linux distributions as well.)

  • http://www.redhat.com — On the Red Hat website you can find links to the Linux Documentation Project (LDP), online versions of the Red Hat Linux manuals, FAQs (Frequently Asked Questions), a database that can help you find a Linux Users Group near you, technical information in the Red Hat Support Knowledge Base, and more.

  • http://www.linuxheadquarters.com — The Linux Headquarters website features easy-to-follow, step-by-step guides for a variety of Linux tasks.

  • http://www.slashdot.org — Slashdot is a technical news site that often discusses Linux-related stories. The site supports an active user community, many of whose members are Linux administrators and users.

Linux Newsgroups

You can participate in newsgroups by following the discussions of others attempting to solve problems, or by actively asking or answering questions. Experienced Linux users are known to be extremely helpful when trying to assist new users with various Linux issues — especially if you are posing your questions in the right venue. If you do not have access to a newsreader application (note that you can use Mozilla Mail for newsgroups), you can access this information via the web at http://www.deja.com. Dozens of Linux-related newsgroups exist, including the following:

  • linux.help — A great place to get help from fellow Linux users.

  • linux.redhat — Primarily covers Red Hat Linux-specific issues.

  • linux.redhat.install — Pose installation questions to this newsgroup or search it to see how others have solved similar problems.

  • linux.redhat.misc — Questions or requests for help that do not really fit into traditional categories go here.

  • linux.redhat.rpm — A good place to go if you are having trouble using RPM to accomplish particular objectives.


Part I: Essential Information

Chapter List

Chapter 1: Kickstart Installations
Chapter 2: Boot Process, init, and Shutdown
Chapter 3: GRUB
Chapter 4: Red Hat Linux File System
Chapter 5: Gathering System Information


Chapter 1: Kickstart Installations

What Are Kickstart Installations?

The basic Red Hat Linux installation process is covered in Appendix A of this book, and in the Official Red Hat Linux User’s Guide (Red Hat Press/Wiley, 2003).

While the Red Hat Linux installation process is generally straightforward, it does require a fairly high degree of attention from the user. This level of interactivity sometimes makes the process unsuitable, for example, in situations where a large number of machines must be installed in a short amount of time, or in any situation where the administrator’s time is at a premium.

To answer this need, Red Hat created the kickstart installation method. In a nutshell, kickstart lets the administrator automate the installation process. Using kickstart, the administrator can create a single file containing the answers to all the questions that are normally asked during a typical Red Hat Linux installation. With this method, a single kickstart file can be used to install multiple machines, requiring only as much time from the administrator as it takes to initiate the process.


How Do You Perform a Kickstart Installation?

Kickstart installations can be performed using a local CD-ROM, a local hard drive, or via NFS, FTP, or HTTP. To use kickstart, you must:

  1. Create a kickstart file.

  2. Create a boot diskette with the kickstart file or make the kickstart file available on the network.

  3. Make the installation tree available.

  4. Start the kickstart installation.

This chapter explains these steps in detail.

Creating the Kickstart File

The kickstart file is a simple text file containing a list of items, each identified by a keyword. You can create it by editing a copy of the sample.ks file found in the RH-DOCS directory of the Red Hat Linux Documentation CD, using Kickstart Configurator, or writing it from scratch. The Red Hat Linux installation program also creates a sample kickstart file based on the options that you selected during installation. It is written to the file /root/anaconda-ks.cfg. You should be able to edit it with any text editor or word processor that can save files as ASCII text. First, be aware of the following issues when you are creating your kickstart file:

  • Sections must be specified in order. Items within the sections do not have to be in a specific order unless otherwise specified. The section order is:

    • The Command section: Refer to the “Kickstart Options” section of this chapter for a list of kickstart options. You must include the required options.

    • The %packages section: Refer to the “Package Selection” section of this chapter for details.

    • The %pre and %post sections: These two sections can be in any order and are not required. Refer to the “Pre-Installation Script” and “Post-Installation Script” sections of this chapter for details.

  • Items that are not required can be omitted.

  • Omitting any required item will result in the installation program’s prompting the user for an answer to the related item, just as the user would be prompted during a typical installation. Once the answer is given, the installation will continue unattended (unless it finds another missing item).

  • Lines starting with a pound sign (#) are treated as comments and ignored.

For kickstart upgrades, the following items are required:

  • Language

  • Language support

  • Installation method

  • Device specification (if device is needed to perform installation)

  • Keyboard setup

  • The upgrade keyword

  • Boot loader configuration

If any other items are specified for an upgrade, those items will be ignored (note that this includes package selection).

Kickstart Options

The following options can be placed in a kickstart file. If you prefer to use a graphical interface for creating your kickstart file, you can use Kickstart Configurator. Refer to the “Kickstart Configurator” section of this chapter for details.

Note

If the option is followed by an equals mark (=), a value must be specified after it. In the example commands, options in brackets ([ ]) are optional arguments for the command.

autostep (optional)

Similar to interactive except it goes to the next screen for you. It is used mostly for debugging.

auth or authconfig (required)

Sets up the authentication options for the system. It’s similar to the authconfig command, which can be run after the install. By default, passwords are normally encrypted and are not shadowed.

--enablemd5

Use md5 encryption for user passwords.

--enablenis

Turns on NIS support. By default, --enablenis uses whatever domain it finds on the network. A domain should almost always be set by hand with the --nisdomain= option.

--nisdomain=

NIS domain name to use for NIS services.

--nisserver=

Server to use for NIS services (broadcasts by default).

--useshadow or --enableshadow

Use shadow passwords.

--enableldap

Turns on LDAP support in /etc/nsswitch.conf, allowing your system to retrieve information about users (UIDs, home directories, shells, etc.) from an LDAP directory. To use this option, you must install the nss_ldap package. You must also specify a server and a base DN with --ldapserver= and --ldapbasedn=.

--enableldapauth

Use LDAP as an authentication method. This enables the pam_ldap module for authentication and changing passwords, using an LDAP directory. To use this option, you must have the nss_ldap package installed. You must also specify a server and a base DN with --ldapserver= and --ldapbasedn=.

--ldapserver=

If you specified either --enableldap or --enableldapauth, this variable will contain the name of the LDAP server to use. This option is set in the /etc/ldap.conf file.

--ldapbasedn=

If you specified either --enableldap or --enableldapauth, this variable will contain the DN (distinguished name) in your LDAP directory tree under which user information is stored. This option is set in the /etc/ldap.conf file.

--enableldaptls

Use TLS (Transport Layer Security) lookups. This option allows LDAP to send encrypted usernames and passwords to an LDAP server before authentication.

--enablekrb5

Use Kerberos 5 for authenticating users. Kerberos itself does not know about home directories, UIDs, or shells. So if you enable Kerberos you will need to make users’ accounts known to this workstation by enabling LDAP, NIS, or Hesiod or by using the /usr/sbin/useradd command to make their accounts known to this workstation. If you use this option, you must have the pam_krb5 package installed.

--krb5realm=

The Kerberos 5 realm to which your workstation belongs.

--krb5kdc=

The KDC (or KDCs) that serves requests for the realm. If you have multiple KDCs in your realm, separate their names with commas (,).

--krb5adminserver=

The KDC in your realm that is also running kadmind. This server handles password changing and other administrative requests. This server must be run on the master KDC if you have more than one KDC.

--enablehesiod

Enable Hesiod support for looking up user home directories, UIDs, and shells. More information on setting up and using Hesiod on your network is in /usr/share/doc/glibc-2.x.x/README.hesiod, which is included in the glibc package. Hesiod is an extension of DNS that uses DNS records to store information about users, groups, and various other items.

--hesiodlhs

The Hesiod LHS (“left-hand side”) option, set in /etc/hesiod.conf. This option is used by the Hesiod library to determine the name to search DNS for when looking up information, similar to LDAP’s use of a base DN.

--hesiodrhs

The Hesiod RHS (“right-hand side”) option, set in /etc/hesiod.conf. This option is used by the Hesiod library to determine the name to search DNS for when looking up information, similar to LDAP’s use of a base DN.

Tip

To look up user information for “jim,” the Hesiod library looks up jim.passwd <LHS> <RHS>, which should resolve to a TXT record that looks like what his passwd entry would look like (jim:*:501:501:Jungle Jim:/home/jim:/bin/bash). For groups, the situation is identical, except jim.group <LHS> <RHS> would be used. Looking up users and groups by number is handled by making 501.uid a CNAME for jim.passwd, and 501.gid a CNAME for jim.group. that the <LHS> and <RHS> do not have periods [.] in front of them when the library determines the name for which to search, so the <LHS> and <RHS> usually begin with periods.
--enablesmbauth

Enables authentication of users against an SMB server (typically a Samba or Windows server). SMB authentication support does not know about home directories, UIDs, or shells. So if you enable it you will need to make users’ accounts known to the workstation by enabling LDAP, NIS, or Hesiod or by using the /usr/sbin/useradd command to make their accounts known to the workstation. To use this option, you must have the pam_smb package installed.

--smbservers=

The name of the server(s) to use for SMB authentication. To specify more than one server, separate the names with commas (,).

--smbworkgroup=

The name of the workgroup for the SMB servers.

--enablecache

Enables the nscd service. The nscd service caches information about users, groups, and various other types of information. Caching is especially helpful if you choose to distribute information about users and groups over your network using NIS, LDAP, or Hesiod.

bootloader (required)

Specifies how the boot loader should be installed and whether the boot loader should be LILO or GRUB. This option is required for both installations and upgrades. For upgrades, if --useLilo is not specified and LILO is the current bootloader, the bootloader will be changed to GRUB. To preserve LILO on upgrades, use the --upgrade option.

--append=

Specifies kernel parameters.

--location=

Specifies where the boot record is written. Valid values are the following: mbr (the default), partition (installs the boot loader on the first sector of the partition containing the kernel), or none (does not install the boot loader).

--password=

If you are using GRUB, this option sets the GRUB boot loader password to the one specified here. This should be used to restrict access to the GRUB shell, where arbitrary kernel options can be passed.

--md5pass=

If using GRUB, similar to --password=, except the password should already be encrypted.

--useLilo

Use LILO instead of GRUB as the boot loader.

--linear

If using LILO, use the linear LILO option; this is only for backwards compatibility (and linear is now used by default).

--nolinear

If using LILO, use the nolinear LILO option; linear is the default.

--lba32

If using LILO, force use of lba32 mode instead of autodetecting.

--upgrade

Upgrade the existing boot loader configuration, preserving the old entries. This option is available only for upgrades.

clearpart (optional)

Removes partitions from the system, prior to creation of new partitions. By default, no partitions are removed.

Note

If the clearpart command is used, then the --onpart command cannot be used on a logical partition.
--linux

Erases all Linux partitions.

--all

Erases all partitions from the system.

--drives

Specifies which drives to clear partitions from.

--initlabel

Initializes the disk label to the default for your architecture (msdos for x86 and gpt for Itanium). It is useful so that the installation program does not ask if it should initialize the disk label if installing to a brand new hard drive.

device (optional)

On most PCI systems, the installation program will autoprobe for Ethernet and SCSI cards properly. On older systems and some PCI systems, however, kickstart needs a hint to find the proper devices. The device command, which tells the installation program to install extra modules, is in this format:

device   <type>    <moduleName>   --opts=<options>
<type>

Replace with either scsi or eth.

<moduleName>

Replace with the name of the kernel module that should be installed.

--opts=

Options to pass to the kernel module. Note that multiple options may be passed if they are put in quotes. For example:

--opts="aic152x=0x340 io=11"

deviceprobe (optional)

Forces a probe of the PCI bus and loads modules for all the devices found if a module is available.

driverdisk (optional)

Driver disks can be used during kickstart installations. You will need to copy the driver disk’s contents to the root directory of a partition on the system’s hard drive. Then you will need to use the driverdisk command to tell the installation program where to look for the driver disk.

driverdisk  <partition> [--type= <fstype> ]
<partition>

Partition containing the driver disk.

--type=

File system type (for example, vfat, ext2, or ext3).

firewall (optional)

This option corresponds to the Firewall Configuration screen in the installation program:

firewall  <securitylevel>  [--trust=]  <incoming>  [--port=]
<securitylevel>

Replace with one of the following levels of security:

  • high

  • medium

  • disabled

--trust=

Listing a device here, such as eth0, allows all traffic coming from that device to go through the firewall. To list more than one device, use --trust eth0 --trust eth1. Do not use a comma-separated format such as --trust eth0, eth1.

<incoming>

If desired, replace with one or more of the following to allow the specified services through the firewall.

  • dhcp

  • ssh

  • telnet

  • smtp

  • http

  • ftp

--port=

You can specify that ports be allowed through the firewall using the port:protocol format. For example, if you want to allow IMAP access through your firewall, you can specify imap:tcp. You can also specify numeric ports explicitly; for example, to allow UDP packets on port 1234 through, specify 1234:udp. To specify multiple ports, separate them by commas.

install (optional)

Tells the system to install a fresh system rather than upgrade an existing system. This is the default mode. For installation, you must specify the type of installation from one of cdrom, harddrive, nfs, or url (for ftp or http installations).

cdrom

Install from the first CD-ROM drive on the system.

harddrive

Install from a Red Hat installation tree on a local drive, which must be either vfat or ext2.

--partition=

Partition to install from (such as sdb2).

--dir=

Directory containing the Red Hat directory of the installation tree. For example:

harddrive --partition=hdb2 --dir=/tmp/install-tree
nfs

Install from the NFS server specified.

--server=

Server from which to install (hostname or IP).

--dir=

Directory containing the Red Hat directory of the installation tree. For example:

nfs --server=nfsserver.example.com --dir=/tmp/install-tree
url

Install from an installation tree on a remote server via FTP or HTTP. For example:

url --url http:// <server> / <dir>

or

url --url ftp:// <username> : <password> @ <server> / <dir>

interactive (optional)

Uses the information provided in the kickstart file during the installation but allows for inspection and modification of the values given. You will be presented with each screen of the installation program with the values from the kickstart file. Either accept the values by clicking Next or change the values and click Next to continue. See also autostep.

keyboard (required)

Sets system keyboard type. Here is the list of available keyboards on i386, Itanium, and Alpha machines:

  • be-latin1

  • be-latin2

  • bg

  • br-abnt2

  • cf

  • cz-lat2

  • cz-us-qwertz

  • de

  • de-latin1

  • de-latin1-nodeadkeys

  • dk

  • dk-latin1

  • dvorak

  • es

  • et

  • fi

  • fr

  • fr_CH

  • fr_CH-latin1

  • fr-latin0

  • fr-latin1

  • fr-pc

  • gr

  • hu

  • hu101

  • i-latin1

  • is-latin1

  • it

  • it2

  • it-ibm

  • jp106

  • no

  • no-latin1

  • pl

  • pt-latin1

  • ro

  • ru

  • ru_win

  • ru1

  • ru2

  • ru-cp1251

  • ru-ms

  • se-latin1

  • sg

  • sg-latin1

  • sk-qwerty

  • slovene

  • speakup

  • speakup-lt

  • trq

  • ua

  • uk

  • us

lang (required)

Sets the language to use during installation. For example, to set the language to English, the kickstart file should contain the following line:

lang en_US

Valid language codes are the following (please note that these are subject to change at any time):

  • cs_CZ

  • da_DK

  • en_US

  • fr_FR

  • de_DE

  • is_IS

  • it_IT

  • ja_JP.eucJP

  • ko_KR.eucKR

  • no_NO

  • pt_PT

  • ru_RU.koi8r

  • sl_SI

  • es_ES

  • sv_SE

  • uk_UA

  • zh_CN.GB18030

  • zh_TW.Big5

langsupport (required)

Sets the language(s) to install on the system. The same language codes used with lang can be used with langsupport. If you want to install just one language, specify it. For example, to install and use the French language, fr_FR:

langsupport fr_FR
--default=

If you want to install language support for more than one language, you must specify a default. For example, to install English and French and use English as the default language:

langsupport --default=en_US fr_FR

If you use --default with only one language, all languages will be installed with the specified language set to the default.

lilo (replaced by bootloader)

Specifies how the boot loader should be installed on the system. By default, LILO installs on the MBR of the first disk, and installs a dual-boot system if a DOS partition is found (the DOS/Windows system will boot if the user types dos at the LILO: prompt).

Caution

This option has been replaced by bootloader and is available only for backwards compatibility. Refer to bootloader.
--append <params>

Specifies kernel parameters.

--linear

Use the linear LILO option; this is only for backwards compatibility (and linear is now used by default).

--nolinear

Use the nolinear LILO option; linear is now used by default.

--location=

Specifies where the LILO boot record is written. Valid values are the following: mbr (the default) or partition (installs the boot loader on the first sector of the partition containing the kernel). If no location is specified, LILO is not installed.

--lba32

Forces the use of lba32 mode instead of autodetecting.

lilocheck (optional)

If lilocheck is present, the installation program checks for LILO on the MBR of the first hard drive, and reboots the system if it is found — in this case, no installation is performed. This can prevent kickstart from reinstalling an already installed system.

logvol (optional)

Create a logical volume for Logical Volume Management (LVM) with the syntax:

logvol mountpoint --vgname=name --size=size --name=name

Create the partition first, create the logical volume group, and then create the logical volume. For example:

part pv.01 --size 3000
volgroup myvg pv.01
logvol / --vgname=myvg --size=2000 --name=rootvol
NEW FEATURE

This option is new to Red Hat Linux 8.0.

mouse (required)

Configures the mouse for the system, both in GUI and text modes. Options are:

--device=

Device the mouse is on (such as --device=ttyS0).

--emulthree

If present, simultaneous clicks on the left and right mouse buttons will be recognized as the middle mouse button by the X Window System. This option should be used if you have a two-button mouse.

After options, the mouse type may be specified as one of the following:

  • alpsps/2

  • ascii

  • asciips/2

  • atibm

  • generic

  • generic3

  • generic3ps/2

  • generic3usb

  • genericps/2

  • genericusb

  • geniusnm

  • geniusnmps/2

  • geniusprops/2

  • geniusscrollps/2

  • geniusscrollps/2+

  • logibm

  • logimman

  • logimman+

  • logimman+ps/2

  • logimmanps/2

  • logimmusb

  • logitech

  • logitechcc

  • microsoft

  • mmhittab

  • mmseries

  • mousesystems

  • msbm

  • msintelli

  • msintellips/2

  • msintelliusb

  • msnew

  • none

  • sun

  • thinking

  • thinkingps/2

If the mouse command is given without any arguments, or it is omitted, the installation program will attempt to autodetect the mouse. This procedure works for most modern mice.

network (optional)

Configures network information for the system. If the kickstart installation does not require networking (in other words, it is not installed over NFS, HTTP, or FTP), networking is not configured for the system. If the installation does require networking and network information is not provided in the kickstart file, the Red Hat Linux installation program assumes that the installation should be done over eth0 via a dynamic IP address (BOOTP/DHCP), and configures the final, installed system to determine its IP address dynamically. The network option configures networking information for kickstart installations via a network as well as for the installed system.

--bootproto=

One of dhcp, bootp, or static. It defaults to dhcp. bootp and dhcp are treated the same. The dhcp method uses a DHCP server system to obtain its networking configuration. As you might guess, the bootp method is similar, requiring a BOOTP server to supply the networking configuration. To direct a system to use DHCP:

network --bootproto=dhcp

To direct a machine to use BOOTP to obtain its networking configuration, use the following line in the kickstart file:

network --bootproto=bootp

The static method requires that you enter all the required networking information in the kickstart file. As the name implies, this information is static and will be used during and after the installation. The entry for static networking is more complex, as you must include all network configuration information on one line. You must specify the IP address, netmask, gateway, and nameserver. For example (the \ indicates that it is all one line):

network --bootproto=static --ip=10.0.2.15 --netmask=255.255.255.0 \
--gateway=10.0.2.254 --nameserver=10.0.2.1

If you use the static method, be aware of the following two restrictions:

  • All static networking configuration information must be specified on one line; you cannot wrap lines using a backslash, for example.

  • You can specify only one nameserver here. However, you can use the kickstart file’s %post section to add more nameservers, if needed.

--device=

Used to select a specific Ethernet device for installation. Note that using --device= will not be effective unless the kickstart file is a local file (such as ks=floppy), since the installation program will configure the network to find the kickstart file. For example:

network --bootproto=dhcp --device=eth0
--ip=

IP address for the machine to be installed.

--gateway=

Default gateway as an IP address.

--nameserver=

Primary nameserver, as an IP address.

--nodns

Do not configure any DNS server.

--netmask=

Netmask for the installed system.

--hostname=

Hostname for the installed system.

part or partition (required for installs, ignored for upgrades)

Creates a partition on the system. If more than one Red Hat Linux installation exists on the system on different partitions, the installation program prompts the user and asks which installation to upgrade.

Caution

All partitions created will be formatted as part of the installation process unless --noformat and --onpart are used.

<mntpoint>

mntpoint is where the partition will be mounted and must be of one of the following forms:

/path

For example, /, /usr, /home.

swap

The partition will be used as swap space. To determine the size of the swap partition automatically, use the --recommended option:

swap --recommended

The minimum size of the automatically generated swap partition will be no smaller than the amount of RAM in the system and no bigger than twice the amount of RAM in the system.

raid <id>

The partition will be used for software RAID (refer to raid).

pv <id>

The partition will be used for LVM (refer to logvol).

--size=

The minimum partition size in megabytes. Specify an integer value here, such as 500. Do not append MB to the number.

--grow

Tells the partition to grow to fill available space (if any), or up to the maximum size setting.

--maxsize=

The maximum partition size in megabytes when the partition is set to grow. Specify an integer value here, and do not append MB to it.

--noformat

Tells the installation program not to format the partition, for use with the --onpart command.

--onpart= or --usepart=

Put the partition on the already existing device. For example,

partition /home --onpart hda1

will put /home on /dev/hda1, which must already exist.

--ondisk= or --ondrive=

Forces the partition to be created on a particular disk. For example,

--ondisk=sdb

will put the partition on the second SCSI disk on the system.

--asprimary

Forces automatic allocation of the partition as a primary partition or the partitioning will fail.

--bytes-per-inode=

Number specified represents the number of bytes per inode on the file system when it is created. It must be given in decimal format. This option is useful for applications where you want to increase the number of inodes on the file system.

--type= (replaced by fstype)

This option is no longer available. Use fstype.

--fstype=

Sets the file system type for the partition. Valid values are ext2, ext3, swap, and vfat.

--start=

Specifies the starting cylinder for the partition. It requires that a drive be specified with --ondisk= or ondrive=. It also requires that the ending cylinder be specified with --end= or the partition size be specified with --size=.

--end=

Specifies the ending cylinder for the partition. It requires that the starting cylinder be specified with --start=.

--badblocks

Specifies that the partition should be checked for bad sectors.

Note

If partitioning fails for any reason, diagnostic messages will appear on virtual console 3.

raid (optional)

Assembles a software RAID device. This command is of the form:

raid  <mntpoint> --level= <level> --device= <mddevice>   <partitions*>
<mntpoint>

Location where the RAID file system is mounted. If it is /, the RAID level must be 1 unless a boot partition (/boot) is present. If a boot partition is present, the /boot partition must be level 1 and the root (/) partition can be any of the available types.

partitions*

Lists the RAID identifiers to add to the RAID array. (The * denotes that multiple partitions can be listed.)

--level=

RAID level to use (0, 1, or 5).

--device=

Name of the RAID device to use (such as md0 or md1). RAID devices range from md0 to md7, and each may be used only once.

--spares=

Specifies the number of spare drives allocated for the RAID array. Spare drives are used to rebuild the array in case of drive failure.

--fstype=

Sets the file system type for the RAID array. Valid values are ext2, ext3, swap, and vfat.

--noformat

Do not format the RAID array.

Sample Configuration

The following example shows how to create a RAID level 1 partition for /, and a RAID level 5 partition for /usr, assuming there are three SCSI disks on the system. It also creates three swap partitions, one on each drive.

part raid.01 --size=60 --ondisk=sda
part raid.02 --size=60 --ondisk=sdb
part raid.03 --size=60 --ondisk=sdc
part swap --size=128 --ondisk=sda
part swap --size=128 --ondisk=sdb
part swap --size=128 --ondisk=sdc
part raid.11 --size=1 --grow --ondisk=sda
part raid.12 --size=1 --grow --ondisk=sdb
part raid.13 --size=1 --grow --ondisk=sdc
raid / --level=1 --device=md0 raid.01 raid.02 raid.03
raid /usr --level=5 --device=md1 raid.11 raid.12 raid.13

reboot (optional)

Reboot after the installation is complete (no arguments). Normally, kickstart displays a message and waits for the user to press a key before rebooting.

rootpw (required)

Sets the system’s root password to the password argument.

rootpw [--iscrypted] <password>
--iscrypted

If this is present, the password argument is assumed to already be encrypted.

skipx (optional)

If present, X is not configured on the installed system.

text (optional)

Perform the kickstart installation in text mode. Kickstart installations are performed in graphical mode by default.

timezone (required)

Sets the system time zone to timezone, which may be any of the time zones listed by timeconfig.

timezone [--utc]  <timezone>
--utc

If present, the system assumes the hardware clock is set to UTC (Greenwich Mean) time.

upgrade (optional)

Tells the system to upgrade an existing system rather than install a fresh system. You must specify one of cdrom, harddrive, nfs, or url (for ftp and http) as the location of the installation tree. Refer to install for details.

xconfig (optional)

Configures the X Window System. If this option is not given, the user will need to configure X manually during the installation, if X was installed; this option should not be used if X is not installed on the final system.

--noprobe

Do not probe the monitor.

--card=

Use specified card; this card name should be from the list of cards in /usr/share/hwdata/Cards from the hwdata package. If this argument is not provided, the installation program will probe the PCI bus for the card. Since AGP is part of the PCI bus, AGP cards will be detected if supported. The probe order is determined by the PCI scan order of the motherboard.

--videoram=

Specify the amount of video RAM the video card has.

--monitor=

Use specified monitor; monitor name should be from the list of monitors in /usr/share/hwdata/MonitorsDB from the hwdata package. This is ignored if --hsync or --vsync is provided. If no monitor information is provided, the installation program tries to probe for it automatically.

--hsync=

Specifies the horizontal sync frequency of the monitor.

--vsync=

Specifies the vertical sync frequency of the monitor.

--defaultdesktop=

Specify either GNOME or KDE to set the default desktop (assumes that GNOME Desktop Environment and/or KDE Desktop Environment has been installed through %packages).

--startxonboot

Use a graphical login on the installed system.

--resolution=

Specify the default resolution for the X Window System on the installed system. Valid values are 640 × 480, 800 × 600, 1024 × 768, 1152 × 864, 1280 × 1024, 1400 × 1050, 1600 × 1200. Be sure to specify a resolution that is compatible with the video card and monitor.

--depth=

Specify the default color depth for the X Window System on the installed system. Valid values are 8, 16, 24, and 32. Be sure to specify a color depth that is compatible with the video card and monitor.

volgroup (optional)

Use to create a Logical Volume Management (LVM) group with the syntax:

volgroup name partition

Create the partition first, create the logical volume group, and then create the logical volume. For example:

part pv.01 --size 3000
volgroup myvg pv.01
logvol / --vgname=myvg --size=2000 --name=rootvol

zerombr (optional)

If zerombr is specified, and yes is its sole argument, any invalid partition tables found on disks are initialized. This will destroy all of the contents of disks with invalid partition tables. This command should be in the following format:

zerombr yes

No other format is effective.

%include

Use the %include /path/to/file command to include the contents of another file in the kickstart file as though the contents were at the location of the %include command in the kickstart file.

Package Selection

Use the %packages command to begin a kickstart file section that lists the packages you would like to install (this is for installations only, as package selection during upgrades is not supported).

--resolvedeps

Install the listed packages and automatically resolve package dependencies.

--ignoredeps

Ignore the unresolved dependencies and install the listed packages without the dependencies.

Packages can be specified by group or by individual package name. The installation program defines several groups that contain related packages. See the RedHat/base/comps.xml file on any Red Hat Linux CD-ROM for a list of groups. Each group has an id, user visibility value, name, description, and package list. In the package list, the packages marked as mandatory are always installed if the group is selected, the packages marked default are selected by default if the group is selected, and the packages marked optional must be specifically selected even if the group is selected to be installed.

NEW FEATURE

This option is new to Red Hat Linux 8.0.

In most cases, it is necessary to list only the desired groups and not individual packages. Note that the Core and Base groups are always selected by default, so it is not necessary to specify those groups in the %packages section.

Here is an example %packages selection:

%packages
@ X Window System
@ GNOME Desktop Environment
@ Graphical Internet
@ Sound and Video
galeon

As you can see, groups are specified, one to a line, starting with an @ symbol, a space, and then the full group name as given in the comps file. Specify individual packages with no additional characters (the galeon line in the example above is an individual package).

To specify an “everything” installation (to install all packages), add this line to the %packages section:

@ Everything

You can also specify which packages not to install from the default package list:

@ Games and Entertainment
-kdegames

Pre-installation Script

You can add commands to run on the system immediately after the ks.cfg file has been parsed. This section must be at the end of the kickstart file (after the commands) and must start with the %pre command. You can access the network in the %pre section; however, name service has not been configured at this point, so only IP addresses will work.

Note

The pre-install script is not run in the change root environment.
--interpreter /usr/bin/python

Allows you to specify a different scripting language, such as Python. Replace /usr/bin/python with the scripting language of your choice.

Example

Here is an example %pre section:

;
%pre

#!/bin/sh

hds=""
mymedia=""

for file in /proc/ide/h*

do
     mymedia=`cat $file/media`
     if [ $mymedia == "disk" ] ; then
          hds="$hds `basename $file`"
     fi
done

set $hds
numhd=`echo $#`

drive1=`echo $hds | cut -d' ' -f1`
drive2=`echo $hds | cut -d' ' -f2`

#Write out partition scheme based on whether there are 1 or \
     2 hard drives

if [ $numhd == "2" ] ; then
     #2 drives
     echo "#partitioning scheme generated in %pre for 2 \
          drives" /tmp/part-include
     echo "clearpart --all"      /tmp/part-include
     echo "part /boot --fstype ext3 --size 75 --ondisk had" \
          /tmp/part-include
     echo "part / --fstype ext3 --size 1 --grow --ondisk hda" \
          /tmp/part-include
     echo "part swap --recommended --ondisk $drive1"  \
          /tmp/part-include
     echo "part /home --fstype ext3 --size 1 --grow --ondisk  \
          hdb" /tmp/part-include

else
     #1 drive
     echo "#partitioning scheme generated in %pre for 1 \
          drive" /tmp/part-include
     echo "clearpart --all"     /tmp/part-include
     echo "part /boot --fstype ext3 --size 75"  /tmp/part-include
     echo "part swap --recommended"     /tmp/part-include
     echo "part / --fstype ext3 --size 2048"     /tmp/part-include
     echo "part /home --fstype ext3 --size 2048 --grow"  /tmp/part- \
          include
fi

This script determines the number of hard drives in the system and writes a text file with a different partitioning scheme depending on whether the machine has one or two drives. Instead of having a set of partitioning commands in the kickstart file, include the line

%include /tmp/part-include

The partitioning commands selected in the script will be used.

Post-installation Script

You have the option of adding commands to run on the system once the installation is complete. This section must be at the end of the kickstart file and must start with the %post command. This section is useful for functions such as installing additional software and configuring an additional nameserver.

Note

If you configured the network with static IP information, including a nameserver, you can access the network and resolve IP addresses in the %post section. If you configured the network for DHCP, the /etc/resolv.conf file will not have been completed when the installation executes the %post section. You can access the network, but you cannot resolve IP addresses. Thus, if you are using DHCP, you must specify IP addresses in the %post section.
Note

The post-install script is run in a chroot environment; therefore, performing tasks such as copying scripts or RPMs from the installation media will not work.
--nochroot

Allows you to specify commands that you would like to run outside of the chroot environment. The following example copies the file /etc/resolv.conf to the file system that was just installed:

%post –nochroot
cp /etc/resolv.conf /mnt/sysimage/etc/resolv.conf
--interpreter /usr/bin/python

Allows you to specify a different scripting language, such as Python. Replace /usr/bin/python with the scripting language of your choice.

Post-installation Script Examples

Turn services on and off:

/sbin/chkconfig --level 345 telnet off
/sbin/chkconfig --level 345 finger off
/sbin/chkconfig --level 345 lpd off
/sbin/chkconfig --level 345 httpd on

Run a script named runme from an NFS share:

mkdir /mnt/temp
mount 10.10.0.2:/usr/new-machines /mnt/temp
open -s -w -- /mnt/temp/runme
umount /mnt/temp

Add a user to the system:

/usr/sbin/useradd bob
/usr/bin/chfn -f "Bob Smith" bob
/usr/sbin/usermod -p 'kjdf$04930FTH/ ' bob


Making the Kickstart File Available

A kickstart file must be placed in one of two locations:

  • On a boot diskette

  • On a network

Normally a kickstart file is copied to the boot diskette, or made available on the network. The network-based approach is most commonly used, as most kickstart installations tend to be performed on networked computers. Let us take a more in-depth look at where the kickstart file may be placed.

Creating a Kickstart Boot Diskette

To perform a diskette-based kickstart installation, the kickstart file must be named ks.cfg and must be located in the boot diskette’s top-level directory. Note that the Red Hat Linux boot diskettes are in MS-DOS format, so it is easy to copy the kickstart file under Linux using the mcopy command:

mcopy ks.cfg a:

Alternatively, you can use Windows to copy the file. You can also mount the MS-DOS boot diskette and cp the file over.

Making the Kickstart File Available on the Network

Network installations using kickstart are quite common, because system administrators can easily automate the installation on many networked computers quickly and painlessly. In general, the approach most commonly used is for the administrator to have both a BOOTP/DHCP server and an NFS server on the local network. The BOOTP/DHCP server is used to give the client system its networking information, while the actual files used during the installation are served by the NFS server. Often, these two servers run on the same physical machine, but they are not required to.

To perform a network-based kickstart installation, you must have a BOOTP/DHCP server on your network, and it must include configuration information for the machine on which you are attempting to install Red Hat Linux. The BOOTP/DHCP server will provide the client with its networking information as well as the location of the kickstart file.

If a kickstart file is specified by the BOOTP/DHCP server, the client system will attempt an NFS mount of the file’s path, and will copy the specified file to the client, using it as the kickstart file. The exact settings required vary depending on the BOOTP/DHCP server you use. Here is an example of a line from the dhcpd.conf file for the DHCP server shipped with Red Hat Linux:

filename "/usr/new-machine/kickstart/";
next-server blarg.redhat.com;

Note that you should replace the value after filename with the name of the kickstart file (or the directory in which the kickstart file resides) and the value after next-server with the NFS server name.

If the file name returned by the BOOTP/DHCP server ends with a slash (/), then it is interpreted as a path only. In this case, the client system mounts that path using NFS, and searches for a particular file. The file name the client searches for is:

<ip-addr> -kickstart

The ip-addr section of the file name should be replaced with the client’s IP address in dotted decimal notation. For example, the file name for a computer with an IP address of 10.10.0.1 would be 10.10.0.1-kickstart. Note that if you do not specify a server name, then the client system will attempt to use the server that answered the BOOTP/DHCP request as its NFS server. If you do not specify a path or file name, the client system will try to mount /kickstart from the BOOTP/DHCP server and will try to find the kickstart file using the same ip-addr -kickstart file name as described above.

Making the Installation Tree Available

The kickstart installation needs to access an installation tree. An installation tree is a copy of the binary Red Hat Linux CD-ROMs with the same directory structure. If you are performing a CD-based installation, insert the Red Hat Linux CD-ROM #1 into the computer before starting the kickstart installation. If you are performing a hard-drive installation, make sure the ISO images of the binary Red Hat Linux CD-ROMs are on a hard drive in the computer. If you are performing a network-based (NFS, FTP, or HTTP) installation, you must make the installation tree available over the network. Refer to the “Preparing for a Network Installation” section of Appendix A for details.

Starting a Kickstart Installation

To begin a kickstart installation, you must boot the system from a Red Hat Linux boot diskette or the CD-ROM and enter a special boot command at the boot prompt. If the kickstart file is located on a boot diskette that was created from the boot.img or bootnet.img image file, the correct boot command would be:

boot: linux ks=floppy

The linux ks=floppy command also works if the ks.cfg file is located on a vfat or ext2 file system on a floppy diskette and you boot from the Red Hat Linux CD-ROM. An alternate boot command for booting off the Red Hat Linux CD-ROM and having the kickstart file on a vfat or ext2 file system on a floppy diskette is:

boot: linux ks=hd:fd0/ks.cfg

If you need to use a driver disk with kickstart, you can still have the kickstart file on a floppy disk:

boot: linux ks=floppy dd

The Red Hat Linux installation program looks for a kickstart file if the ks command-line argument is passed to the kernel. The command-line argument can take a number of forms.

ks=nfs: <server> :/ <path>

The installation program will look for the kickstart file on the NFS server as file path. The installation program will use DHCP to configure the Ethernet card. For example, if your NFS server is server.example.com and the kickstart file is in the NFS share /mydir/ks.cfg, the correct boot command would be:

ks=nfs:server.example.com:/mydir/ks.cfg.

ks=http:// server / path

The installation program will look for the kickstart file on the HTTP server, as file path. The installation program will use DHCP to configure the Ethernet card. For example, if your HTTP server is server.example.com and the kickstart file is in the HTTP directory /mydir/ks.cfg, the correct boot command would be:

ks=http://server.example.com/mydir/ks.cfg.

ks=floppy

The installation program looks for the file ks.cfg on a vfat or ext2 file system on the floppy in drive /dev/fd0.

ks=hd: <device> / <file>

The installation program will mount the file system on <device> (which must be vfat or ext2), and look for the kickstart configuration file as a file in that file system (for example, ks=hd:sda3/mydir/ks.cfg).

ks=file:/ <file>

The installation program will try to read the file from the file system; no mounts will be done. This is normally used if the kickstart file is already on the initrd image.

ks=cdrom:/ <path>

The installation program will look for the kickstart file on CD-ROM, as file path.

ks

If ks is used alone, the installation program will configure the Ethernet card in the system using DHCP. The system will use the bootServer from the DHCP response as an NFS server to read the kickstart file from (by default, this is the same as the DHCP server).

The kickstart file will be identified in one of the following ways:

  • If DHCP is specified and the bootfile begins with a /, the bootfile provided by DHCP is looked for on the NFS server.

  • If DHCP is specified and the bootfile begins with something other than a /, the bootfile provided by DHCP is looked for in the /kickstart directory on the NFS server.

  • If DHCP did not specify a bootfile, then the installation program tries to read the file /kickstart/1.2.3.4-kickstart, where 1.2.3.4 is the numeric IP address of the machine being installed.

ksdevice= <device>

The installation program will use this network device to connect to the network. For example, to start a kickstart installation with the kickstart file on an NFS server that is connected to the system through the eth1 device, use the command

ks=nfs: <server> :/ <path>  ksdevice=eth1

at the boot: prompt.


Kickstart Configurator

For those who find the process of creating a kickstart file manually to be too cumbersome, Red Hat provides a graphical tool, called Kickstart Configurator, to automate the process. Kickstart Configurator asks all the questions that would be asked during the installation process, and then creates a kickstart file based on the answers it receives.

To use Kickstart Configurator, you must be running the X Window System. To start Kickstart Configurator, select the Main Menu Button (on the Panel) > System Tools > Kickstart, or type the command /usr/sbin/redhat-config-kickstart. As you are creating a kickstart file, you can select File > Preview at any time to preview your current selections.

Basic Configuration

Choose the language to use during the installation and as the default language after installation from the Language menu. Select the system keyboard type from the Keyboard menu. Choose the mouse for the system from the Mouse menu. If you choose No Mouse, no mouse will be configured. If you choose Probe for Mouse, the installation program will try to autodetect the mouse. Probing works for most modern mice. If you have a two-button mouse, you can emulate a three-button mouse by selecting Emulate 3 Buttons. If this option is selected, simultaneously clicking the left and right mouse buttons will be recognized as a middle mouse-button click.

From the Time Zone menu, choose the time zone to use for the system. Enter the desired root password for the system in the Root Password text entry box. If you want to save the password as an encrypted password in the file, select Encrypt root password. When the file is saved, the plaintext password that you typed will be encrypted and written to the kickstart file. Do not type an already encrypted password and select to encrypt it. To install languages in addition to the one selected from the Language pull-down menu, check them in the Language Support list. The language selected from the Language pull-down menu is used by default after installation; however, the default can be changed with the Language Configuration Tool (redhat-config-language) after installation.

Choosing Reboot system after installation will reboot your system automatically after the installation is finished. Kickstart installations are performed in graphical mode by default. To override this default and use text mode instead, check Perform installation in text-mode button.

You can perform a kickstart installation in interactive mode. This means that the installation program will use all the options pre-configured in the kickstart file, but it will allow you to preview the options in each screen before you can continue to the next screen. To continue to the next screen, click the Next button after you have approved the settings. If you are not satisfied with the pre-configured options, you can change them before continuing the installation. If you prefer this type of installation, check Perform installation in interactive mode button.

Installation Method

The Installation Method screen allows you to choose whether you want to perform a full installation or an upgrade. If you choose upgrade, the Partition Information and Package Selection options will be disabled. They are not supported for kickstart upgrades. Also choose the type of kickstart installation to perform from this screen. You can choose from the following options.

CD-ROM

Choose this option if you wish to install Red Hat Linux from the Red Hat Linux CD-ROMs.

Click To expand
Figure 1-1: Kickstart basic configuration

NFS

Choose this option if you wish to install Red Hat Linux from an NFS shared directory. Two text-entry boxes for the NFS server and NFS directory will appear. Enter the fully qualified domain name or IP address of the NFS server. For the NFS directory, enter the name of the NFS directory that contains the Red Hat directory of the installation tree. For example, if your NFS server contains the directory /mirrors/redhat/i386/RedHat, enter /mirrors/redhat/i386 for the NFS directory.

FTP

Choose this option if you wish to install Red Hat Linux from an FTP server. Two text-entry boxes for the FTP server and FTP directory will appear. Enter the fully qualified domain name or IP address of the FTP server. For the FTP directory, enter the name of the FTP directory that contains the Red Hat directory. For example, if your FTP server contains the directory /mirrors/redhat/i386/RedHat, enter /mirrors/redhat/i386 for the FTP directory.

Click To expand
Figure 1-2: Kickstart Installation Method screen

HTTP

Choose this option if you wish to install Red Hat Linux from an HTTP server. Two text-entry boxes for the HTTP server and HTTP directory will appear. Enter the fully qualified domain name or IP address of the HTTP server. For the HTTP directory, enter the name of the HTTP directory that contains the Red Hat directory. For example, if your HTTP server contains the directory /mirrors/redhat/i386/RedHat, enter /mirrors/redhat/i386 for the HTTP directory.

Hard Drive

Choose this option if you wish to install Red Hat Linux from a hard drive. Two text-entry boxes for hard-drive partition and hard-drive directory will appear. Hard-drive installations require the use of ISO (or CD-ROM) images. Be sure to verify that the ISO images are intact before you start the installation. To verify them, use an md5sum program. Enter the hard drive partition that contains the ISO images (for example, /dev/hda1) in the Hard Drive Partition text box, and enter the directory that contains the ISO images in the Hard Drive Directory text box.

Boot Loader Options

You have the option of installing GRUB or LILO as the boot loader. If you do not want to install a boot loader, select Do not install a boot loader. If you choose not to install a boot loader, make sure you create a boot disk or have another way (such as a third-party boot loader) to boot your system.

If you choose to install a boot loader, you must also choose which boot loader to install (GRUB or LILO) and where to install the boot loader (the Master Boot Record or the first sector of the /boot partition). Install the boot loader on the MBR if you plan to use it as your boot loader. If you are using a different boot loader, install LILO or GRUB on the first sector of the /boot partition and configure the other boot loader to boot Red Hat Linux.

If you need to pass any special parameters to the kernel to be used when the system boots, enter them in the Kernel parameters text field. For example, if you have an IDE CD-ROM writer, you can tell the kernel to use the SCSI emulation driver that must be loaded before using cdrecord by typing hdd=ide-scsi as a kernel parameter (where hdd is the device name of the CD-ROM device).

If you choose LILO as the boot loader, choose whether you want to use linear mode and whether you want to force the use of lba32 mode.

If you choose GRUB as the boot loader, you can password protect it by configuring a GRUB password. Enter a password in the Use GRUB password text-entry area. If you want to save the password as an encrypted password in the file, select Encrypt GRUB password. When the file is saved, the plaintext password that you typed will be encrypted and written to the kickstart file. Do not type an already encrypted password and select to encrypt it.

If you selected to upgrade an existing installation on the Installation Method page, you can select Upgrade existing boot loader to upgrade the existing boot loader configuration, while preserving the old entries.

Partition Information

Select whether or not to clear the Master Boot Record (MBR). You can also choose to remove all the existing partitions, remove all the existing Linux partitions, or preserve existing partitions. You can initialize the disk label to the default for the architecture of the system (msdos for x86 and gpt for Itanium). Select Initialize the disk label if you are installing on a brand new hard drive.

Creating Partitions

To create a partition, click the Add button. The Partition Options window shown in Figure 1-5 will appear. Choose mount point, file system type, and partition size for the new partition. Optionally, you can also choose from the following:

  • In the Additional Size Options section, choose to make the partition a fixed size, up to a chosen size, or fill the remaining space on the hard drive. If you selected swap as the file system type, you can select to have the installation program create the swap partition with the recommended size instead of specifying a size.

    Click To expand
    Figure 1-3: Boot loader options

  • Force the partition to be created as a primary partition.

  • Create the partition on a specific hard drive. For example, to make the partition on the first IDE hard disk (/dev/hda), specify hda as the drive. Do not include /dev in the drive name.

  • Use an existing partition. For example, to make the partition on the first partition on the first IDE hard disk (/dev/hda1), specify hda1 as the partition. Do not include /dev in the partition name.

  • Format the partition as the chosen file system type.

    Click To expand
    Figure 1-4: Partition information

To edit an existing partition, select the partition from the list and click the Edit button. The same Partitions Options window that appears when you add a partition appears, except it contains the values for the selected partition. Modify the partition options and click OK.

Creating Software RAID Partitions

Read Chapter 11 to learn more about RAID and the different RAID levels. RAID 0, 1, and 5 can be configured. To create a software RAID partition, see Figure 1-6 and use the following steps:

  1. Click the RAID button.

  2. Select Create a software RAID partition.

  3. Configure the partitions as previously described, except select Software RAID as the file system type. Also, you must specify a hard drive on which to make the partition or an existing partition to use.

    Click To expand
    Figure 1-5: Creating partitions

To delete an existing partition, select the partition from the list and click the Delete button.

Repeat these steps to create as many partitions as needed for your RAID setup. Not all of your partitions have to be RAID partitions. After creating all the partitions needed to form a RAID device, follow these steps:

Click To expand
Figure 1-6: Creating a software RAID partition

  1. Click the RAID button.

  2. Select Create a RAID device.

  3. Select a mount point, file system type, RAID device name, RAID level, RAID members, number of spares for the software RAID device, and whether to format the partition.

  4. Click OK to add the device to the list.

Network Configuration

There are three network configuration options: DHCP, Static IP, and None. If there is not an Ethernet card in the system, choose None. Networking is required only if you choose a network-based installation method (NFS, FTP, or HTTP). If you are unsure which to choose, choose None. Networking can always be configured after installation with the Network Administration Tool (redhat-config-network). If you select Static IP, you must provide additional networking information in the table below the network types.

Authentication

In the Authentication section, select whether to use shadow passwords and MD5 encryption for user passwords. These options are highly recommended and selected by default. The Authentication Configuration options allow you to configure the following methods of authentication:

Figure 1-7: Creating a software RAID device
Click To expand
Figure 1-8: Network configuration

  • NIS

  • LDAP

  • Kerberos 5

  • Hesiod

  • SMB

  • Name Switch Cache

They are not enabled by default. To enable one or more of these methods, click the appropriate tab, click the checkbutton next to Enable, and enter the appropriate information for the authentication method.

Firewall Configuration

The Firewall Configuration window is identical to the screen in the Red Hat Linux installation program and the Security Level Configuration Tool, with the same functionality. Choose between High, Medium, and Disabled security levels. Refer to Chapter 22 for detailed information about these security levels.

Click To expand
Figure 1-9: Authentication

X Configuration

If you are installing the X Window System, you can configure it during the kickstart installation by checking the Configure the X Window System button on the X Configuration window as shown in Figure 1-11. If this option is not chosen, the X configuration options will be disabled and the skipx option will be written to the kickstart file.

General

The first step in configuring X is to choose the default color depth and resolution. Select them from their respective pull-down menus. Be sure to specify a color depth and resolution that is compatible with the video card and monitor for the system.

Click To expand
Figure 1-10: Firewall configuration

If you are installing both the GNOME and KDE desktops, you need to choose which desktop you want to be the default. If you are just installing one desktop, be sure to choose it. Once the system is installed, users can choose which desktop they want to be their default.

Note

For more information about GNOME and KDE, refer to the Official Red Hat Linux User’s Guide (Red Hat Press/Wiley, 2003).

Next, choose whether to start the X Window System when the system is booted. This option will start the system in runlevel 5 with the graphical login screen. After the system is installed, this can be changed by modifying the /etc/inittab configuration file.

Click To expand
Figure 1-11: X configuration

Video Card

Probe for video card is selected by default. Accept this default if you want the installation program to probe for the video card during installation. Probing works for most modern video cards. If you select this option and the installation program cannot successfully probe the video card, the installation program will stop at the video card configuration screen. To continue the installation process, select your video card from the list and click Next.

Alternatively, you can select the video card from the list on the Video Card tab as shown in Figure 1-12. Also select the amount of video RAM the selected video card has from the Video Card RAM pull-down menu. These values will be used by the installation program to configure the X Window System.

Click To expand
Figure 1-12: X configuration: video card

Monitor

After configuring the video card, click on the Monitor tab shown in Figure 1-13. Probe for monitor is selected by default. Accept this default if you want the installation program to probe for the monitor during installation. Probing works for most modern monitors. If you select this option and the installation program cannot successfully probe the monitor, the installation program will stop at the monitor configuration screen. To continue the installation process, select your monitor from the list and click Next.

Alternatively, you can select your monitor from the list. You can also specify the horizontal and vertical sync rates instead of specifying a monitor by checking the Specify hysnc and vsync instead of monitor option. This option is useful if the monitor for the system is not listed. Notice that when this option is enabled, the monitor list is disabled.

Click To expand
Figure 1-13: X configuration: monitor

Package Selection

The Package Selection window allows you to choose which package groups to install. There are also options to resolve package dependencies automatically and to ignore package dependencies. Currently, Kickstart Configurator does not allow you to select individual packages. To install individual packages, modify the %packages section of the kickstart file after you save it.

Pre-Installation Script

You can add commands to run on the system immediately after the kickstart file has been parsed and before the installation begins. If you have configured the network in the kickstart file, the network is enabled before this section is processed. If you would like to include a pre-installation script, type it in the text area.

Click To expand
Figure 1-14: Package selection

If you want to specify a scripting language to use to execute your script, click the Use an interpreter button and enter the interpreter in the text box beside the button. For example, /usr/bin/python2.2 can be specified for a Python script. This option corresponds to using %pre --interpreter /usr/bin/python2.2 in your kickstart file.

Caution

Do not include the %pre command. It will be added for you.

Post-Installation Script

You can also add commands to execute on the system after the installation is completed. If you have properly configured the network in the kickstart file, the network is enabled. If you would like to include a post-installation script, type it in the text area.

Click To expand
Figure 1-15: Pre-installation script

For example, to change the message of the day for the newly installed system, add the following command to the %post section:

echo "Hackers will be punished!" > /etc/motd
Caution

Do not include the %post command. It will be added for you.

chroot Environment

If you want your post-installation script to run outside of the chroot environment, click the checkbutton next to this option on the top of the Post-Installation window. This is equivalent to the using the --nochroot option in the %post section.

Click To expand
Figure 1-16: Post-installation script

If you want to make any changes to the newly installed file system in the post-installation section outside of the chroot environment, you must append /mnt/sysimage to the directory name.

For example, if you check the Run outside of the chroot environment button, the previous example needs to be changed to the following:

echo "Hackers will be punished!" > /mnt/sysimage/etc/motd

Use an Interpreter

If you want to specify a scripting language to use to execute your script, click the Use an interpreter button and enter the interpreter in the text box beside the button. For example, /usr/bin/python2.2 can be specified for a Python script. This option corresponds to using %post --interpreter /usr/bin/python2.2 in your kickstart file.

Saving the File

If you want to preview the contents of the kickstart file after you have finished choosing your kickstart options, select File > Preview from the pull-down menu.

Click To expand
Figure 1-17: Preview

To save the kickstart file, select File > Save File or press Ctrl-S. A file dialog box will appear to allow you to select where to save the file. After saving the file, refer to the “ Making the Kickstart File Available” section of this chapter for information on how to start the kickstart installation.


Chapter 2: Boot Process, init, and Shutdown

An important and powerful aspect of Red Hat Linux is the open method it uses for starting and stopping the operating system. During boot time, Red Hat Linux loads programs in a specific and configurable order. Once booted, you are free to change the configuration files controlling the boot process as well as the configuration files for the programs started at boot time.

Similarly, system shutdown gracefully terminates processes in an organized and configurable way, although customization of this process is rarely required. Understanding how the boot and shutdown processes work will not only allow you to easily customize Red Hat Linux to your needs, but will also make it easier to troubleshoot problems related to starting or shutting down your system.

In addition, the initialization process used by Red Hat Linux allows for multiple configurations, or runlevels, to be created on a single machine. This allows the administrator to switch between modes, and to define a single mode as the default.

The Boot Process

Below are the basic stages of the boot process for an x86 system:

  1. The system BIOS checks the system and launches the first-stage boot loader on the MBR of the primary hard disk.

  2. The first-stage boot loader loads itself into memory and launches the second-stage boot loader from the /boot/ partition.

  3. The kernel is loaded into memory, which in turn loads any necessary modules and mounts the root partition read-only.

  4. The kernel hands control of the boot process to the /sbin/init program.

  5. The /sbin/init program loads all services and user-space tools, and mounts all partitions listed in /etc/fstab.

  6. The user is presented with a login prompt for the freshly booted Linux system.

Because configuration of the boot process is more common than the customization of the shutdown process, the remainder of this chapter will discuss in detail how the boot process works and how it can be customized to suit your needs.


A Detailed Look at the Boot Process

The very beginning of the boot process varies depending the platform on which you are booting Red Hat Linux. However, once the kernel is found and loaded by the system, the default boot process is identical across all architectures. In the example outlined below, the system will be an x86 computer.

The BIOS

When an x86 computer is booted, the processor looks at the end of system memory for the Basic Input/Output System, or BIOS, program and runs it. The BIOS not only controls the first step of the boot process but also provides the lowest level interface to peripheral devices. For this reason it is written into read-only, permanent memory and is always available for use. Other platforms use different programs to perform low-level tasks roughly equivalent to those of the BIOS on an x86 system. For instance, Itanium-based computers use the Extensible Firmware Interface (EFI) Shell, while Alpha systems use the SRM console.

Once loaded, the BIOS tests the system, looks for and checks peripherals, and then locates a valid device with which to boot the system. Usually, it first checks any floppy drives and CD-ROM drives present for bootable media, then it looks to the system’s hard drives. The order of the drives searched for booting can often be controlled with a setting in BIOS. Often, the first hard drive set to boot is the C drive or the master IDE device on the primary IDE bus. The BIOS loads whatever program is residing in the first sector of this device, called the Master Boot Record, or MBR, into memory. The MBR is only 512 bytes in size and contains machine code instructions for booting the machine, along with the partition table. Once found and loaded, the BIOS passes control whatever program is on the MBR.

The Boot Loader

This section looks at the boot process for the x86 platform. Depending on your system’s architecture, the boot process may differ slightly. Please see the section “Differences in the Boot Process of Other Architectures” later in this chapter for a brief overview of non-x86 boot processes.

Linux boot loaders for the x86 platform are broken into at least two stages. The first stage is a small machine code binary on the MBR. Its sole job is to locate the second stage boot loader and load the first part of it into memory. Under Red Hat Linux you can install one of two boot loaders: GRUB or LILO. GRUB is the default boot loader, but LILO is available for those who require it for their hardware setup or who prefer it.

If you are using LILO under Red Hat Linux, the second stage boot loader uses information on the MBR to determine what boot options are available to the user. This means that any time a configuration change is made or you upgrade your kernel manually, you must run the /sbin/lilo -v --v command to write the appropriate information to the MBR. GRUB, on the other hand, can read ext2 partitions and therefore simply loads the configuration file /boot/grub/grub.conf when the second stage loader is called.

Cross-Reference

See Chapter 3 for information on how to edit the /boot/grub/grub.conf file.
Tip

If you upgrade the kernel using the Red Hat Update Agent, the MBR or the /boot/grub/grub.conf file will be updated automatically. For more information on Red Hat Network (RHN), refer to the following URL: https://rhn.redhat.com.

Once the second stage boot loader is in memory, it presents the user with the Red Hat Linux initial graphical screen showing the different operating systems or kernels it has been configured to boot. If you have only Red Hat Linux installed and have not changed anything in the /etc/lilo.conf or /boot/grub/grub.conf files, you will see only one option for booting. If you have configured the boot loader to boot other operating systems, this screen gives you the opportunity to select them. Use the arrow keys to highlight the operating system and press Enter. If you do nothing, the boot loader will load the default selection.

Note

If you installed Symmetric Multi-Processor (SMP) kernel support, you will see more than one option the first time you boot your system. Under LILO you will see linux and linux-up. Under GRUB you will see Red Hat Linux (kernel version) and Red Hat Linux (kernel version-smp). The linux or Red Hat Linux (kernel version-smp) option is the SMP kernel. If you experience any problems with the SMP kernel, select the linux-up or non-SMP kernel upon rebooting.

If you need to alter the command-line arguments to the kernel, see Chapter 3. For information on changing the runlevel at the GRUB or LILO prompt, see the section “Init Runlevels” in this chapter.

Once the second stage boot loader has determined which kernel to boot, it locates the corresponding kernel binary in the /boot/ directory. The proper binary is the /boot/vmlinuz-2.4.x-xx file that corresponds to the boot loader’s settings. Next the boot loader places the appropriate initial RAM disk image, called an initrd, into memory. The initrd image is used by the kernel to load any drivers not compiled into it that are necessary to boot the system. This is particularly important if you have SCSI hard drives or are using the ext3 file system.

Warning

Do not remove the /initrd/ directory from the file system for any reason. Removing this directory will cause your system to fail with a kernel panic error message at boot time.

Once the kernel and the initrd image are loaded into memory, the boot loader hands control of the boot process to the kernel.

The Kernel

When the kernel loads, it immediately initializes and configures the computer’s memory. Next it configures the various hardware attached to the system, including all processors and I/O subsystems, as well as any storage devices. It then looks for the compressed initrd image in a predetermined location in memory, decompresses it, mounts it, and loads all necessary drivers. Next it initializes file system–related virtual devices, such as LVM or software RAID, before unmounting the initrd disk image and freeing up all the memory it once occupied.

After the kernel has initialized all the devices on the system, it creates a root device, mounts the root partition read-only, and frees unused memory. At this point, with the kernel loaded into memory, the system isoperational. However, with no user applications to give the user the ability to provide meaningful input to the system, not much can be done with it. To set up the user environment, the kernel starts the /sbin/init command.

The /sbin/init Program

The init program coordinates the rest of the boot process and configures the environment for the user. When the init command starts, it becomes the parent or grandparent of all of the processes that start up automatically on a Red Hat Linux system. First, it runs the /etc/rc.d/rc.sysinit script, which sets the environment path, starts swap, checks the file systems, and so on. Basically, rc.sysinit takes care of everything that a system needs to have done at initialization.

For example, most systems use a clock, so on them rc.sysinit reads the /etc/sysconfig/clock configuration file to initialize the clock. If special serial port processes must be initialized, rc.sysinit executes the /etc/rc.serial file.

The init command then runs the /etc/inittab script, which describes how the system should be set up in each SysV init runlevel. Among other things, /etc/inittab sets the default runlevel and dictates that /sbin/update should be run whenever it starts a given runlevel.

Cross-Reference

For details on making an initrd, see the section about converting to an ext3 file system in Chapter 4.
Cross-Reference

For more information on SysV init, see the section “Differences in the Boot Process of other Architectures” in this chapter. For more about init runlevels, see the “Init Runlevels” section.
Note

The update command is used to flush dirty buffers back to disk.

Next, the init command sets the source function library, /etc/rc.d/init.d/functions, for the system. This spells out how to start or kill a program and how to determine the process identification number (PID) of a program. The init program starts all of the background processes by looking in the appropriate rc directory for the runlevel specified as default in /etc/inittab. The rc directories are numbered to correspond to the runlevel they represent. For instance, /etc/rc.d/rc5.d/ is the directory for runlevel 5.

When booting to runlevel 5, the init program looks in the /etc/rc.d/rc5.d/ directory to determine which processes to start and stop. Below is an example listing for a runlevel 5, /etc/rc.d/rc5.d/ directory:

K01pppoe -> ../init.d/pppoe
K05innd -> ../init.d/innd
K10ntpd -> ../init.d/ntpd
K15httpd -> ../init.d/httpd
K15mysqld -> ../init.d/mysqld
K15pvmd -> ../init.d/pvmd
K16rarpd -> ../init.d/rarpd
K20bootparamd -> ../init.d/bootparamd
K20nfs -> ../init.d/nfs
K20rstatd -> ../init.d/rstatd
K20rusersd -> ../init.d/rusersd
K20rwalld -> ../init.d/rwalld
K20rwhod -> ../init.d/rwhod
K25squid -> ../init.d/squid
K28amd -> ../init.d/amd
K30mcserv -> ../init.d/mcserv
K34yppasswdd -> ../init.d/yppasswdd
K35dhcpd -> ../init.d/dhcpd
K35smb -> ../init.d/smb
K35vncserver -> ../init.d/vncserver
K45arpwatch -> ../init.d/arpwatch
K45named -> ../init.d/named
K50snmpd -> ../init.d/snmpd
K54pxe -> ../init.d/pxe
K55routed -> ../init.d/routed
K60mars-nwe -> ../init.d/mars-new
K61ldap -> ../init.d/ldap
K65kadmin -> ../init.d/kadmin
K65kprop -> ../init.d/kprop
K65krb524 -> ../init.d/krb524
K65krb5kdc -> ../init.d/krb5kdc
K75gated -> ../init.d/gated
K80nscd -> ../init.d/nscd
K84ypserv -> ../init.d/ypserv
K90ups -> ../init.d/ups
K96irda -> ../init.d/irda
S05kudzu -> ../init.d/kudzu
S06reconfig -> ../init.d/reconfig
S08ipchains -> ../init.d/ipchains
S10network -> ../init.d/network
S12syslog -> ../init.d/syslog
S13portmap -> ../init.d/portmap
S14nfslock -> ../init.d/nfslock
S18autofs -> ../init.d/autofs
S20random -> ../init.d/random
S25netfs -> ../init.d/netfs
S26apmd -> ../init.d/apmd
S35identd -> ../init.d/identd
S40atd -> ../init.d/atd
S45pcmcia -> ../init.d/pcmcia
S55sshd -> ../init.d/sshd
S56rawdevices -> ../init.d/rawdevices
S56xinetd -> ../init.d/xinetd
S60lpd -> ../init.d/lpd
S75keytable -> ../init.d/keytable
S80isdn -> ../init.d/isdn
S80sendmail -> ../init.d/sendmail
S85gpm -> ../init.d/gpm
S90canna -> ../init.d/canna
S90crond -> ../init.d/crond
S90FreeWnn -> ../init.d/FreeWnn
S90xfs -> ../init.d/xfs
S95anacron -> ../init.d/anacron
S95firstboot -> ../init.d/firstboot
S97rhnsd -> ../init.d/rhnsd
S99local -> ../rc.local
S99mdmonitor -> ../init.d/mdmonitor

As you can see, none of the scripts that actually start and stop the services are located in the /etc/rc.d/rc5.d/ directory. Rather, all of the files in /etc/rc.d/rc5.d/ are symbolic links pointing to scripts located in the /etc/rc.d/init.d/ directory. Symbolic links are used in each of the rc directories so that the runlevels can be reconfigured by creating, modifying, and deleting the symbolic links without affecting the actual scripts they reference.

The name of each symbolic link begin with either a K or an S. The K links are processes that are killed on that runlevel, while those beginning with an S are started. The init command first stops all of the K symbolic links in the directory by issuing the /etc/rc.d/init.d/ command stop command, where command is the process to be killed. It then starts all of the S symbolic links by issuing /etc/rc.d/init.d/ command start.

Tip

After the system is finished booting, you can log in as root and execute these same scripts to start and stop services. For instance, the command /etc/rc.d/init.d/httpd stop will stop the Apache Web server.

Each of the symbolic links is numbered to dictate start order. You can change the order in which the services are started or stopped by changing this number. Those symbolic links with the same number are started alphabetically.

In the example /etc/rc.d/rc5.d/ directory above, the init command will kill pppoe, innd, ntpd, httpd, mysqld, pvmd, rarpd, bootparamd, nfs, rstatd, rusersd, rwalld, rwhod, squid, amd, mcserv, yppasswdd, dhcpd, smb, vncserver, arpwatch, named, snmpd, pxe, routed, mars-nwe, ldap, kadmin, kprop, krb524, krb5kdc, gated, nscd, ypserv, ups, and irda. After all processes are killed, init looks into the same directory and finds start scripts for kudzu, reconfig, ipchains, portmap, nfslock, autofs, random, netfs, apmd, identd, atd, pcmcia, sshd, rawdevices, xinetd, lpd, keytable, isdn, sendmail, gpm, canna, crond, FreeWnn, xfs, anacron, firstboot, rhnsd, and mdmonitor.

The last thing the init program does is run any scripts located in /etc/rc.d/rc.local (see the section “Running Programs at Boot Time” in this chapter for more on customizing the rc.local file). At this point, the system is considered to be operating at runlevel 5.

After the init command has progressed through the appropriate rc directory for the runlevel, the /etc/inittab script forks a getty process for each virtual console (login prompts) allocated to the runlevel. Runlevels 2 through 5 get all six virtual consoles, while runlevel 1 (single-user mode) gets only one, and runlevels 0 and 6 get none. The getty process opens communication pathways to tty devices, sets their modes, prints the login prompt, gets the user name, and initiates the login process for the user. In runlevel 5, /etc/inittab runs a script called /etc/X11/prefdm. The prefdm script runs the preferred X display manager — gdm if you are running GNOME or kdm if you are running KDE — based on the contents of the /etc/sysconfig/desktop/ directory.

Finally, the init command runs the /etc/rc.d/rc.local script. At this point, you should be looking at a login prompt.


Running Programs at Boot Time

The file /etc/rc.d/rc.local script is run by the init command at boot time, or when changing runlevels, after all other initialization is complete. You can use this file to add additional commands necessary for your environment. For instance, you can start additional daemons or initialize a printer.

In addition, if you require serial port setup at boot time, you can create and edit /etc/rc.serial. This script runs setserial commands to configure the system's serial ports. See the setserial man page for more information.


Differences in the Boot Processes of Other Architectures

Once the Red Hat Linux kernel loads and hands off the boot process to the init command, the same sequence of events occurs on every architecture. So the main difference between each architecture’s boot process is in the application used to find and load the kernel. For example, the Alpha architecture uses the aboot boot loader, while the Itanium architecture uses the ELILO boot loader.


SysV init

SysV init is a standard process used by Red Hat Linux to control which software the init command launches or shuts off on a given runlevel. SysV init was chosen because it is easier to use and more flexible than the traditional BSD-style init process. The configuration files for SysV init are in the /etc/rc.d/ directory. Within this directory are the rc, rc.local, and rc.sysinit scripts as well as the following directories:

  • init.d

  • rc0.d

  • rc1.d

  • rc2.d

  • rc3.d

  • rc4.d

  • rc5.d

  • rc6.d

The init.d directory contains the scripts used by the init command when controlling services. Each of the numbered directories represents one of the six default runlevels configured by default under Red Hat Linux. For more information on runlevels, see the section “Init Runlevels” in this chapter.

The default runlevel is listed in /etc/inittab. To find out the default runlevel for your system, look for the line similar to the one below near the top of /etc/inittab:

id:3:initdefault:

The default runlevel listed in the example above is 3, as the number after the first colon indicates. If you want to change it, edit /etc/inittab as root.

Warning

Be very careful when editing /etc/inittab. Simple typos can cause your system to become unbootable. If this happens, you will either need a boot diskette for your system or you will need to enter rescue mode to boot your computer and fix the file.
Cross-Reference

For more information on rescue mode, see Appendix B.


Init Runlevels

The idea behind operating different services at different runlevels revolves around the fact that different systems can be used in a different ways. Some services cannot be used until the system is in a particular state, or mode, such as being ready for more than one user or having networking available. There are times in which you may want to operate the system at a lower mode, such as fixing disk corruption problems in runlevel 1, when no other users can possibly be on the system, or leaving a server in runlevel 3 without an X session running. In these cases, running services that depend upon a higher system mode to function does not make sense because they will not work correctly anyway.

By already having each service assigned to start when its particular runlevel is reached, you ensure an orderly startup process and can quickly change the mode of the machine without worrying about which services to manually start or stop. Generally, Red Hat Linux operates in runlevel 3 or runlevel 5 — both full multi-user modes. The following runlevels are defined in Red Hat Linux:

  • 0 — Halt

  • 1 — Single-user mode

  • 2 — Not used (user-definable)

  • 3 — Full multi-user mode

  • 4 — Not used (user-definable)

  • 5 — Full multi-user mode (with an X-based login screen)

  • 6 — Reboot

The default runlevel for a system to boot into and stop in is configured in /etc/inittab. For more information on /etc/inittab, see the “Init Runlevels” section of this chapter. Feel free to configure runlevels 2 and 4 as you see fit. Many users configure those runlevels in a way that makes the most sense for them while leaving the standard runlevels 3 and 5 alone. This allows them to quickly move in and out of their custom configuration without disturbing the normal set of features at the standard runlevels.

If your machine gets into a state where it will not boot because of a bad /etc/inittab or will not let you log in because you have a corrupted /etc/passwd or if you have simply forgotten your password, you can boot into single-user mode. If you are using LILO, you can enter single-user mode by typing linux single at the LILO boot: prompt. If you are using GRUB as your boot loader, you can enter single-user mode using the following steps.

  1. In the graphical GRUB boot loader screen, select the Red Hat Linux boot label and type e to edit it.

  2. Arrow down to the kernel line and type e to edit it.

  3. At the prompt, type single and press Enter.

  4. You will be returned to the GRUB screen with the kernel information. Type b to boot the system into single-user mode.

  5. A very bare system will boot, and you will have a command shell from which you can fix things.

If this does not work, you will need to boot by typing linux init=/bin/bash at the LILO boot: prompt. This places you at a shell prompt; note that no file systems other than the root file system are mounted, and the root file system is mounted in read-only mode. To mount it in read-write mode (to allow editing of a broken /etc/inittab, for example) do:

mount -n /proc
mount -o rw,remount /

Initscript Utilities

The /sbin/chkconfig utility is a simple command-line tool for maintaining the /etc/rc.d/init.d directory hierarchy. It relieves system administrators of having to directly manipulate the numerous symbolic links in the directories under /etc/rc.d. In addition, there is /sbin/ntsysv, which provides a text-based interface that you may find easier to use than chkconfig’s command-line interface.

If you prefer a graphical interface, use the Services Configuration Tool program, which can be invoked using the redhat-config-services command. All of these utilities must be run as root.

Cross-Reference

See Chapter 21 for more information regarding these tools.

Next, we will discuss information in the files within the /etc/sysconfig/ directory that define the parameters used by some services when they start up.


The /etc/sysconfig/ Directory

The following information outlines some of the files found in the /etc/sysconfig/ directory, their functions, and their contents. This information is not intended to be complete, as many of these files have a variety of options that are used only in very specific or rare circumstances. The /usr/share/doc/initscripts-version-number/sysconfig.txt file contains a more authoritative listing of the files found in the /etc/sysconfig directory and the configuration options available.

Files in the /etc/sysconfig/ Directory

The following files are normally found in the /etc/sysconfig/ directory:

  • amd

  • apmd

  • arpwatch

  • authconfig

  • cipe

  • clock

  • desktop

  • dhcpd

  • firstboot

  • gpm

  • harddisks

  • hwconf

  • i18n

  • identd

  • init

  • ipchains

  • iptables

  • irda

  • keyboard

  • kudzu

  • mouse

  • named

  • netdump

  • network

  • ntpd

  • pcmcia

  • radvd

  • rawdevices

  • redhat-config-users

  • redhat-logviewer

  • samba

  • sendmail

  • soundcard

  • squid

  • tux

  • ups

  • vncservers

  • xinetd

It is possible that your system may be missing a few of them if the corresponding program that would need that file is not installed. Next, we will take a look at each one.

/etc/sysconfig/amd

The /etc/sysconfig/amd file contains various parameters used by amd allowing for the automounting and automatic unmounting of file systems.

/etc/sysconfig/apmd

The /etc/sysconfig/apmd file is used by apmd as a configuration for what things to start/stop/change on suspend or resume. It is set up to turn on or off apmd during startup, depending on whether your hardware supports Advanced Power Management (APM) or if you choose not to use it. apm is a monitoring daemon that works with power management code within the Linux kernel. It can alert you to a low battery if you are using Red Hat Linux on a laptop, among other things.

/etc/sysconfig/arpwatch

The /etc/sysconfig/arpwatch file is used to pass arguments to the arpwatch daemon at boot time. The arpwatch daemon maintains a table of Ethernet MAC addresses and their IP address pairings. For more information about what parameters you can use in this file, type man arpwatch. By default, this file sets the owner of the arpwatch process to the user pcap.

/etc/sysconfig/authconfig

The /etc/sysconfig/authconfig file sets the kind of authorization to be used on the host. It contains one or more of the following lines:

  • USEMD5=value, where value is one of the following:

    • yes — MD5 is used for authentication.

    • no — MD5 is not used for authentication.

  • USEKERBEROS=value, where value is one of the following:

    • yes — Kerberos is used for authentication.

    • no — Kerberos is not used for authentication.

  • USELDAPAUTH=value, where value is one of the following:

    • yes — LDAP is used for authentication.

    • no — LDAP is not used for authentication.

/etc/sysconfig/clock

The /etc/sysconfig/clock file controls the interpretation of values read from the system clock. Earlier releases of Red Hat Linux used the following values (which are deprecated):

  • CLOCKMODE=value, where value is one of the following:

    • GMT — Indicates that the clock is set to Universal Time (Greenwich Mean Time).

    • ARC — Indicates the ARC console’s 42-year time offset is in effect (for Alpha-based systems only).

Currently, the correct values are:

  • UTC=value, where value is one of the following boolean values:

    • true — Indicates that the clock is set to Universal Time.

    • Any other value indicates that it is set to local time.

  • ARC=value, where value is the following:

    • true — Indicates the ARC console’s 42-year time offset is in effect.

    • Any other value indicates that the normal UNIX epoch is assumed (for Alpha-based systems only).

  • ZONE=filename — Indicates the timezone file under /usr/share/zoneinfo that /etc/localtime is a copy of, such as: ZONE="America/New York". Identifies the timezone file copied into /etc/localtime, such as ZONE="America/New York". Timezone files are stored in /usr/share/zoneinfo.

/etc/sysconfig/desktop

The /etc/sysconfig/desktop file specifies the desktop manager to be run, such as:

DESKTOP="GNOME"

/etc/sysconfig/dhcpd

The /etc/sysconfig/dhcpd file is used to pass arguments to the dhcpd daemon at boot time. The dhcpd daemon implements the Dynamic Host Configuration Protocol (DHCP) and the Internet Bootstrap Protocol (BOOTP). DHCP and BOOTP assign hostnames to machines on the network. For more information about what parameters you can use in this file, type man dhcpd.

/etc/sysconfig/firstboot

Beginning with Red Hat Linux 8.0, the first time you boot the system, the /sbin/init program calls the etc/rc.d/init.d/firstboot script. This allows the user to install additional applications and documentation before the boot process completes. The /etc/sysconfig/firstboot file tells the firstboot command not to run on subsequent reboots. If you want firstboot to run the next time you boot the system, simply remove /etc/sysconfig/firstboot and execute chkconfig --level 5 firstboot on.

/etc/sysconfig/gpm

The /etc/sysconfig/gpm file is used to pass arguments to the gpm daemon at boot time. The gpm daemon is the mouse server which allows mouse acceleration and middle-click pasting. For more information about what parameters you can use in this file, type man gpm. By default, it sets the mouse device to /dev/mouse.

/etc/sysconfig/harddisks

The /etc/sysconfig/harddisks file allows you to tune your hard drive(s). You can also use /etc/sysconfig/hardiskhd[a-h], where a-h are the unique identifiers for the desired drive, to configure parameters for specific drives.

Warning

Do not make changes to this file lightly. If you change the default values stored here, you could corrupt all of the data on your hard drive(s).

The /etc/sysconfig/harddisks file may contain the following:

  • USE_DMA=1, where setting this to 1 enables DMA. However, with some chipsets and hard-drive combinations, DMA can cause data corruption. Check with your hard-drive documentation or manufacturer before enabling this.

  • Multiple_IO=16, where a setting of 16 allows for multiple sectors per I/O interrupt. When enabled, this feature reduces operating system overhead by 30 to 50 percent. Use with caution.

  • EIDE_32BIT=3 enables (E)IDE 32-bit I/O support to an interface card.

  • LOOKAHEAD=1 enables drive read-lookahead.

  • EXTRA_PARAMS= specifies where extra parameters can be added.

/etc/sysconfig/hwconf

The /etc/sysconfig/hwconf file lists all the hardware that kudzu detected on your system, as well as the drivers used, vendor ID, and device ID information. The kudzu program detects and configures new and/or changed hardware on a system. The /etc/sysconfig/hwconf file is not meant to be manually edited. If you do edit it, devices could suddenly show up as being added or removed.

/etc/sysconfig/i18n

The /etc/sysconfig/i18n file sets the default language, such as:

LANG="en_US"

/etc/sysconfig/identd

The /etc/sysconfig/identd file is used to pass arguments to the identd daemon at boot time. The identd daemon returns the username of processes with open TCP/IP connections. Some services on the network, such as FTP and IRC servers, will complain and cause slow responses if identd is not running. But in general, identd is not a required service, so if security is a concern, you should not run it. For more information about what parameters you can use in this file, type man identd. By default, the file contains no parameters.

/etc/sysconfig/init

The /etc/sysconfig/init file controls how the system will appear and function during the boot process. The following values may be used:

  • BOOTUP=value, where value is one of the following:

    • BOOTUP=color means the standard color boot display, where the success or failure of devices and services starting up is shown in different colors.

    • BOOTUP=verbose means an old-style display, which provides more information than purely a message of success or failure.

    • Anything else means a new display, but without ANSI formatting.

  • RES_COL=value, where value is the number of the column of the screen to start status labels. Defaults to 60.

  • MOVE_TO_COL=value, where value moves the cursor to the value in the RES_COL line. Defaults to ANSI sequences output by echo -e.

  • SETCOLOR_SUCCESS=value, where value sets the color to a color indicating success. Defaults to ANSI sequences output by echo -e, setting the color to green.

  • SETCOLOR_FAILURE=value, where value sets the color to one indicating failure. Defaults to ANSI sequences output by echo -e, setting the color to red.

  • SETCOLOR_WARNING=value, where value sets the color to one indicating warning. Defaults to ANSI sequences output by echo -e, setting the color to yellow.

  • SETCOLOR_NORMAL=value, where value sets the color to “normal.” Defaults to ANSI sequences output by echo -e.

  • LOGLEVEL=value, where value sets the initial console logging level for the kernel. The default is 7; 8 means everything (including debugging); 1 means nothing except kernel panics. syslogd will override this once it starts.

  • PROMPT=value, where value is one of the following boolean values:

    • yes — Enables the key check for interactive mode.

    • no — Disables the key check for interactive mode.

/etc/sysconfig/ipchains

The /etc/sysconfig/ipchains file contains information used by the kernel to set up ipchains packet-filtering rules at boot time or whenever the service is started. This file is modified by typing the command /sbin/service ipchains save when valid ipchains rules are in place. You should not manually edit this file. Instead, use the /sbin/ipchains command to configure the necessary packet filtering rules and then save the rules to this file using /sbin/service ipchains save.

Note

Use of ipchains to set up firewall rules is not recommended as it is deprecated and may disappear from future releases of Red Hat Linux. If you need a firewall, use iptables instead.

/etc/sysconfig/iptables

Like /etc/sysconfig/ipchains, the /etc/sysconfig/iptables file stores information used by the kernel to set up packet-filtering services at boot time or whenever the service is started. You should not modify this file by hand unless you are familiar with how to construct iptables rules. The simplest way to add rules is to use the /usr/sbin/lokkit command or the gnome-lokkit graphical application to create your firewall. Using these applications will automatically edit this file at the end of the process.

If you wish, you can manually create rules using /sbin/iptables and then type /sbin/service iptables save to add the rules to the /etc/sysconfig/iptables file. Once this file exists, any firewall rules saved there will persist through a system reboot or a service restart.

Cross-Reference

For more information on iptables, see Chapter 22.

/etc/sysconfig/irda

The /etc/sysconfig/irda file controls how infrared devices on your system are configured at startup. The following values may be used:

  • IRDA=value, where value is one of the following boolean values:

    • yes — irattach will be run, which periodically checks to see if anything is trying to connect to the infrared port, such as another notebook computer attempting to make a network connection. For infrared devices to work on your system, this line must be set to yes.

    • no — irattach will not be run, preventing infrared device communication.

  • DEVICE=value, where value is the device (usually a serial port) that handles infrared connections.

  • DONGLE=value, where value specifies the type of dongle being used for infrared communication. This setting exists for people who use serial dongles rather than real infrared ports. A dongle is a device that is attached to a traditional serial port to communicate via infrared. This line is commented out by default because notebooks with real infrared ports are far more common than computers with add-on dongles.

  • DISCOVERY=value, where value is one of the following boolean values:

    • yes — Starts irattach in discovery mode, meaning it actively checks for other infrared devices. This needs to be turned on in order for the machine to be actively looking for an infrared connection (meaning the peer that does not initiate the connection).

    • no — Does not start irattach in discovery mode.

/etc/sysconfig/keyboard

The /etc/sysconfig/keyboard file controls the behavior of the keyboard. The following values may be used:

  • KEYBOARDTYPE=sun|pc, which is used on SPARCs only. sun means a Sun keyboard is attached on /dev/kbd, and pc means a PS/2 keyboard is connected to a PS/2 port.

  • KEYTABLE=file, where file is the name of a keytable file. For example: KEYTABLE="us". The files that can be used as keytables start in /usr/lib/kbd/keymaps/i386 and branch into different keyboard layouts from there, all labeled file.kmap.gz. The first file found beneath /usr/lib/kbd/keymaps/i386 that matches the KEYTABLE setting is used.

/etc/sysconfig/kudzu

The /etc/sysconfig/kuzdu allows you to specify a safe probe of your system’s hardware by kudzu at boot time. A safe probe is one that disables serial port probing.

  • SAFE=value, where value is one of the following:

    • yes — kuzdu does a safe probe.

    • no — kuzdu does a normal probe.

/etc/sysconfig/mouse

The /etc/sysconfig/mouse file is used to specify information about the available mouse. The following values may be used:

  • FULLNAME=value, where value refers to the full name of the kind of mouse being used.

  • MOUSETYPE=value, where value is one of the following:

    • microsoft — A Microsoft mouse.

    • mouseman — A MouseMan mouse.

    • mousesystems — A Mouse Systems mouse.

    • ps/2 — A PS/2 mouse.

    • msbm — A Microsoft bus mouse.

    • logibm — A Logitech bus mouse.

    • atibm — An ATI bus mouse.

    • logitech — A Logitech mouse.

    • mmseries — An older MouseMan mouse.

    • mmhittab — An mmhittab mouse.

  • XEMU3=value, where value is one of the following boolean values:

    • yes — The mouse has only two buttons, but three mouse buttons should be emulated.

    • no — The mouse already has three buttons.

  • XMOUSETYPE=value, where value refers to the kind of mouse used when X is running. The options here are the same as those provided by the MOUSETYPE setting in this same file.

  • DEVICE=value, where value is the mouse device. In addition, /dev/mouse is a symbolic link that points to the actual mouse device.

/etc/sysconfig/named

The /etc/sysconfig/named file is used to pass arguments to the named daemon at boot time. The named daemon is a Domain Name System (DNS) server, which implements the Berkeley Internet Name Domain (BIND) version 9 distribution. This server maintains a table of which hostnames are associated with IP addresses on the network. Currently, only the following values may be used:

  • ROOTDIR=/some/where, where /some/where refers to the full directory path of a configured chroot environment under which named will run. This chroot environment must first be configured. Type info chroot for more information on how to do this.

  • OPTIONS="value", where value is any option listed in the man page for named except -t. In place of -t, use the ROOTDIR line above.

For more information about what parameters you can use in this file, type man named. By default, the file contains no parameters.

Cross-Reference

For detailed information on how to configure a BIND DNS server, see Chapter 16.

/etc/sysconfig/netdump

The /etc/sysconfig/netdump file is the configuration file for the /etc/init.d/netdump service. The netdump service sends both oops data and memory dumps over the network. In general, netdump is not a required service, so you should run it only if you absolutely need to. For more information about what parameters you can use in this file, type man netdump.

/etc/sysconfig/network

The /etc/sysconfig/network file is used to specify information about the desired network configuration. The following values may be used:

  • NETWORKING=value, where value is one of the following boolean values:

    • yes — Networking should be configured.

    • no — Networking should not be configured.

  • HOSTNAME=value, where value should be the Fully Qualified Domain Name (FQDN), such as hostname.domain.com, but can be whatever hostname you want.

    Note

    For compatibility with older software that people might install (such as trn), the /etc/HOSTNAME file and the /etc/sysconfig/network file should contain the same value.

  • GATEWAY=value, where value is the IP address of the network’s gateway.

  • GATEWAYDEV=value, where value is the gateway device, such as eth0.

  • NISDOMAIN=value, where value is the NIS domain name.

/etc/sysconfig/ntpd

The /etc/sysconfig/ntpd file is used to pass arguments to the ntpd daemon at boot time. The ntpd daemon sets and maintains the system clock to synchronize with an Internet standard time server. It implements version 4 of the Network Time Protocol (NTP). For more information about what parameters you can use in this file, point a browser at the following file: /usr/share/doc/ntp-version/ntpd.htm (where version is the version number of ntpd). By default, this file sets the owner of the ntpd process to the user ntp.

/etc/sysconfig/pcmcia

The /etc/sysconfig/pcmcia file is used to specify PCMCIA configuration information. The following values may be used:

  • PCMCIA=value, where value is one of the following:

    • yes — PCMCIA support should be enabled.

    • no — PCMCIA support should not be enabled.

  • PCIC=value, where value is one of the following:

    • i82365 — The computer has an i82365-style PCMCIA socket chipset.

    • tcic — The computer has a tcic-style PCMCIA socket chipset.

  • PCIC_OPTS=value, where value is the socket driver (i82365 or tcic) timing parameters.

  • CORE_OPTS=value, where value is the list of pcmcia_core options.

  • CARDMGR_OPTS=value, where value is the list of options for the PCMCIA cardmgr (such as -q for quiet mode, -m to look for loadable kernel modules in the specified directory, and so on). Read the cardmgr man page for more information.

/etc/sysconfig/radvd

The /etc/sysconfig/radvd file is used to pass arguments to the radvd daemon at boot time. The radvd daemon listens to for router requests and sends router advertisements for the IP version 6 protocol. This service allows hosts on a network to dynamically change their default routers based on these router advertisements. For more information about what parameters you can use in this file, type man radvd. By default, this file sets the owner of the radvd process to the user radvd.

/etc/sysconfig/rawdevices

The /etc/sysconfig/rawdevices file is used to configure raw device bindings, such as:

/dev/raw/raw1 /dev/sda1
/dev/raw/raw2 8 5

/etc/sysconfig/redhat-config-users

The /etc/sysconfig/redhat-config-users file is the configuration file for the graphical application User Manager. Under Red Hat Linux 8.0, this file is used to filter out system users such as root, daemon, and lp. This file is edited via the Preferences > Filter system users and groups pull-down menu in the User Manager application and should not be edited manually. For more information on using this application, see Chapter 7.

/etc/sysconfig/redhat-logviewer

The /etc/sysconfig/redhat-logviewer file is the configuration file for the graphical, interactive log viewing application Log Viewer. This file is edited via the Edit > Preferences pull-down menu in the Log Viewer application and should not be edited manually.

/etc/sysconfig/samba

The /etc/sysconfig/samba file is used to pass arguments to the smbd and the nmbd daemons at boot time. The smbd daemon offers file-sharing connectivity for Windows clients on the network. The nmbd daemon offers NetBIOS-over-IP naming services. For more information about what parameters you can use in this file, type man smbd. By default, this file sets smbd and nmbd to run in daemon mode.

/etc/sysconfig/sendmail

The /etc/sysconfig/sendmail file allows messages to be sent to one or more recipients, routing the message over whatever networks are necessary. The file sets the default values for the Sendmail application to run. Its default values are to run as a background daemon, and to check its queue once an hour in case something has backed up and stalled the process. The following values may be used:

  • DAEMON=value, where value is one of the following boolean values:

    • yes — Sendmail should be configured to listen to port 25 for incoming mail. yes implies the use of Sendmail's -bd options.

    • no — Sendmail should not be configured to listen to port 25 for incoming mail.

  • QUEUE=1h, which is given to Sendmail as -q$QUEUE. The -q option is not given to Sendmail if /etc/sysconfig/sendmail exists and QUEUE is empty or undefined.

/etc/sysconfig/soundcard

The /etc/sysconfig/soundcard file is generated by sndconfig and should not be modified. The sole use of this file is to determine what card entry in the menu to pop up by default the next time sndconfig is run. Sound card configuration information is located in the /etc/modules.conf file. It may contain the following:

  • CARDTYPE=value, where value is set to, for example, SB16 for a Soundblaster 16 sound card.

/etc/sysconfig/squid

The /etc/sysconfig/squid file is used to pass arguments to the squid daemon at boot time. The squid daemon is a proxy caching server for Web client applications. For more information on configuring a squid proxy server, use a Web browser to open the /usr/share/doc/squid-version/ directory (replace version with the squid version number installed on your system). By default, this file sets squid to start in daemon mode and sets the amount of time before it shuts itself down.

/etc/sysconfig/tux

The /etc/sysconfig/tux file is the configuration file for the Red Hat Content Accelerator (formerly known as TUX), the kernel-based Web server. For more information on configuring the Red Hat Content Accelerator, use a Web browser to open the /usr/share/doc/tux-version/tux/index.html file (replace version with the version number of TUX installed on your system). The parameters available for this file are listed in /usr/share/doc/tux-version/tux/parameters.html.

/etc/sysconfig/ups

The /etc/sysconfig/ups file is used to specify information about any Uninterruptible Power Supplies (UPS) connected to your system. A UPS can be very valuable for a Red Hat Linux system because it gives you time to correctly shut down the system in the case of power interruption. The following values may be used:

  • SERVER=value, where value is one of the following:

    • yes — A UPS device is connected to your system.

    • no — A UPS device is not connected to your system.

  • MODEL=value, where value must be one of the following or set to NONE if no UPS is connected to the system:

    • apcsmart — For an APC SmartUPSTM or similar device.

    • fentonups — For a Fenton UPSTM.

    • optiups — For an OPTI-UPSTM device.

    • bestups — For a Best PowerTM UPS.

    • genericups — For a generic brand UPS.

    • ups-trust425+625 — For a TrustTM UPS.

  • DEVICE=value, where value specifies where the UPS is connected, such as /dev/ttyS0.

  • OPTIONS=value, where value is a particular command that needs to be passed to the UPS.

/etc/sysconfig/vncservers

The /etc/sysconfig/vncservers file configures the way the Virtual Network Computing (VNC) server starts up. VNC is a remote display system which allows you to view a desktop environment not only on the machine where it is running but across different networks on a variety of architectures. It may contain the following:

  • VNCSERVERS=value, where value is set to something like 1:fred, to indicate that a VNC server should be started for user fred on display :1. User fred must have set a VNC password using vncpasswd before attempting to connect to the remote VNC server.

Note that when you use a VNC server, your communication with it is unencrypted, and so it should not be used on an untrusted network. For specific instructions concerning the use of SSH to secure the VNC communication, see http://www.uk.research.att.com/vnc/sshvnc.html. To find out more about SSH, see Chapter 24.

/etc/sysconfig/xinetd

The /etc/sysconfig/xinetd file is used to pass arguments to the xinetd daemon at boot time. The xinetd daemon starts programs that provide Internet services when a request to the port for that service is received. For more information about what parameters you can use in this file, type man xinetd. For more information on the xinetd service, see Chapter 21.

Directories in the /etc/sysconfig/ Directory

The following directories are normally found in /etc/sysconfig/.

apm-scripts

This contains the Red Hat APM suspend/resume script. You should not edit this file directly. If you need customization, simply create a file called /etc/sysconfig/apm-scripts/apmcontinue and it will be called at the end of the script. Also, you can control the script by editing /etc/sysconfig/apmd.

cbq

This directory contains the configuration files needed to do Class Based Queuing for bandwidth management on network interfaces.

networking

This directory is used by the Network Administration Tool (redhat-config-network), and its contents should not be edited manually. For more information about configuring network interfaces using the Network Administration Tool, see Chapter 13.

network-scripts

This directory contains the following network-related configuration files:

  • Network configuration files for each configured network interface, such as ifcfg-eth0 for the eth0 Ethernet interface.

  • Scripts used to bring up and down network interfaces, such as ifup and ifdown.

  • Scripts used to bring up and down ISDN interfaces, such as ifup-isdn and ifdown-isdn.

  • Various shared network function scripts that should not be edited directly.

    Cross-Reference

    For more information on the network-scripts directory, see Chapter 12.

rhn

This directory contains the configuration files and GPG keys for Red Hat Network. No files in this directory should be edited by hand. For more information on Red Hat Network, see the Red Hat Network website at https://rhn.redhat.com.


Shutting Down

To shut down Red Hat Linux, issue the shutdown command. You can read the shutdown man page for complete details, but the two most common uses are:

/sbin/shutdown -h now
/sbin/shutdown -r now

You must run shutdown as root. After you’ve shut everything down, the -h option will halt the machine, and the -r option will reboot. Non-root users can use the reboot and halt commands to shut down the system while in runlevels 1 through 5. However, not all Linux distributions support this feature.

If your computer does not power itself down, be careful not to turn it off until you see a message indicating that the system is halted. Failure to wait for this message means you may be turning off the machine before the hard-drive partitions are unmounted, which can cause file system corruption.


Chapter 3: GRUB

As you saw in the previous chapter, in order for a Red Hat Linux system to boot properly, a boot loader — typically either GRUB or LILO — must be invoked in order for the operating system to be loaded and initialized. The default boot loader for Red Hat Linux 8.0 is GRUB, the GRand Unified Boot loader. In addition to loading the Red Hat Linux operating system, GRUB allows for multiple boot options to be configured. For example, GRUB can be used in a dual-boot situation, where both Red Hat Linux and another operating system like Windows are available. GRUB can also be used to pass boot-time arguments to the kernel.

Note

GRUB is typically used only on Intel-compatible x86 architectures. If your architecture differs, see the available documentation at http://www.redhat.com.

GRUB and the x86 Boot Process

This section discusses the specific role GRUB plays when booting an x86 system. For a detailed look at the overall boot process, see Chapter 2. GRUB loads itself into memory in the following stages:

  1. The Stage 1 or primary boot loader is read into memory by the BIOS from the MBR1. The primary boot loader exists on less than 512 bytes of disk space within the MBR. The only thing it does is load the Stage 1.5 or Stage 2 boot loader.

  2. The Stage 1.5 boot loader is read into memory by the Stage 1 boot loader only if necessary. Some hardware requires an intermediate step to get to the Stage 2 boot loader. This is sometimes true when the /boot partition is above the 1024-cylinder head of the hard drive or when using LBA mode. The Stage 1.5 boot loader is found either on the /boot partition or on a small part of the MBR and the /boot partition.

  3. The Stage 2 or secondary boot loader is read into memory. The secondary boot loader displays the GRUB menu and command environment. This interface allows you to select which operating system or Linux kernel to boot, pass arguments to the kernel, or look at system parameters, such as available RAM.

  4. The secondary boot loader reads the operating system or kernel and initrd into memory. Once GRUB determines which operating system to start, it loads it into memory and hands control of the machine to that operating system.

The boot method used to boot Red Hat Linux is called the direct loading method because the boot loader loads the operating system directly. There is no intermediary between the boot loader and the kernel.

Cross-Reference

For more on the system BIOS and the MBR, see Chapter 2.

The boot process used by other operating systems may differ. For example, Microsoft’s DOS and Windows operating systems, as well as various other proprietary operating systems, are loaded using a chain loading boot method. Under this method, the MBR simply points to the first sector of the partition holding the operating system. There it finds the files necessary to actually boot that operating system. GRUB supports both direct and chain loading boot methods, allowing it to boot almost any operating system.

Warning

During installation, Microsoft’s DOS and Windows installer completely overwrites the MBR, destroying any existing boot loader. If creating a dual-boot system, it is best to install the Microsoft operating system first.


Features of GRUB

A number of features make GRUB preferable to other boot loaders available for the x86 architecture. Below is a list of some of the more important features:

  • GRUB provides a true command-based, pre-OS environment on x86 machines. This affords the user maximum flexibility in loading operating systems with certain options or gathering information about the system. For years many non-x86 architectures have employed pre-OS environments that allow system booting from a command line. While some command features are available with LILO and other x86 boot loaders, GRUB is more feature rich.

  • GRUB supports Logical Block Addressing (LBA) mode. LBA places the addressing conversion used to find files in the hard driver’s firmware, and it is used on many IDE and all SCSI hard devices. Before LBA, boot loaders could encounter the 1024-cylinder BIOS limitation, where the BIOS could not find a file after that cylinder head of the disk. LBA support allows GRUB to boot operating systems from partitions beyond the 1024-cylinder limit, so long as the system BIOS supports LBA mode. Most modern BIOS revisions support LBA mode.

  • GRUB can read ext2 partitions. This allows GRUB to access its configuration file, /boot/grub/grub.conf, every time the system boots, obviating the need for the user to write a new version of the first-stage boot loader to MBR when configuration changes are made. The only time a user would need to reinstall GRUB on the MBR is if the physical location of the /boot partition is moved on the disk. For details on installing GRUB to the MBR, see the next section.


Installing GRUB

If GRUB was not installed during the Red Hat Linux installation process, you can install it afterwards and it will automatically become the default boot loader. Before installing GRUB, make sure you have the latest GRUB package available, or use the GRUB package from the Red Hat Linux installation CD-ROMs.

Cross-Reference

For instructions on installing packages, see Chapter 6.

Once the GRUB package is installed, open a root shell prompt and run the command /sbin/grub-install location, where location is the location where GRUB Stage 1 boot loader should be installed. The following command installs GRUB to the MBR of the master IDE device on the primary IDE bus, also known as the C drive:

/sbin/grub-install /dev/hda

The next time you boot the system, you should see the GRUB graphical boot loader menu before the kernel loads.


GRUB Terminology

When configuring GRUB, it is important to understand the way in which it refers to devices on any particular system. The device naming conventions differ from typical Linux /dev entries, and the GRUB syntax must be understood if advanced or unusual configurations, such as setting up a dual-boot system, are to be included on your system.

Device Names

The first hard drive of a system is called (hd0) by GRUB. The first partition on that drive is called (hd0,0), and the fifth partition on the second hard drive is called (hd1,4). In general, the naming convention for file systems when using GRUB breaks down in this way:

( <type-of-device> <bios-device-number> , <partition-number> )

The parentheses and comma are very important to the device naming conventions. The type-of-device refers to whether a hard disk (hd) or floppy disk (fd) is being specified. The bios-device-number is the number of the device according to the system’s BIOS, starting with 0. The primary IDE hard drive is numbered 0, while the secondary IDE hard drive is numbered 1. The ordering is roughly equivalent to the way the Linux kernel arranges the devices by letters, where the a in hda relates to 0, the b in hdb relates to 1, and so on.

Note

GRUB’s numbering system for devices starts with 0, not 1. Failing to make this distinction is one of the most common mistakes made by new GRUB users.

The partition-number relates to the number of a specific partition on a disk device. Like the bios-device-number, the partition numbering starts at 0. While most partitions are specified by numbers, if a system uses BSD partitions, they are signified by letters, such as a or c.

GRUB uses the following rules when naming devices and partitions:

  • It does not matter if system hard drives are IDE or SCSI. All hard drives start with hd. Floppy disks start with fd.

  • To specify an entire device without respect to its partitions, simply omit the comma and the partition number. This is important when telling GRUB to configure the MBR for a particular disk. For example, (hd0) specifies the MBR on the first device and (hd3) specifies the MBR on the fourth device.

  • If a system has multiple drive devices, it is very important to know the drive boot order set in the BIOS. This is rather simple to do if a system has only IDE or SCSI drives, but if there is a mix of devices, it can become confusing.

File Names

When typing commands to GRUB involving a file, such as a menu list to use when allowing the booting of multiple operating systems, it is necessary to include the name of the file immediately after specifying the device and partition. A sample file specification to an absolute file name is organized as follows:

( <type-of-device> <bios-device-number> , <partition-number> \
 )/path/to/file

Most of the time, a user will specify files by the directory path on that partition, plus the file name. It is also possible to specify files to GRUB that do not actually appear in the file system, such as a chain loader that appears in the first few blocks of a partition. To specify these files, you must provide a blocklist, which tells GRUB, block by block, where the file is located in the partition. Since a file can comprise several different sets of blocks, there is a specific way to write blocklists. Each file’s section location is described by an offset number of blocks and then a number of blocks from that offset point, and the sections are put together in a comma-delimited order. Consider the following blocklist:

0+50,100+25,200+1

This blocklist tells GRUB to use a file that starts at the first block on the partition and uses blocks 0 through 49, 99 through 124, and 199. Knowing how to write blocklists is useful when using GRUB to load operating systems that use chain loading, such as Microsoft Windows. It is possible to leave off the offset number of blocks if starting at block 0. As an example, the chain loading file in the first partition of the first hard drive would have the following name:

(hd0,0)+1

The following shows the chainloader command with a similar blocklist designation at the GRUB command line after setting the correct device and partition as root:

chainloader +1

GRUB’s Root File System

Some users are confused by the use of the term “root file system” with GRUB. It is important to remember that GRUB’s root file system has nothing to do with the Linux root file system. The GRUB root file system is the root partition for a particular device. GRUB uses this information to mount the device and load files from it.

With Red Hat Linux, once GRUB has loaded its root partition, which equates to the /boot partition and contains the Linux kernel, the kernel command can be executed with the location of the kernel file as an option. Once the Linux kernel boots, it sets its own root file system. The original GRUB root file system and its mounts are forgotten; they existed only to boot the kernel file. Refer to the root and kernel commands in the “GRUB Commands” section of this chapter for more information.


GRUB Interfaces

GRUB features three interfaces, each of which provides a different level of functionality. Each of these interfaces allows users to boot operating systems and move between interfaces within the GRUB environment.

Menu Interface

If GRUB was automatically configured by the Red Hat Linux installation program, this is the interface shown by default. A menu of operating systems or kernels preconfigured with their own boot commands are displayed as a list, ordered by name. Use the arrow keys to select an option other than the default selection and press the Enter key to boot it. Alternatively, a timeout period is set, so that GRUB will start loading the default option.

From the menu interface, type e to enter the entry editor interface or c to load a command-line interface. See the “Command-Line Interface” section of this chapter for more information on configuring this interface.

Menu Entry Editor Interface

To access the menu entry editor, type e at the boot loader menu. The GRUB commands for that entry are displayed here, and users may alter these command lines before booting the operating system by adding a command line (o inserts the new line after the current line and O before it), editing one (e), or deleting one (d).

After all changes are made, type b to execute the commands and boot the operating system. The Esc key discards any changes and reloads the standard menu interface. Type c to load the command-line interface.

Command-Line Interface

The command line is the most basic GRUB interface, but it is also the one that grants the most control. The command line makes it possible to type any relevant GRUB commands followed by the Enter key to execute them. This interface features some advanced shell-like features, including Tab key completion, based on context, and Ctrl key combinations when typing commands, such as Ctrl-a to move to the beginning of a line, and Ctrl-e to move to the end of a line. In addition, the arrow, Home, End, and Delete keys work as they do in the bash shell. See the “GRUB Commands” section for a list of common commands.

Order of Interface Use

When the GRUB environment loads the second-stage boot loader, it looks for its configuration file. When found, it uses the configuration file to build the menu list and displays the boot menu interface. If the configuration file cannot be found, or if the configuration file is unreadable, GRUB will load the command-line interface to allow users to manually type the commands necessary to boot an operating system.

If the configuration file is not valid, GRUB will print out the error and ask for input. This can be very helpful, because users can then see precisely where the problem occurred and fix it in the file. Pressing any key will reload the menu interface, where it is then possible to edit the menu option and correct the problem based on the error reported by GRUB. If the correction fails, the error is reported and GRUB will begin again.


GRUB Commands

GRUB allows a number of useful commands in its command-line interface. Some of the commands accept options after their name, and these options should be separated from the command and other options on that line by space characters. The following is a list of useful commands:

  • boot — Boots the operating system or chain loader that has been previously specified and loaded.

  • chainloader filename — Loads the specified file as a chain loader. To grab the file at the first sector of the specified partition, use +1 as the file’s name.

  • displaymem — Displays the current use of memory, based on information from the BIOS. This is useful to determine how much RAM a system has prior to booting it.

  • initrd filename — Enables users to specify an initial RAM disk to use when booting. An initrd is necessary when the kernel needs certain modules in order to boot properly, such as when the root partition is formated with the ext3 file system.

  • install stage-1 install-disk stage-2 p config-file — Installs GRUB to the system MBR.

    Warning

    The install command will overwrite any other information in the MBR. If it is executed, any information (other than GRUB information) that is used to boot other operating systems will be lost. Make sure you know what you are doing before executing this command.

  • This command can be configured in several different ways. However, it is required to specify a stage-1, which signifies a device, partition, and file where the first boot loader image can be found, such as (hd0,0)/grub/stage1. In addition, specify the disk where the stage 1 boot loader should be installed, such as (hd0). The stage-2 section tells the stage 1 boot loader where the stage 2 boot loader is located, such as (hd0,0)/grub/stage2. The p option tells the install command that a menu configuration file is being specified in the config-file section, such as (hd0,0)/grub/grub.conf.

  • kernel kernel-filename option-1 option-N — Specifies the kernel file to load from GRUB’s root file system when using direct loading to boot the operating system. Options can follow the kernel command and will be passed to the kernel when it is loaded. For Red Hat Linux, an example kernel command looks like the following:

    kernel /vmlinuz root=/dev/hda5

  • This line specifies that the vmlinuz file is loaded from GRUB’s root file system, such as (hd0,0). An option is also passed to the kernel specifying that the root file system for the Linux kernel when it loads should be on hda5, the fifth partition on the first IDE hard drive. Multiple options may be placed after this option, if needed.

  • root device-and-partition — Configures GRUB’s root partition to be the particular device and partition, such as (hd0,0), and mounts the partition so that files can be read.

  • rootnoverify device-and-partition — Does the same thing as the root command but does not mount the partition.

Commands other than these are available. Type info grub for a full list of commands.


GRUB Menu Configuration File

The configuration file, which is used to create the list in GRUB’s menu interface of operating systems to boot, essentially allows the user to select a preset group of commands to execute. The commands given in the previous “GRUB Commands” section of this chapter can be used, as well as some special commands that are available only in the configuration file.

Special Configuration File Commands

The following commands can be used only in the GRUB menu configuration file:

  • color normal-color selected-color — Configures specific colors for the foreground and background of the GRUB menu. Use simple color names, such as red/black. For example:

     color red/black green/blue.

  • default title-name — The default entry title name that will be loaded if the menu interface times out.

  • fallback title-name — If used, the entry title name to try if first attempt fails.

  • hiddenmenu — If used, prevents the GRUB menu interface from being displayed, loading the default entry when the timeout period expires. The user can see the standard GRUB menu by pressing the Esc key.

  • password password — If used, prevents the user who does not know the password from editing the entries for this menu option. Optionally, it is possible to specify an alternate menu configuration file after the password, so that, if the password is known, GRUB will restart the second stage of the boot loader and use this alternate configuration file to build the menu. If this alternate file were left out of the command, then a user who knows the password would be able to edit the current configuration file.

  • timeout — If used, sets the interval, in seconds, before GRUB loads the entry designated by the default command.

  • splashimage — Specifies the location of the splash screen image to be used when GRUB boots.

  • title — Sets a title to be used with a particular group of commands used to load an operating system. The # character can be used to place comments in the menu configuration file.

Configuration File Structure

The GRUB menu interface’s configuration file is /boot/grub/grub.conf. The commands to set the global preferences for the menu interface are placed at the top of the file, followed by the different entries for each of the operating systems or kernels listed in the menu. A very basic GRUB menu configuration file designed to boot either Red Hat Linux or Microsoft Windows 2000 might look as follows:

default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz

# section to load linux
title Red Hat Linux (2.4.18-5.47)
                root (hd0,0)
                kernel /vmlinuz-2.4.18-5.47 ro root=/dev/sda2
                initrd /initrd-2.4.18-5.47.img

# section to load Windows 2000
title windows
                rootnoverify (hd0,0)
                chainloader +1

This file would tell GRUB to build a menu with Red Hat Linux as the default operating system, set to autoboot it after 10 seconds. Two sections are given, one for each operating system entry, with commands specific to this system’s disk partition table.

Note

The default is specified as a number. This refers to the first title line GRUB comes across. If you want Windows to be the default, change the default= value to 1.


Chapter 4: Red Hat Linux File System

This chapter discusses the file systems used by Red Hat Linux. In particular, it focuses on three areas:

  • The structure and organization of the Red Hat Linux file system, including the directory layout and organization of files

  • The features and management of the ext3 (third extended) file system, including how data is formatted and managed in that system

  • The /proc virtual file system

The Red Hat Linux File System

The Red Hat file system uses a single consistent structure, which is described in the following section.

Why Share a Common Structure?

An operating system’s file system structure is its most basic level of organization. Almost all of the ways an operating system interacts with its users, applications, and security model are dependent upon the way it stores its files on a storage device. It is crucial for a variety of reasons that users, as well as programs, be able to refer to a common guideline to know where to read and write files. A file system can be seen in terms of two different logical categories of files:

  • Shareable versus unshareable files

  • Variable versus static files

Shareable files are those that can be accessed by various hosts; unshareable files are not available to any other hosts. Variable files can change at any time without any intervention; static files, such as read-only documentation and binaries, do not change without an action from the system administrator or an agent that the system administrator has placed in motion to accomplish that task.

The reason for looking at files in this way is to help you understand the type of permissions given to the directory that holds them. The way in which the operating system and its users need to use the files determines the directory where those files should be placed, whether the directory is mounted read-only or read-write, and the level of access allowed on each file. The top level of the file system must be organized properly, using a known structure, or security and user access problems may arise.

However, simply having a structure does not mean very much unless it is a standard. Competing structures can actually cause more problems than they fix. Because of this, Red Hat has chosen the most widely used file system structure and extended it only slightly to accommodate special files used within Red Hat Linux.


Overview of File System Hierarchy Standard (FHS)

Red Hat is committed to the File System Hierarchy Standard (FHS), a collaborative document that defines the names and locations of many files and directories. Red Hat continues to track and follow the standard to keep Red Hat Linux FHS-compliant. The current FHS document is the authoritative reference to any FHS-compliant file system, but the standard leaves many areas undefined or extendable. This section provides an overview of the standard and a description of the parts of the file system not covered by the standard. The complete standard is available at http://www.pathname.com/fhs.

Compliance with the standard means many things, but the two most important are compatibility with other compliant systems and the ability to mount a /usr partition as read-only because it contains common executables and is not meant to be changed by users. Since the /usr directory is mounted read-only, it can be mounted from the CD-ROM or from another machine via a read-only NFS mount.

FHS Organization

The directories and files noted here are a small subset of those specified by the FHS document. Check the latest FHS document for the most complete information.

The /dev Directory

The /dev directory contains file system entries which represent devices that are attached to the system. These files are essential for the system to function properly.

The /etc Directory

The /etc directory is reserved for configuration files that are local to your machine. No binaries are to be put in /etc. Any binaries that, in previous versions, were put in /etc should now go into /sbin or possibly /bin. The X11 and skel directories are subdirectories of the /etc directory:

/etc
      |- X11
      |- skel

The X11 directory is for X11 configuration files such as XF86Config. The skel directory is for “skeleton” user files, which are used to populate a home directory when a user is first created.

The /lib Directory

The /lib directory should contain only those libraries that are needed to execute the binaries in /bin and /sbin. These shared library images are particularly important for booting the system and executing commands within the root file system.

The /mnt Directory

The /mnt directory is for temporarily mounted file systems, such as CD-ROMs and floppy disks.

The /opt Directory

The /opt directory provides an area for large, static application software packages to be stored. For packages that wish to avoid putting their files throughout the file system, /opt provides a logical and predictable organizational system under that package’s directory. This gives the system administrator an easy way to determine the role of each file within a particular package. For example, if sample is the name of a particular software package located within /opt, then all of its files could be placed within directories inside /opt/sample, such as /opt/sample/bin for binaries and /opt/sample/man for man pages.

Large packages that encompass many different sub-packages, each of which accomplish a particular task, also go within /opt, giving that large package a standardized way to organize itself. In this way, our sample package may have different tools that each go in their own sub-directories, such as /opt/sample/tool1 and /opt/sample/tool2, each of which can have their own bin, man, and other similar directories.

The /proc Directory

The /proc directory contains special “files” that either extract information from or send information to the kernel. Because of the great variety of data available within /proc and the many ways this directory can be used to communicate with the kernel, an entire chapter (Chapter 12) has been devoted to the subject. For more information, please see the “/proc” section of this appendix.

The /sbin Directory

The /sbin directory is for executables used only by the root user. The executables in /sbin are used only to boot and mount /usr and perform system recovery operations. The FHS says: “/sbin typically contains files essential for booting the system in addition to the binaries in /bin. Anything executed after /usr is known to be mounted (when there are no problems) should be placed in /usr/sbin. Local-only system administration binaries should be placed into /usr/local/sbin.”

At a minimum, the following programs should be in /sbin: arp, clock, getty, halt, init, fdisk, fsck.*, grub, ifconfig, lilo, mkfs.*, mkswap, reboot, route, shutdown, swapoff, swapon, and update.

The /usr Directory

The /usr directory is for files that can be shared across a whole site. The /usr directory usually has its own partition, and it should be mountable read-only. At minimum, the following directories should be subdirectories of /usr:

/usr
  |- bin
  |- dict
  |- doc
  |- etc
  |- games
  |- include
  |- kerberos
  |- lib
  |- libexec
  |- local
  |- sbin
  |- share
  |- src
  |- tmp -> ../var/tmp
  |- X11R6

The bin directory contains executables, dict contains non–FHS compliant documentation pages, etc contains system-wide configuration files, games is for games, include contains C header files, kerberos contains binaries and much more for Kerberos, and lib contains object files and libraries that are not designed to be directly utilized by users or shell scripts. The libexec directory contains small helper programs called by other programs, sbin is for system administration binaries (those that do not belong in /sbin), share contains files that are not architecture-specific, src is for source code, and X11R6 is for the X Window System (XFree86 on Red Hat Linux).

The /usr/local Directory

The FHS says: “The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable among a group of hosts, but not found in /usr.”

The /usr/local directory is similar in structure to the /usr directory. It has the following subdirectories, which are similar in purpose to those in the /usr directory:

/usr/local
             |- bin
             |- doc
             |- etc
             |- games
             |- include
             |- lib
             |- libexec
             |- sbin
             |- share
             |- src

The /var Directory

Since the FHS requires that you be able to mount /usr read-only, any programs that write log files or need spool or lock directories should write them to the /var directory. The FHS states /var is for: “... variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files.” Following are some of the directories that should be subdirectories of /var:

/var
      |- account
      |- arpwatch
      |- cache
      |- crash
      |- db
      |- empty
      |- ftp
      |- gdm
      |- kerberos
      |- lib
      |- local
      |- lock
      |- log
      |- mail -> spool/mail
      |- mailman
      |- named
      |- nis
      |- opt
      |- preserve
      |- run
      +- spool
         |- anacron
         |- at
         |- cron
         |- fax
         |- lpd
         |- mail
         |- mqueue
         |- news
         |- rwho
         |- samba
         |- slrnpull
         |- squid
         |- up2date
         |- uucp
         |- uucppublic
         |- vbox
         |- voice
      |- tmp
      |- tux
      |- www
      |- yp

System log files such as messages and lastlog go in /var/log. The /var/lib/rpm directory also contains the RPM system databases. Lock files go in /var/lock, usually in directories particular for the program using the file. The /var/spool directory has subdirectories for various systems that need to store data files.

/usr/local in Red Hat Linux

In Red Hat Linux, the intended use for /usr/local is slightly different from that specified by the FHS. The FHS says that /usr/local should be where you store software that is to remain safe from system software upgrades. Since system upgrades from Red Hat are done safely with the rpm command and the graphical Package Management Tool application, you do not need to protect files by putting them in /usr/local. Instead, use /usr/local for software that is local to your machine.

For instance, say you have mounted /usr via read-only NFS from a host named jake. If there is a package or program you would like to install, but you are not allowed to write to jake, you should install it under /usr/local. Later, perhaps, if you have managed to convince the system administrator of jake to install the program on /usr, you can uninstall it from /usr/local.


Special File Locations

Red Hat extends the FHS structure slightly to accommodate special files used by Red Hat Linux. Most files pertaining to the Red Hat Package Manager (RPM) are kept in the /var/lib/rpm/ directory. For more information on RPM, see Chapter 6.

The /var/spool/up2date/ directory contains files used by Red Hat Update Agent, including RPM header information for the system. This location may also be used to temporarily store RPMs downloaded while updating your system. For more information on Red Hat Update Agent and Red Hat Network, see the Red Hat Network website at https://rhn.redhat.com/.

Another location specific to Red Hat Linux is the /etc/sysconfig/ directory. This directory stores a variety of configuration information. Many scripts that run at boot time use the files in this directory. See Chapter 2 for more information on what is within this directory and the role these files play in the boot process.

Finally, one more directory worth noting is the /initrd/ directory. It is empty, but it is used as a critical mount point during the boot process.

Warning

Do not remove the /initrd/ directory for any reason. Removing this directory will cause your system to fail to boot with a kernel panic error message.


The Ext3 File System

The ext3, or third extended, file system is the default file system used on Red Hat Linux 8.0. ext3 has been the default file system on all Red Hat Linux versions since version 7.2. ext3 replaces the venerable ext2 file system. Data is easily converted between the two file systems, and ext3 adds several new features, most notably journaling, which permits better maintenance of data integrity.

Features of ext3

The ext3 file system is essentially an enhanced version of the ext2 file system. These improvements provide the following advantages.

Availability

After an unexpected power failure or system crash (also called an unclean system shutdown), each mounted ext2 file system on the machine must be checked for consistency by the e2fsck program. This is a time-consuming process that can delay system boot time significantly, especially with large volumes containing a large number of files. During this time, any data on the volumes is unreachable.

The journaling provided by the ext3 file system means that this sort of file system check is no longer necessary after an unclean system shutdown. The only time a consistency check occurs using ext3 is in certain rare hardware-failure cases, such as hard-drive failures. The time to recover an ext3 file system after an unclean system shutdown does not depend on the size of the file system or the number of files; rather, it depends on the size of the journal used to maintain consistency. The default journal size takes about a second to recover, depending on the speed of the hardware.

Data Integrity

The ext3 file system provides stronger data integrity in the event that an unclean system shutdown occurs. The ext3 file system allows you to choose the type and level of protection that your data receives. By default, Red Hat Linux 8.0 configures ext3 volumes to keep a high level of data consistency with regard to the state of the file system.

Speed

Despite writing some data more than once, ext3 has a higher throughput in most cases than ext2 because ext3’s journaling optimizes hard-drive head motion. You can choose from three journaling modes to optimize speed, but doing so means tradeoffs with regard to data integrity.

Easy Transition

It is easy to change from ext2 to ext3 and gain the benefits of a robust journaling file system without reformatting. See the “Converting to an Ext3 File System” section of this chapter for more on how to perform this task. If you perform a fresh installation of Red Hat Linux 8.0, the default file system assigned to the system’s Linux partitions is ext3. If you upgrade from a version of Red Hat Linux that uses ext2 partitions, the installation program allows you to convert these partitions to ext3 partitions without losing data. See the section “Converting to an Ext3 File System.”

The following sections walk you through the steps for creating and tuning ext3 partitions. If you have ext2 partitions and are running Red Hat Linux 8.0, you can skip the partitioning and formatting sections below and go directly to the next section.

Creating an Ext3 File System

After installation, it is sometimes necessary to create a new ext3 file system. For example, if you add a new disk drive to a Red Hat Linux system, you may want to partition the drive and use the ext3 file system. The steps for creating an ext3 file system are as follows:

  1. Create the partition using parted or fdisk.

  2. Format the partition with the ext3 file system using mkfs.

  3. Label the partition using e2label.

  4. Create the mount point.

  5. Add the partition to /etc/fstab.

    Cross-Reference

    Refer to Appendix A for information on performing these steps.

Converting to an Ext3 File System

The tune2fs program can add a journal to an existing ext2 file system without altering the data already on the partition. If the file system is already mounted while it is being transitioned, the journal will be visible as the file .journal in the root directory of the file system. If the file system is not mounted, the journal will be hidden and will not appear in the file system at all.

To convert an ext2 file system to ext3, log in as root and type:

/sbin/tune2fs -j /dev/hdbX

In the above command, replace /dev/hdb with the device name and X with the partition number. After doing this, be certain to change the partition type from ext2 to ext3 in /etc/fstab. If you are transitioning your root file system, you will have to use an initrd image (or RAM disk) to boot. To create this, run the mkinitrd program. For information on using the mkinitrd command, type man mkinitrd. Also make sure your GRUB or LILO configuration loads the initrd image. If you fail to make this change, the system will still boot, but the file system will be mounted as ext2 instead of ext3.

Reverting to an Ext2 File System

Because ext3 is relatively new, some disk utilities do not yet support it. For example, you may need to shrink a partition with resize2fs, which does not yet support ext3. In this situation, it may be necessary to temporarily revert a file system to ext2. To revert a partition, you must first unmount the partition by logging in as root and typing:

umount /dev/hdbX

In the above command, replace /dev/hdb with the device name and X with the partition number. For the remainder of this section, the sample commands will use hdb1 for these values. Next, change the file system type to ext2 by typing the following command as root:

/sbin/tune2fs -O ^has_journal /dev/hdb1

Check the partition for errors by typing the following command as root:

/sbin/e2fsck -y /dev/hdb1

Then mount the partition again as an ext2 file system by typing:

mount -t ext2 /dev/hdb1 /mount/point

In the above command, replace /mount/point with the mount point of the partition. Next, remove the .journal file at the root level of the partition by changing to the directory where it is mounted and typing:

rm -f .journal

You now have an ext2 partition. If you permanently change the partition to ext2, remember to update the /etc/fstab file.


/proc

The Linux kernel has two primary functions: to control access to physical devices on the computer and to schedule when and how processes interact with these devices. The /proc/ directory contains a hierarchy of special files that represent the current state of the kernel — allowing applications and users to peer into the kernel’s view of the system.

Within the /proc/ directory, one can find a wealth of information about the system hardware and any processes currently running. In addition, some of the files within the /proc/ directory tree can be manipulated by users and applications to communicate configuration changes to the kernel.

A Virtual File System

Under Linux, all data is stored as files. Most users are familiar with the two primary types of files: text and binary. But the /proc/ directory contains another type of file called a virtual file. It is for this reason that /proc/ is often referred to as a virtual file system.

These virtual files have unique qualities. Most of them are listed as zero bytes in size and yet when one is viewed, it can contain a large amount of information. In addition, most of the time and date settings on virtual files reflect the current time and date, indicative of the fact they constantly changing.

Virtual files such as interrupts, /proc/meminfo, /proc/mounts, and /proc/partitions provide an up-to-the-moment glimpse of the system’s hardware. Others, like /proc/file systems and the /proc/sys/ directory, provide system configuration information and interfaces. For organizational purposes, files containing information on a similar topic are grouped into virtual directories and sub-directories. For instance, /proc/ide/ contains information for all physical IDE devices. Likewise, process directories contain information about each running process on the system.

Viewing Virtual Files

By using the cat, more, or less commands on files within the /proc/ directory, you can immediately access an enormous amount of information about the system. For example, if you want to see what sort of CPU your computer has, type cat /proc/cpuinfo and you will see something similar to the following:

processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model    : 9
model name : AMD-K6(tm) 3D+ Processor
stepping : 1
cpu MHz     : 400.919
cache size : 256 KB
fdiv_bug : no
hlt_bug     : no
f00f_bug : no
coma_bug : no
fpu    : yes
fpu_exception : yes
cpuid level : 1
wp     : yes
flags    : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr
bogomips : 799.53

When viewing different virtual files in the /proc/ file system, you will notice that some of the information is easily understandable while some is not human-readable. This is in part why utilities exist to pull data from virtual files and display it in a useful way. Some examples of such applications are lspci, apm, free, and top.

Note

Some of the virtual files in the /proc/ directory are readable by the root user only.

Changing Virtual Files

As a general rule, most virtual files within the /proc/ directory are read-only. However, some can be used to adjust settings in the kernel. This is especially true for files in the /proc/sys/ subdirectory. To change the value of a virtual file, use the echo command and a > symbol to redirect the new value to the file. For instance, to change your hostname on the fly, you can type:

echo bob.subgenius.com > /proc/sys/kernel/hostname

Other files act as binary or boolean switches. For instance, if you type cat /proc/sys/net/ipv4/ip_forward, you will see either a 0 or a 1. A 0 indicates that the kernel is not forwarding network packets. By using the echo command to change the value of the ip_forward file to 1, you can immediately turn packet forwarding on.

Tip

Another command used to alter settings in the /proc/sys/ subdirectory is /sbin/sysctl.

For a listing of some of the kernel configuration files available in /proc/sys/, see the “/proc/sys” section later in this chapter.


Top-level Files in the proc File System

Following is a list of some of the more useful virtual files in the top level of the /proc/ directory.

Note

In most cases, the content of files listed in this section will not be the same on your machine. This is because much of the information pertains to the hardware on which you are running Red Hat Linux.

/proc/apm

This file provides information about the state of the Advanced Power Management (APM) system and is used by the apm command. If the system with no battery is connected to an AC power source, this virtual file looks similar to this:

1.16 1.2 0x07 0x01 0xff 0x80 -1% -1 ?

Running the apm -v command on such a system results in output similar to this:

APM BIOS 1.2 (kernel driver 1.16)
AC on-line, no system battery

For systems that do not use a battery as a power source, apm is able do little more than put the machine in standby mode. The apm command is much more useful on laptops. For example, the following output is from the command cat /proc/apm on a laptop running Red Hat Linux while plugged into a power outlet:

1.16 1.2 0x03 0x01 0x03 0x09 100% -1 ?

When the same laptop is unplugged from its power source for a few minutes, the contents of the apm file change to something like this:

1.16 1.2 0x03 0x00 0x00 0x01 99% 1792 min

The apm -v command will now yield more useful data, such as the following:

APM BIOS 1.2 (kernel driver 1.16)
AC off-line, battery status high: 99% (1 day, 5:52)

/proc/cmdline

This file shows the parameters passed to the kernel at the time it is started. A sample /proc/cmdline file looks like this:

ro root=/dev/hda2

This tells us the kernel is mounted read-only — signified by ro — off of the second partition on the first IDE device (/dev/hda2).

/proc/cpuinfo

This virtual file identifies the type of processor used by your system. The following is an example of the output you’ll typically see from /proc/cpuinfo:

processor               : 0
vendor_id               : AuthenticAMD
cpu family              : 5
model                   : 9
model name              : AMD-K6(tm) 3D+ Processor
stepping                : 1
cpu MHz                 : 400.919
cache size              : 256 KB
fdiv_bug                : no
hlt_bug                 : no
f00f_bug                : no
coma_bug                : no
fpu                     : yes
fpu_exception           : yes
cpuid level             : 1
wp                      : yes
flags                   : fpu vme de pse tsc msr mce cx8 pge mmx syscall  \
 3dnow k6_mtrr
bogomips                : 799.53

  • processor — Provides each processor with an identifying number. If you have only one processor, you will see only a 0.

  • cpu family — Authoritatively tells you the type of processor you have in the system. If your computer is an Intel-based system, simply place the number in front of “86” to determine the value. This is particularly helpful if you are wondering about the architecture of an older system such as the 586, 486, or 386. Because some RPM packages are compiled for each of these particular architectures, this value enables you determine which package to install.

  • model name — Gives you the common name of the processor, including its project name.

  • cpu MHz — Shows the processor’s precise speed, in megahertz, to the thousandth decimal point.

  • cache size — Tells you the amount of level 2 memory cache available to the processor.

  • flags — Defines a number of different processor attributes, such as the presence of a floating-point unit (FPU) and the ability to process MMX instructions.

/proc/devices

This file displays the various character and block devices currently configured for use with the kernel. It does not include devices whose modules are not loaded into the kernel. Following is a sample output from this virtual file:

Character devices:
      1 mem
      2 pty
      3 ttyp
      4 ttyS
      5 cua
      7 vcs
     10 misc
     14 sound
     29 fb
     36 netlink
    128 ptm
    129 ptm
    136 pts
    137 pts
    162 raw
    254 iscsictl
Block devices:
      1 ramdisk
      2 fd
      3 ide0
      9 md
     22 ide1

The output from /proc/devices includes the major number and name of the device and is broken into two major sections: character devices and block devices. Character devices are similar to block devices, except for two basic differences.

Block devices have a buffer available, allowing them to order requests before dealing with them. This is important for devices designed to store information — such as hard drives — because the ability to order the information before writing it to the device allows it to be placed in more efficient order. Character devices do not require buffering.

The other difference is that block devices can send and receive information in blocks of a size configured per device. Character devices send data with no preconfigured size. For more information about devices see /usr/src/linux-2.4/Documentation/devices.txt.

/proc/dma

This file contains a list of the registered ISA direct memory access (DMA) channels in use. A sample /proc/dma file looks like this:

4: cascade

/proc/execdomains

This file lists the execution domains currently supported by the Linux kernel, along with the range of personalities they support.

0-0      Linux                 [kernel]

Think of execution domains as the “personality” for a particular operating system. Because other binary formats, such as Solaris, UnixWare, and FreeBSD, can be used with Linux, programmers can change the way the operating system treats particular system calls from these binaries by changing the personality of the task. Except for the PER_LINUX execution domain, different personalities can be implemented as dynamically loadable modules.

/proc/fb

This file contains a list of frame buffer devices, with the frame buffer device number and the driver that controls it. Typical output of /proc/fb for systems that contain frame buffer devices looks similar to this:

0 VESA VGA

/proc/

This file displays a list of the file system types currently supported by the kernel. Sample output from a generic kernel’s /proc/filesystems file looks similar to this:

nodev          rootfs
nodev          bdev
nodev          proc
nodev          sockfs
nodev          tmpfs
nodev          shm
nodev          pipefs
               ext2
nodev          ramfs
               iso9660
nodev          devpts
               ext3
nodev          autofs
nodev          binfmt_misc

The first column signifies whether the file system is mounted on a block device. Those beginning with nodev are not mounted on a device. The second column lists the name of the file systems supported. The mount command cycles through these file systems when one is not specified as an argument.

/proc/interrupts

This file records the number of interrupts per IRQ on the x86 architecture. A standard /proc/interrupts file looks similar to this:

          CPU0
  0:    80448940               XT-PIC     timer
  1:      174412               XT-PIC     keyboard
  2:           0               XT-PIC     cascade
  8:           1               XT-PIC     rtc
 10:      410964               XT-PIC     eth0
 12:       60330               XT-PIC     PS/2 Mouse
 14:     1314121               XT-PIC     ide0
 15:     5195422               XT-PIC     ide1
NMI:           0
ERR:           0

For a multi-processor machine, this file may look slightly different:

        CPU0        CPU1
 0:  1366814704       0      XT-PIC    timer
 1:         128     340      IO-APIC-edge      keyboard
 2:           0       0      XT-PIC    cascade
 8            0       1      IO-APIC-edge      rtc
12:        5323    5793      IO-APIC-edge      PS/2 Mouse
13:           1       0      XT-PIC    fpu
16:    11184294  15940594    IO-APIC-level Intel \
     EtherExpress \ Pro 10/100 Ethernet
20:     8450043  11120093    IO-APIC-level megaraid
30:       10432     10722    IO-APIC-level aic7xxx
31:          23        22    IO-APIC-level aic7xxx
NMI:  0
ERR:  0

The first column refers to the IRQ number. Each CPU in the system has its own column and its own number of interrupts per IRQ. The next column reports the type of interrupt, and the last column contains the name of the device that is located at that IRQ. Each of the types of interrupts seen in this file, which are architecture-specific, means something a little different. For x86 machines, the following values are common:

  • XT-PIC — This is the old AT computer interrupts.

  • IO-APIC-edge — The voltage signal on this interrupt transitions from low to high, creating an edge where the interrupt occurs, and is signaled only once. This kind of interrupt, as well as the IO-APIC-level interrupt, is seen only on systems with processors from the 586 family and higher.

  • IO-APIC-level — Generates interrupts when its voltage signal goes high until the signal goes low again.

/proc/iomem

This file shows you the current map of the system’s memory for each physical device:

00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-07ffffff : System RAM
  00100000-00291ba8 : Kernel code
  00291ba9-002e09cb : Kernel data
e0000000-e3ffffff : VIA Technologies, Inc. VT82C597 [Apollo VP3]
e4000000-e7ffffff : PCI Bus #01
  e4000000-e4003fff : Matrox Graphics, Inc. MGA G200 AGP
  e5000000-e57fffff : Matrox Graphics, Inc. MGA G200 AGP
e8000000-e8ffffff : PCI Bus #01
  e8000000-e8ffffff : Matrox Graphics, Inc. MGA G200 AGP
ea000000-ea00007f : Digital Equipment Corporation DECchip 21140 [FasterNet]
  ea000000-ea00007f : tulip
ffff0000-ffffffff : reserved

The first column displays the memory registers used by each of the different types of memory. The second column tells the kind of memory located within those registers. In particular, this column tells you which memory registers are used by the kernel within the system RAM or, if you have multiple Ethernet ports on your NIC, the memory registers assigned for each port.

/proc/ioports

The output of /proc/ioports provides a list of currently registered port regions used for input or output communication with a device. This file can be quite long, with a beginning similar to this:

0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial(auto)
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf1
d000-dfff : PCI Bus #01
e000-e00f : VIA Technologies, Inc. Bus Master IDE
  e000-e007 : ide0
  e008-e00f : ide1
e800-e87f : Digital Equipment Corporation DECchip 21140 [FasterNet]
  e800-e87f : tulip

The first column gives the IO port address range reserved for the device listed in the second column.

/proc/isapnp

This file lists Plug and Play (PnP) cards in ISA slots on the system. This is most often seen with sound cards but may include any number of devices. A /proc/isapnp file containing a Soundblaster entry looks similar to this:

Card 1 'CTL0070:Creative ViBRA16C PnP' PnP version 1.0 Product version 1.0
    Logical device 0 'CTL0001:Audio'
     Device is not active
     Active port 0x220,0x330,0x388
     Active IRQ 5 [0x2]
     Active DMA 1,5
     Resources 0
        Priority preferred
        Port 0x220-0x220, align 0x0, size 0x10, 16-bit address decoding
        Port 0x330-0x330, align 0x0, size 0x2, 16-bit address decoding
        Port 0x388-0x3f8, align 0x0, size 0x4, 16-bit address decoding
        IRQ 5 High-Edge
        DMA 1 8-bit byte-count compatible
        DMA 5 16-bit word-count compatible
        Alternate resources 0:1
           Priority acceptable
           Port 0x220-0x280, align 0x1f, size 0x10, 16-bit address decoding
           Port 0x300-0x330, align 0x2f, size 0x2, 16-bit address decoding
           Port 0x388-0x3f8, align 0x0, size 0x4, 16-bit address decoding
           IRQ 5,7,2/9,10 High-Edge
           DMA 1,3 8-bit byte-count compatible
           DMA 5,7 16-bit word-count compatible

This file can be quite long, depending on the number of devices displayed and their resource requirements. Each card lists its name, PnP version number, and product version number. If the device is active and configured, this file will also reveal the port and IRQ numbers for the device. In addition, to ensure better compatibility, the card will specify preferred and acceptable values for a number of different parameters. The goal here is to allow the PnP cards to work around one another and avoid IRQ and port conflicts.

/proc/kcore

This file represents the physical memory of the system and is stored in the core file format. Unlike most /proc/ files, kcore displays a size. This value is given in bytes and is equal to the size of physical memory (RAM) used plus 4KB. The contents of this file are designed to be examined by a debugger, such as gdb; they are not human-readable.

Warning

Do not view the /proc/kcore virtual file. The contents of the file will scramble text output on the terminal. If you accidentally view this file, press Ctrl-C to stop the process, then type reset to bring back the command-line prompt.

/proc/kmsg

This file is used to hold messages generated by the kernel. These messages are then picked up by other programs, such as /sbin/klogd.

/proc/ksyms

This file holds the kernel-exported symbol definitions used by the module tools to dynamically link and bind loadable modules.

e003def4 speedo_debug [eepro100]
e003b04c eepro100_init [eepro100]
e00390c0 st_template [st]
e002104c RDINDOOR [megaraid]
e00210a4 callDone [megaraid]
e00226cc megaraid_detect [megaraid]

The first column lists the memory address for the kernel function, the second column refers to the name of the function, and the last column reveals the name of the loaded module.

/proc/loadavg

This file provides a look at load average on the processor over time and additional data used by uptime and other commands. A sample /proc/loadavg file looks similar to this:

0.20 0.18 0.12 1/80 11206

The first three entries measure CPU utilization of the last 1-, 5-, and 10-minute periods. The fourth column shows the number of currently running processes and the total number of processes. The last column displays the last process ID used.

/proc/locks

This file displays the files currently locked by the kernel. The content of this file contains internal kernel debugging data and can vary tremendously, depending on the use of the system. A sample /proc/locks file for a lightly loaded system looks similar to this:

1: FLOCK  ADVISORY  WRITE 807 03:05:308731 0 EOF c2a260c0 c025aa48 c2a26120
2: POSIX  ADVISORY  WRITE 708 03:05:308720 0 EOF c2a2611c c2a260c4 c025aa48

Each lock has its own line that starts with a unique number. The second column refers to the class of lock used, with FLOCK signifying the older-style UNIX file locks from a flock system call and POSIX representing the newer POSIX locks from the lockf system call. The third column can have two values. ADVISORY means that the lock does not prevent other people from accessing the data; it prevents only other attempts to lock it. MANDATORY means that no other access to the data is permitted while the lock is held. The fourth column reveals whether the lock is allowing the holder READ or WRITE access to the file, and the fifth column shows the ID of the process holding the lock. The sixth column shows the ID of the file being locked, in the format of MAJOR-DEVICE:MINOR-DEVICE:INODE-NUMBER. The seventh column shows the start and end of the file’s locked region. The remaining columns point to internal kernel data structures used for specialized debugging and can be ignored.

/proc/mdstat

This file contains the current information for multiple-disk RAID configurations. If your system does not contain such a configuration, then your /proc/mdstat file will look similar to this:

Personalities :
read_ahead not set
unused devices: none

This file remains in the state above unless you create a software RAID or md device. In that case, you can view /proc/mdstat to give you a picture of what is currently happening with your mdX RAID devices. The /proc/mdstat file below shows a system with its md0 configured as a RAID 1 device. It is currently re-syncing the disks:

Personalities : [linear] [raid1]
read_ahead 1024 sectors
md0: active raid1 sda2[1] sdb2[0] 9940 blocks [2/2] [UU] resync=1% \ finish=12.3min
algorithm 2 [3/3] [UUU]
unused devices: none

/proc/meminfo

This is one of the more commonly used files in the /proc/ directory, as it reports back plenty of valuable information about the current RAM usage on the system. A system with 256MB of RAM and 384MB of swap space will likely have a /proc/meminfo file similar to this one:

         total:    used:   free:  shared:   buffers:  cached:
Mem:   261709824 253407232 8302592     0   120745984 48689152
Swap:  402997248    8192 402989056
MemTotal:         255576 kB
MemFree:            8108 kB
MemShared:             0 kB
Buffers:          117916 kB
Cached:            47548 kB
Active:           135300 kB
Inact_dirty:       29276 kB
Inact_clean:         888 kB
Inact_target:          0 kB
HighTotal:             0 kB
HighFree:              0 kB
LowTotal:         255576 kB
LowFree:            8108 kB
SwapTotal:        393552 kB
SwapFree:         393544 kB

Much of the information here is used by the free, top, and ps commands. In fact, the output of the free command is even similar in appearance to the contents and structure of /proc/meminfo. But looking directly at /proc/meminfo reveals more details:

  • Mem — Displays the current state of physical RAM in the system, including a full breakdown of total, used, free, shared, buffered, and cached memory utilization in bytes.

  • Swap — Displays the total, used, and free amounts of swap space, in bytes.

  • MemTotal — Total amount of physical RAM, in kilobytes.

  • MemFree — The amount of physical RAM, in kilobytes, left unused by the system.

  • MemShared — Unused with 2.4 and later kernels but left in for compatibility with earlier kernel versions.

  • Buffers — The amount of physical RAM, in kilobytes, used for file buffers.

  • Cached — The amount of physical RAM, in kilobytes, used as cache memory.

  • Active — The total amount of buffer or page cache memory, in kilobytes, that is in active use.

  • Inact_dirty — The total amount of buffer or cache pages, in kilobytes, that might be free and available.

  • Inact_clean — The total amount of buffer or cache pages in kilobytes that are definitely free and available.

  • Inact_target — The net amount of allocations per second, in kilobytes, averaged over one minute.

  • HighTotal and HighFree — The total and free amount of memory, respectively, that is not directly mapped into kernel space. The HighTotal value can vary based on the type of kernel used.

  • LowTotal and LowFree — The total and free amount of memory, respectively, that is directly mapped into kernel space. The LowTotal value can vary based on the type of kernel used.

  • SwapTotal — The total amount of swap available, in kilobytes.

  • SwapFree — The total amount of swap free, in kilobytes.

/proc/misc

This file lists miscellaneous drivers registered on the miscellaneous major device, which is device number 10:

135 rtc
  1 psaux
134 apm_bios

The first column is the minor number of each device, and the second column shows the driver in use.

/proc/modules

This file displays a list of all modules loaded into the kernel. Its contents will vary based on the configuration and use of your system, but it should be organized in a similar manner to this sample /proc/modules file output:

ide-cd                       27008     0 (autoclean)
cdrom                        28960     0 (autoclean) [ide-cd]
soundcore                     4100     0 (autoclean)
agpgart                      31072     0 (unused)
binfmt_misc                   5956     1
iscsi                        32672     0 (unused)
scsi_mod                     94424     1 [iscsi]
autofs                       10628     0 (autoclean) (unused)
tulip                        48608     1
ext3                         60352     2
jbd                          39192     2 [ext3]

The first column contains the name of the module. The second column refers to the memory size of the module, in bytes. The third column tells you whether the module is currently loaded (1) or unloaded (0). The final column states if the module can unload itself automatically after a period without use (autoclean) or if it is not being utilized (unused). Any module with a line containing a name listed in brackets ([ and ]) tells you that this module depends upon another module’s presence in order to function.

/proc/mounts

This file provides a quick list of all mounts in use by the system:

rootfs / rootfs rw 0 0
/dev/hda2 / ext3 rw 0 0
/proc /proc proc rw 0 0
/dev/hda1 /boot ext3 rw 0 0
none /dev/pts devpts rw 0 0
none /dev/shm tmpfs rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0

The output found here is similar to the contents of /etc/mtab, except that /proc/mount can be more current. The first column specifies the device that is mounted, with the second column revealing the mount point. The third column tells the file system type, and the fourth column tells you if it is mounted read-only (ro) or read-write (rw). The fifth and sixth columns contain dummy values designed to match the format used in /etc/mtab.

/proc/mtrr

This file refers to the current Memory Type Range Registers (MTRRs) in use with the system. If your system’s architecture supports MTRRs, your mtrr might look something like this:

reg00: base=0x00000000 > 0MB), size=       64MB: write-back, count=1

MTRRs are used with the Intel P6 family of processors (Pentium II and higher), and they are used to control processor access to memory ranges. When using a video card on a PCI or AGP bus, a properly configured /proc/mtrr file can increase performance by more than 150 percent. Most of the time, this value is properly configured for you. For more information on MTRRs and manually configuring this file, please see http://web1.linuxhq.com/kernel/v2.3/doc/mtrr.txt.html.

/proc/partitions

Most of the information here is of little importance to the user, except for the following columns:

  • major — The major number of the device with this partition. The major number corresponds with the block device ide0 in /proc/devices.

  • minor — The minor number of the device with this partition. This serves to separate the partitions into different physical devices and relates to the number at the end of the name of the partition.

  • #blocks — Lists the number of physical disk blocks contained in a particular partition.

  • name — The name of the partition.

/proc/pci

This file contains a full listing of every PCI device on your system. Depending on the number of PCI devices you have, /proc/pci can get rather long. An example from this file on a basic system looks similar to this:

  Bus      0, device     0, function       0:
   Host bridge:Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 3).
           Master Capable.        Latency=64.
           Prefetchable 32 bit memory at 0xe4000000 [0xe7ffffff].
  Bus      0, device     1, function       0:
   PCI bridge:Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 3).
           Master Capable.        Latency=64.    Min Gnt=128.
  Bus      0, device     4, function       0:
   ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2).
  Bus      0, device     4, function       1:
   IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1).
           Master Capable.        Latency=32.
           I/O at 0xd800 [0xd80f].
  Bus      0, device     4, function       2:
   USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1).
           IRQ 5.
           Master Capable.        Latency=32.
           I/O at 0xd400 [0xd41f].
  Bus      0, device     4, function       3:
   Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 2).
           IRQ 9.
  Bus      0, device     9, function       0:
   Ethernet controller: Lite-On Communications Inc LNE100TX (rev 33).
           IRQ 5.
           Master Capable.        Latency=32.
           I/O at 0xd000 [0xd0ff].
           Non-prefetchable 32 bit memory at 0xe3000000 [0xe30000ff].
  Bus      0, device    12, function       0:
   VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 1).
           IRQ 11.
           Master Capable.        Latency=32.    Min Gnt=4.Max Lat=255.
           Non-prefetchable 32 bit memory at 0xdc000000 [0xdfffffff].

This output shows a list of all PCI devices, sorted in the order of bus, device, and function. Beyond providing the name and version of the device, this list also gives you detailed IRQ information so you can quickly look for conflicts.

Tip

To get a more readable version of this information, type lspci -vb.

/proc/slabinfo

This file gives information about memory usage on the slab level. Linux kernels later than 2.2 use slab pools to manage memory above the page level. Commonly used objects have their own slab pools. The following is a portion of a typical /proc/slabinfo virtual file:

slabinfo - version: 1.1
kmem_cache                    64       68     112      2     2      1
nfs_write_data                 0        0     384      0     0      1
nfs_read_data                  0      160     384      0    16     1
nfs_page                        0     200       96     0     5      1
ip_fib_hash                   10      113       32     1     1      1
journal_head                  51     7020       48     2    90     1
revoke_table                   2      253       12     1     1      1
revoke_record                  0        0       32     0     0      1
clip_arp_cache                 0        0     128      0     0      1
ip_mrt_cache                   0        0       96     0     0      1

The values in this file occur in the following order: cache name, number of active objects, number of total objects, size of the object, number of active slabs (blocks) of the objects, total number of slabs of the objects, and the number of pages per slab. Note that active in this case means that an object is in use. Therefore an active object is one that is in use, and an active slab is one that contains one or more active objects.

/proc/stat

This file keeps track of a variety of different statistics about the system since it was last restarted. The content of /proc/stat, which can be quite long, begins something like this:

cpu       1139111 3689 234449 84378914
cpu0 1139111 3689 234449 84378914
page 2675248 8567956
swap 10022 19226
intr 93326523 85756163 174412 0 3 3 0 6 0 1 0 428620 0 60330 0 1368304 \ 5538681
disk_io: (3,0):(1408049,445601,5349480,962448,17135856)
ctxt 27269477
btime 886490134
processes 206458

Some of the more popular statistics include:

  • cpu — Measures the number of jiffies (1/100 of a second) that the system has been in user mode, user mode with low priority (nice), system mode, and the idle task, respectively. The total for all CPUs is given at the top, and each individual CPU is listed below with its own statistics.

  • page — The number of memory pages the system has written in and out to disk.

  • swap — The number of swap pages the system has brought in and out.

  • intr — The number of interrupts the system has experienced.

  • btime — The boot time, measured in the number of seconds since January 1, 1970, otherwise known as the epoch.

/proc/swaps

This file measures swap space and its utilization. For a system with only one swap partition, the output of /proc/swap may look similar to this:

Filename        Type           Size       Used     Priority
/dev/hda6       partition      136512     20024    -1

While some of this information can be found in other files in the /proc/ directory, /proc/swap provides a snapshot of every swap file name, type of swap space, the total size, and the amount of this space that is in use (in kilobytes). The priority column is useful when multiple swap files are in use. The lower the priority, the more likely the swap file is to be used.

/proc/uptime

This file contains information about how long the system has on since its last restart. The output of /proc/uptime is quite minimal:

350735.47 234388.90

The first number tells you the total number of seconds the system has been up. The second number tells you how much of that time the machine has spent idle in seconds.

/proc/version

This files tells you the versions of the Linux kernel and gcc, as well as the version of Red Hat Linux installed on the system:

Linux version 2.4.18-0.40 (user@foo.redhat.com)(gcc version 2.96 20000731
(Red Hat Linux 7.2 2.96-102)) #1 Tue May 28 04:28:05 EDT 2002

This information is used for a variety of purposes, including the version data presented when a user logs in.


Directories in /proc/

Common groups of information concerning the kernel are grouped into directories and subdirectories within the /proc/ directory.

Process Directories

Every /proc/ directory contains a number of directories and their numerical names. A listing of them may start off like this:

dr-xr-xr-x    3 root        root         0 Feb 13 01:28 1
dr-xr-xr-x    3 root        root         0 Feb 13 01:28 1010
dr-xr-xr-x    3 xfs         xfs          0 Feb 13 01:28 1087
dr-xr-xr-x    3 daemon      daemon       0 Feb 13 01:28 1123
dr-xr-xr-x    3 root        root         0 Feb 13 01:28 11307
dr-xr-xr-x    3 apache      apache       0 Feb 13 01:28 13660
dr-xr-xr-x    3 rpc         rpc          0 Feb 13 01:28 637
dr-xr-xr-x    3 rpcuser     rpcuser      0 Feb 13 01:28 666

These directories are called process directories, as they are named after a program’s process ID and contain information specific to that process. The owner and group of each process directory is set to the user running the process. When the process is terminated, its /proc/ process directory vanishes. Each process directory contains the following files.

This file contains the command issued when starting the process.

Provides specific information about the utilization of each of the system’s CPUs. A process running on a dual-CPU system produces output similar to this:

cpu    11 3
cpu0    0 0
cpu1   11 3

A symlink to the current working directory for the process.

Gives a list of the environment variables for the process. The environment variable is given in all uppercase characters, and the value is in lowercase characters.

A symlink to the executable of this process.

A directory containing all of the file descriptors for a particular process. These are given in numbered links:

total 0
lrwx------   1 root  root  64 May   8 11:31 0 -> /dev/null
lrwx------   1 root  root  64 May   8 11:31 1 -> /dev/null
lrwx------   1 root  root  64 May   8 11:31 2 -> /dev/null
lrwx------   1 root  root  64 May   8 11:31 3 -> /dev/ptmx
lrwx------   1 root  root  64 May   8 11:31  4 -> socket:[7774817]
lrwx------   1 root  root  64 May   8 11:31 5 -> /dev/ptmx
lrwx------   1 root  root  64 May   8 11:31 6 -> socket:[7774829]
lrwx------   1 root  root  64 May   8 11:31 7 -> /dev/ptmx

Contains memory maps to the various executables and library files associated with this process. This file can be rather long, depending upon the complexity of the process. Sample output from the sshd process begins like this:

08048000-08086000 r-xp 00000000 03:03 391479          /usr/sbin/sshd
08086000-08088000 rw-p 0003e000 03:03 391479          /usr/sbin/sshd
08088000-08095000 rwxp 00000000 00:00 0
40000000-40013000 r-xp 00000000 03:03 293205         lib/ld-2.2.5.so
40013000-40014000 rw-p 00013000 03:03 293205         /lib/ld-2.2.5.so
40031000-40038000 r-xp 00000000 03:03 293282         /lib/libpam.so.0.75
40038000-40039000 rw-p 00006000 03:03 293282         /lib/libpam.so.0.75
40039000-4003a000 rw-p 00000000 00:00 0
4003a000-4003c000 r-xp 00000000 03:03 293218         /lib/libdl-2.2.5.so
4003c000-4003d000 rw-p 00001000 03:03 293218         /lib/libdl-2.2.5.so

The memory held by the process. This file cannot be read by the user.

A link to the root directory of the process.

The status of the process.

The status of the memory in use by the process. Following is a sample /proc/statm file:

      263 210 210 5 0 205 0

The seven columns relate to different memory statistics for the process. From left to right, they report the following aspects of the memory used:

  1. Total program size, in kilobytes

  2. Size of memory portions, in kilobytes

  3. Number of pages that are shared

  4. Number of pages that are code

  5. Number of pages of data/stack

  6. Number of pages that are libraries

  7. Number of dirty pages

The status of the process in a more readable form than stat or statm. Sample output for sshd looks similar to this:

Name: sshd
State: S (sleeping)
Tgid: 797
Pid: 797
PPid: 1
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 32
Groups:
VmSize:         3072 kB
VmLck:             0 kB
VmRSS:          840 kB
VmData:           104 kB
VmStk:            12 kB
VmExe:          300 kB
VmLib:         2528 kB
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 8000000000001000
SigCgt: 0000000000014005
CapInh: 0000000000000000
CapPrm: 00000000fffffeff
CapEff: 00000000fffffeff

Other than the process’s name and ID, the state (such as S (sleeping) or R (running) and user/group ID running the process are available, as well as much more detailed data regarding memory usage.

/proc/self/

The /proc/self/ directory is a link to the currently running process. This allows a process to look at itself without having to know its process ID. Within a shell environment, a listing of the /proc/self/ directory produces the same contents as listing the process directory for that process.

/proc/bus/

This directory contains information specific to the various buses available on the system. So, for example, on a standard system containing ISA, PCI, and USB buses, current data on each of these buses is available in its directory under /proc/bus/. The contents of the subdirectories and files available vary greatly on the precise configuration of your system. However, each of the directories for each of the bus types has at least one directory for each bus of that type. These individual bus directories, usually signified with numbers, such as 00, contain binary files that refer to the various devices available on that bus.

So, for example, a system with a USB bus but no USB devices connected to it has a /proc/bus/usb/ directory containing several files:

total 0
dr-xr-xr-x    1 root     root       0 May     3 16:25 001
-r--r--r--    1 root     root       0 May     3 16:25 devices
-r--r--r--    1 root     root       0 May     3 16:25 drivers

The /proc/bus/usb/ directory contains files that track the various devices on any USB buses, as well as the drivers required to use them. The /proc/bus/usb/001/ directory contains all devices on the first USB bus. By looking at the contents of the devices file, you can identify the USB root hub on the motherboard:

T:     Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=       1 Spd=12    MxCh= 2
B:     Alloc=     0/900 us > 0%), #Int=       0, #Iso=     0
D:     Ver= 1.00 Cls=09(hub    ) Sub=00 Prot=00 MxPS= 8 #Cfgs=            1
P:     Vendor=0000 ProdID=0000 Rev= 0.00
S:     Product=USB UHCI Root Hub
S:     SerialNumber=d400
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=             0mA
I:     If#= 0 Alt= 0 #EPs= 1 Cls=09(hub         ) Sub=00 Prot=00 Driver=hub
E:     Ad=81(I) Atr=03(Int.) MxPS=           8 Ivl=255ms

/proc/driver/

This directory contains information for specific drivers in use by the kernel. A common file found here is rtc, which provides output from the driver for the system’s Real Time Clock (RTC), the device that keeps the time while the system is switched off. Sample output from /proc/driver/rtc looks like this:

rtc_time : 01:38:43
rtc_date : 1998-02-13
rtc_epoch : 1900
alarm    : 00:00:00
DST_enable : no
BCD     : yes
24hr     : yes
square_wave : no
alarm_IRQ : no
update_IRQ : no
periodic_IRQ : no
periodic_freq : 1024
batt_status : okay

For more information about the RTC, review /usr/src/linux-2.4/Documentation/rtc.txt.

/proc/fs

This directory shows which file systems are exported. If you are running an NFS server, you can type cat /proc/fs/nfs/exports to view the file systems being shared and the permissions granted for the those file systems. For more on sharing file system with NFS, see Chapter 20.

/proc/ide/

This directory holds information about IDE devices on the system. Each IDE channel is represented as a separate directory, such as /proc/ide/ide0 and /proc/ide/ide1. In addition, a drivers file is also available, providing the version number of the various drivers used on the IDE channels:

ide-cdrom version 4.59
ide-floppy version 0.97
ide-disk version 1.10

Many chipsets also provide an informational file in this directory that gives additional data concerning the drives connected through the the channels. For example, a generic Intel PIIX4 Ultra 33 chipset produces a /proc/ide/piix file that will tell you whether DMA or UDMA is enabled for the devices on the IDE channels:

Intel PIIX4 Ultra 33 Chipset.
--------- Primary Channel ------- Secondary Channel --------

              enabled                enabled
------------- drive0 ---- drive1 ---- drive0 ---- drive1 ---

DMA enabled:    yes         no          yes         no
UDMA enabled:   yes         no           no         no
UDMA enabled:    2           X            X          X
UDMA
DMA
PIO

Navigating into the directory for an IDE channel, such as ide0, provides additional information. The channel file provides the channel number, while the model tells you the bus type for the channel (such as pci).

The Device Directory

Within each IDE channel directory is a device directory. The name of the device directory corresponds to the drive letter in the /dev/ directory. For instance, the first IDE drive on ide0 would be hda.

Note

There is a symlink to each of these device directories in the /proc/ide/ directory.

Each device directory contains a collection of information and statistics. The contents of these directories vary according to the type of device connected. Some of the more useful files common to many devices are:

  • cache — The device’s cache.

  • capacity — The capacity of the device, in 512-byte blocks.

  • driver — The driver and version used to control the device.

  • geometry — The physical and logical geometry of the device.

  • media — The type of device, such as a disk.

  • model — The model name or number of the device.

  • settings — A collection of current parameters of the device. This file usually contains quite a bit of useful technical information. A sample settings file for a standard IDE hard disk looks similar to this:

    name               value    min     max        mode
----               -----    ---     ---        ----
bios_cyl            784      0     65535        rw
bios_head           255      0       255        rw
bios_sect            63      0        63        rw
breada_readahead      4      0       127        rw
bswap                 0      0         1         r
current_speed        66      0        69        rw
file_readahead        0      0   2097151        rw
ide_scsi              0      0         1        rw
init_speed           66      0        69        rw
io_32bit              0      0         3        rw
keepsettings          0      0         1        rw
lun                   0      0         7        rw
max_kb_per_request   64      1       127        rw
multcount             8      0         8        rw
nice1                 1      0         1        rw
nowerr                0      0         1        rw
number                0      0         3        rw
pio_mode         write-only  0       255         w
slow                  0      0         1        rw
unmaskirq             0      0         1        rw
using_dma             1      0         1        rw

/proc/irq/

This directory is used to set IRQ to CPU affinity, which allows you to connect a particular IRQ to only one CPU. Alternatively, you can exclude a CPU from handling any IRQs. Each IRQ has its own directory, allowing for individual configuration of each IRQ. The /proc/irq/prof_cpu_mask file is a bitmask that contains the default values for the smp_affinity file in the IRQ directory. The values in smp_affinity specify which CPUs handle that particular IRQ. /usr/src/linux-2.4/Documentation/filesystems/proc.txt contains more information.

/proc/net/

This directory provides a comprehensive look at various networking parameters and statistics. Each of the files covers a specific range of information related to networking on the system. Following is a partial listing of these virtual files:

  • arp — Contains the kernel’s ARP table. This file is particularly useful for connecting a hardware address to an IP address on a system.

  • atm — A directory containing files with various Asynchronous Transfer Mode (ATM) settings and statistics. This directory is primarily used with ATM networking and ADSL cards.

  • dev — Lists the various network devices configured on the system, complete with transmit and receive statistics. This file will quickly tell you the number of bytes each interface has sent and received, the number of packets inbound and outbound, the number of errors seen, the number of packets dropped, and more.

  • dev_mcast — Displays the various Layer2 multicast groups each device is listening to.

  • igmp — Lists the IP multicast addresses that this system joined.

  • ip_fwchains — If ipchains are in use, this virtual file reveals any current rule.

  • ip_fwnames — If ipchains are in use, this virtual file lists all firewall chain names.

  • ip_masquerade — Provides a table of masquerading information under ipchains.

  • ip_mr_cache — List of the multicast routing cache.

  • ip_mr_vif — List of multicast virtual interfaces.

  • netstat — Contains a broad yet detailed collection of networking statistics, including TCP time-outs, SYN cookies sent and received, and much more.

  • psched — List of global packet scheduler parameters.

  • raw — List of raw device statistics.

  • route — Displays the kernel’s routing table.

  • rt_cache — Contains the current routing cache.

  • snmp — List of Simple Network Management Protocol (SNMP) data for various networking protocols in use.

  • sockstat — Provides socket statistics.

  • tcp — Contains detailed TCP socket information.

  • tr_rif — The token ring RIF routing table.

  • udp — Contains detailed UDP socket information.

  • unix — Lists UNIX domain sockets currently in use.

  • wireless — Lists wireless interface data.

/proc/scsi/

This directory is analogous to the /proc/ide/ directory, only it is for connected SCSI devices. The primary file in this directory is /proc/scsi/scsi, which contains a list of every recognized SCSI device. From this listing, the type of devices, as well as the model name, vendor, SCSI channel and ID data, is available. For example, if a system contains a SCSI CD-ROM, tape drive, hard drives, and RAID controller, this file will look similar to this:

Attached devices:
Host: scsi1 Channel: 00 Id: 05 Lun: 00
  Vendor: NEC           Model: CD-ROM DRIVE:466 Rev: 1.06
  Type:      CD-ROM                ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 06 Lun: 00
  Vendor: ARCHIVE       Model: Python 04106-XXX Rev: 7350
  Type:      Sequential-Access     ANSI SCSI revision: 02
Host: scsi2 Channel: 00 Id: 06 Lun: 00
  Vendor: DELL          Model: 1x6 U2W SCSI BP    Rev: 5.35
  Type:      Processor             ANSI SCSI revision: 02
Host: scsi2 Channel: 02 Id: 00 Lun: 00
  Vendor: MegaRAID      Model: LD0 RAID5 34556R Rev: 1.01
  Type:      Direct-Access         ANSI SCSI revision: 02

Each SCSI driver used by the system has its own directory in /proc/scsi/, which contains files specific to each SCSI controller using that driver. So, for the example system above, aic7xxx and megaraid directories are present, as those two drivers are being utilized. The files in each of the directories typically contain IO address range, IRQ, and statistics for the particular SCSI controller using that driver. Each controller can report a different type and amount of information. The Adaptec AIC-7880 Ultra SCSI host adapter’s file in this example system produces the following output:

Adaptec AIC7xxx driver version: 5.1.20/3.2.4
Compile Options:
      TCQ Enabled By Default : Disabled
      AIC7XXX_PROC_STATS     : Enabled
      AIC7XXX_RESET_DELAY    : 5

Adapter Configuration:
     SCSI Adapter: Adaptec AIC-7880 Ultra SCSI host adapter
     Ultra Narrow Controller  PCI MMAPed I/O Base: 0xfcffe000
 Adapter SEEPROM Config: SEEPROM found and used.
          Adaptec SCSI BIOS: Enabled
                            IRQ: 30
           SCBs: Active 0, Max Active 1, Allocated 15,
                  HW 16, Page 255
                  Interrupts: 33726
          BIOS Control Word: 0x18a6
      Adapter Control Word: 0x1c5f
      Extended Translation: Enabled
Disconnect Enable Flags: 0x00ff
        Ultra Enable Flags: 0x0020
 Tag Queue Enable Flags: 0x0000
Ordered Queue Tag Flags: 0x0000
Default Tag Queue Depth: 8
    Tagged Queue By Device array for aic7xxx host instance 1:
          {255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255}
   Actual queue depth per device for aic7xxx host instance 1:
          {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}

Statistics:

(scsi1:0:5:0)
   Device using Narrow/Sync transfers at 20.0 MByte/sec, offset 15
      Transinfo settings: current(12/15/0/0), goal(12/15/0/0), user(12/15/0/0)
      Total transfers 0 (0 reads and 0 writes)
      < 2K     2K+    4K+   8K+   16K+    32K+   64K+   128K+
Reads:   0      0      0     0     0       0      0       0
Writes:  0      0      0     0     0       0      0       0

(scsi1:0:6:0)
      Device using Narrow/Sync transfers at 10.0 MByte/sec, offset 15
      Transinfo settings: current(25/15/0/0), goal(12/15/0/0), user(12/15/0/0)
      Total transfers 132 (0 reads and 132 writes)
       < 2K    2K+    4K+    8K+   16K+   32K+   64K+   128K+
Reads:   0      0      0      0     0      0      0       0
Writes:  0      0      0      1    131     0      0       0

From this screen, you can see the transfer speed to the various SCSI devices connected to the controller based on channel ID, as well as detailed statistics concerning the amount and sizes of files read or written by that device. For instance, from the output above you can see that this controller is communicating with the CD-ROM at 20 megabytes per second, while the tape drive is connected at only 10 megabytes per second.

/proc/sys/

The /proc/sys/ directory is different from others in /proc/ because it not only provides information about the system but also allows you to make configuration changes to the kernel. This allows the administrator of the machine to immediately enable and disable kernel features.

Warning

Use caution when changing settings on a production system using the various files in the /proc/sys/ directory. Changing the wrong setting may render the kernel unstable, requiring a reboot of the system. For this reason, be sure you know the valid options for that file and the expected outcome before attempting to change a value in /proc/sys/.

A good way to determine if a particular file can be configured or is designed only to provide information is to list it with the -l flag in the terminal. If the file is writable, you may use it to configure the kernel. For example, a partial listing of /proc/sys/fs looks like this:

-r--r--r--   1 root   root   0 May 10 16:14 dentry-state
-rw-r--r--   1 root   root   0 May 10 16:14 dir-notify-enable
-r--r--r--   1 root   root   0 May 10 16:14 dquot-nr
-rw-r--r--   1 root   root   0 May 10 16:14 file-max
-r--r--r--   1 root   root   0 May 10 16:14 file-nr

In this listing, the files dir-notify-enable and file-max can be written to and, therefore, can be used to configure the kernel. The other files only provide feedback on current settings. Changing a value within a /proc/sys/ file is done by echoing the new value into the file. For example, to enable the System Request Key on a running kernel, type the command

echo 1 > /proc/sys/kernel/sysrq

This will change the sysrq file’s value from 0 (off) to 1 (on). The purpose of the System Request Key is to allow you to immediately instruct the kernel to do a number of important activities by using a simple key combination, such as immediately shutting down or restarting a system, syncing all mounted file systems, or dumping important information to your console. This feature is most useful when using a development kernel or if you are experiencing system freezes. However, it is considered a security risk for an unattended console and is therefore turned off by default under Red Hat Linux. Refer to /usr/src/linux-2.4/Documentation/sysrq.txt for more information on the System Request Key.

A few /proc/sys/ configuration files contain more than one value. In order to correctly send new values to them, place a space character between each value passed with the echo command, such as is done in this example:

echo 4 2 45 > /proc/sys/kernel/acct
Note

Any configuration changes you make using the echo command will disappear when the system is restarted. To make your configuration changes take effect at the time the system is booted, see Chapter 2.

The /proc/sys/ directory contains several subdirectories controlling different aspects of a running kernel.

/proc/sys/dev/

This directory provides parameters for particular devices on the system. Most systems have at least two directories, cdrom and raid, but customized kernels can have others, such as parport, which provides the ability to share one parallel port between multiple device drivers. The cdrom directory contains a file called info, which reveals a number of important CD-ROM parameters:

CD-ROM information, Id: cdrom.c 3.12 2000/10/18

drive name:             hdc
drive speed:            32
drive # of slots:       1
Can close tray:         1
Can open tray:          1
Can lock tray:          1
Can change speed:       1
Can select disk:        0
Can read multisession:  1
Can read MCN:           1
Reports media changed:  1
Can play audio:         1
Can write CD-R:         0
Can write CD-RW:        0
Can read DVD:           0
Can write DVD-R:        0
Can write DVD-RAM:      0

This file can be quickly scanned to discover the qualities of an unknown CD-ROM, at least in the eyes of the kernel. If multiple CD-ROMs are available on a system, each device is given its own column of information.

Various files in /proc/sys/dev/cdrom, such as autoclose and checkmedia, can be used to control the system’s CD-ROM. Use the echo command to enable or disable these features. If RAID support is compiled into the kernel, a /proc/sys/dev/raid/ directory will be available with at least two files in it: speed_limit_min and speed_limit_max. These settings determine how much to accelerate the RAID device for particularly I/O-intensive tasks, such as resyncing the disks.

/proc/sys/fs/

This directory contains an array of options and information concerning various aspects of the file system, including quota, file handle, inode, and dentry information. The binfmt_misc directory is used to provide kernel support for miscellaneous binary formats. The important files in /proc/sys/fs include:

  • dentry-state — Provides the status of the directory cache. The file looks similar to this:

    57411 52939 45 0 0 0

  • The first number reveals the total number of directory cache entries, while the second number displays the number of unused entries. The third number tells the number of seconds between when a directory has been freed and when it can be reclaimed, and the fourth measures the pages currently requested by the system. The last two numbers are not used and currently display only zeros.

  • dquot-nr — Shows the maximum number of cached disk quota entries.

  • file-max — Allows you to change the maximum number of file handles that the kernel will allocate. Raising the value in this file can resolve errors caused by a lack of available file handles.

  • file-nr — Displays the number of allocated file handles, used file handles, and the maximum number of file handles.

  • overflowgid and overflowuid — Define the fixed group ID and user ID, respectively, for use with file systems that support only 16-bit group and user IDs.

  • super-max — Controls the maximum number of superblocks available.

  • super-nr — Displays the current number of superblocks in use.

/proc/sys/kernel/

This directory contains a variety of different configuration files that directly affect the operation of the kernel. Some of the most important files are:

  • acct — Controls the suspension of process accounting based on the percentage of free space available on the file system containing the log. By default, the file looks like this:

    4 2 30

  • The second value sets the threshold percentage of free space when logging will be suspended, while the first value dictates the percentage of free space required for logging to resume. The third value sets the interval in seconds that the kernel polls the file system to see if logging should be suspended or resumed.

  • cap-bound — Controls the capability bounding settings, which provide a list of capabilities for any process on the system. If a capability is not listed here, then no process, no matter how privileged, can use that capability. The idea is to make the system more secure by ensuring that certain things cannot happen, at least beyond a certain point in the boot process. The various values that are possible here are beyond the scope of this book, so consult the kernel documentation for more information.

  • ctrl-alt-del — Controls whether Ctrl-Alt-Del will gracefully restart the computer using init (value 0) or force an immediate reboot without syncing the dirty buffers to disk (value 1).

  • domainname — Allows you to configure the system’s domain name, such as subgenius.com.

  • hostname — Allows you to configure the system’s hostname, such as bob.subgenius.com.

  • hotplug — Configures the utility to be used when a configuration change is detected by the system. This is primarily used with USB and Cardbus PCI. The default value of /sbin/hotplug should not be changed unless you are testing a new program to fulfill this role.

  • modprobe — Sets the location of the program to be used to load kernel modules when necessary. The default value of /sbin/modprobe signifies that kmod will call it to actually load the module when a kernel thread calls kmod.

  • msgmax — Sets the maximum size of any message sent from one process to another. This value is set to 8,192 bytes by default. Be careful about raising this value, as queued messages between processes are stored in nonswappable kernel memory. Any increase in msgmax would increase RAM requirements for the system.

  • msgmnb — Sets the maximum number of bytes in a single message queue. The default is 16,384.

  • msgmni — Sets the maximum number of message queue identifiers. The default is 16.

  • osrelease — Lists the Linux kernel release number. This file can be altered only by changing the kernel source and recompiling.

  • ostype — Displays the type of operating system. By default, this file is set to Linux, and this value can be changed only by changing the kernel source and recompiling.

  • overflowgid and overflowuid — Define the fixed group ID and user ID, respectively, for use with system calls on architectures that support only 16-bit group and user IDs.

  • panic — Defines the number of seconds the kernel will postpone rebooting when the system experiences a kernel panic. By default, the value is set to 0, which disables automatic rebooting after a panic.

  • printk — This file controls a variety of settings related to printing or logging error messages. Each error message reported by the kernel has a loglevel associated with it that defines the importance of the message. The loglevel values break down in this order:

    • 0 — Kernel emergency. The system is unusable.

    • 1 — Kernel alert. Action must be taken immediately.

    • 2 — Condition of the kernel is considered critical.

    • 3 — General kernel error condition.

    • 4 — General kernel warning condition.

    • 5 — Kernel notice of a normal but significant condition.

    • 6 — Kernel informational message.

    • 7 — Kernel debug-level messages.

  • Four values are found in the printk file:

    6 4 1 7

  • Each of these values defines a different rule for dealing with error messages. The first value, called the console loglevel, defines the lowest priority of messages that will be printed to the console. (Note that the lower the priority, the higher the loglevel number.) The second value sets the default loglevel for messages without an explicit loglevel attached to them. The third value sets the lowest possible loglevel configuration for the console loglevel. The last value sets the default value for the console loglevel.

  • rtsig-max — Configures the maximum number of POSIX realtime signals that the system may have queued at any one time. The default value is 1,024.

  • rtsig-nr — The current number of POSIX realtime signals queued by the kernel.

  • sem — This file configures semaphore settings within the kernel. A semaphore is a System V IPC object that is used to control utilization of a particular process.

  • shmall — Sets the total amount of shared memory that can be used at one time on the system, in bytes. By default, this value is 2,097,152.

  • shmmax — Sets the largest shared memory segment size allowed by the kernel, in bytes. By default, this value is 33,554,432. However, the kernel supports much larger values than this.

  • shmmni — Sets the maximum number of shared memory segments for the whole system. By default, this value is 4,096.

  • sysrq — Activates the System Request Key, if this value is set to anything other than the default of 0.

  • threads-max — Sets the maximum number of threads to be used by the kernel, with a default value of 2,048.

  • version — Displays the date and time the kernel was last compiled. The first field in this file, such as #3, relates to the number of times a kernel was built from the source base.

The random directory stores a number of values related to generating random numbers for the kernel.

/proc/sys/net/

This directory contains assorted directories concerning various networking topics. Various configurations at the time of kernel compilation make available different directories here, such as appletalk, ethernet, ipv4, ipx, and ipv6. Within these directories, you can adjust the assorted networking values for that configuration on a running system.

Note

Given the wide variety of possible networking options available with Linux and the great amount of space required to discuss them, only the most common /proc/sys/net/ directories will be discussed.

The core directory contains a variety of settings that control the interaction between the kernel and networking layers. The most important files there are:

  • message_burst — The amount of time in tenths of a second required to write a new warning message. This is used to prevent Denial of Service (DoS) attacks. The default setting is 50.

  • message_cost — Also used to prevent DoS attacks by placing a cost on every warning message. The higher the value of this file (default of 5), the more likely the warning message will be ignored. The idea of a DoS attack is to bombard your system with requests that generate errors and fill up disk partitions with log files or require all of your system’s resources to handle the error logging. The settings in message_burst and message_cost are designed to be modified based on your system’s acceptable risk versus the need for comprehensive logging.

  • netdev_max_backlog — Sets the maximum number of packets allowed to queue when a particular interface receives packets faster than the kernel can process them. The default value for this file is 300.

  • optmem_max — Configures the maximum ancillary buffer size allowed per socket.

  • rmem_default — Sets the receive socket buffer’s default size in bytes.

  • rmem_max — Sets the receive socket buffer’s maximum size in bytes.

  • wmem_default — Sets the send socket buffer’s default size in bytes.

  • wmem_max — Sets the send socket buffer’s maximum size in bytes.

The /ipv4 directory contains additional networking settings. Many of these settings, used in conjunction with one another, are very useful in preventing attacks on the system or using the system to act as a router.

Warning

An erroneous change to these files may affect your remote connectivity to the system.

Here are some of the most important files in the /proc/sys/net/ipv4/ directory:

  • icmp_destunreach_rate, icmp_echoreply_rate, icmp_paramprob_rate, and icmp_timeexeed_rate — Set the maximum ICMP send packet rate, in hundredths of a second, to hosts under certain conditions. A setting of 0 removes any delay and is not a good idea.

  • icmp_echo_ignore_all and icmp_echo_ignore_broadcasts — Allows the kernel to ignore ICMP ECHO packets from every host or only those originating from broadcast and multicast addresses, respectively. A value of 0 allows the kernel to respond, while a value of 1 ignores the packets.

  • ip_default_ttl — Sets the default Time To Live (TTL), which limits the number of hops a packet may make before reaching its destination. Increasing this value can diminish system performance.

  • ip_forward — Permits interfaces on the system to forward packets to one other. By default, this file is set to 0. Setting this file to 1 will enable network packet forwarding.

  • ip_local_port_range — Specifies the range of ports to be used by TCP or UDP when a local port is needed. The first number is the lowest port to be used, and the second number specifies the highest port. Any systems that expect to require more ports than the default 1,024 to 4,999 should use the 32,768 to 61,000 range in this file.

  • tcp_syn_retries — Provides a limit on the number of times your system will retransmit a SYN packet when attempting to make a connection.

  • tcp_retries1 — Sets the number of permitted retransmissions attempting to answer an incoming connection. Default of 3.

  • tcp_retries2 — Sets the number of permitted retransmissions of TCP packets. Default of 15.

The /usr/src/linux-2.4/Documentation/networking/ip-sysctl.txt file contains a complete list of files and options available in the /proc/sys/net/ipv4/ directory. A number of other directories that exist within the /proc/sys/net/ipv4/ directory cover specific topics.

The conf directory allows each of the system interfaces to be configured in different ways, including the use of default settings for unconfigured devices (in the default subdirectory) and settings that override all special configurations (in the all subdirectory). In order to control connections between direct neighbors, meaning any other system directly connected to your system, the neigh directory allows special configurations for each interface. This will allow you to treat differently systems that you trust more because of their relative proximity to your system. At the same time, it also makes it easy to put strict rules in place for systems several hops away.

Routing over IPV4 also has its own directory, route. Unlike conf and neigh, the route directory contains specifications that apply to routing with any interfaces on the system. Many of these settings, such as max_size, max_delay, and min_delay, relate to controlling the size of the routing cache. To clear the routing cache, simply write any value to the flush file. Additional information about these directories and the possible values for their configuration files can be found in /usr/src/linux-2.4/Documentation/filesystems/proc.txt.

/proc/sys/vm/

This directory facilitates the configuration of the Linux kernel’s virtual memory (VM) subsystem. The kernel makes extensive and intelligent use of virtual memory, which is commonly called swap space. The following files are commonly found in the /proc/sys/vm/ directory:

  • bdflush — Sets various values related to the bdflush kernel daemon.

  • buffermem — Allows you to control the percentage amount of total system memory to be used for buffer memory. Typical output for this file looks like this:

    2        10        60

The first and last values set the minimum and maximum percentage of memory to be used as buffer memory, respectively. The middle value sets the percentage of system memory dedicated to buffer memory where the memory management subsystem will begin to clear buffer cache more than other kinds of memory to compensate for a general lack of free memory.

  • kswapd — Sets various values concerned with the kernel swap-out daemon, kswapd. This file has three values:

    512 32 8

  • The first value sets the maximum number of pages that kswapd will attempt to free in a single attempt. The larger this number, the more aggressively the kernel can move to free pages. The second value sets the minimum number of times that kswapd attempts to free a page. The third value sets the number of pages kswapd attempts to write in a single attempt. Proper tuning of this final value can improve performance on a system using a lot of swap space by telling the kernel to write pages in large chunks, minimizing the number of disk seeks.

  • max_map_count — Configures the maximum number of memory map areas a process may have. In most cases, the default value of 65,536 is appropriate.

  • overcommit_memory — When this is set to the default value of 0, the kernel estimates the amount of memory available and fails requests that are blatantly invalid. Unfortunately, since memory is allocated using a heuristic rather than a precise algorithm, it can sometimes overload the system. If overcommit_memory is set to 1, then the potential for system overload is increased, but so is the performance for memory-intensive tasks, such as those used by some scientific software. For customers who need more control over the risk of overcommitted memory, the following two options have been added. Setting overcommit_memory to 2 fails if a memory request adds up to more than half of the physical RAM, plus swap. Setting it to 3 fails if a memory request adds up to more than swap alone can hold.

  • pagecache — Controls the amount of memory used by the page cache. The values in pagecache are percentages, and they work in a similar way as buffermem to enforce minimums and maximums of available page cache memory.

  • page-cluster — Sets the number of pages read in a single attempt. The default value of 4, which actually relates to 16 pages, is appropriate for most systems.

  • pagetable_cache — Controls the number of page tables that are cached on a per-processor basis. The first and second values relate to the minimum and maximum number of page tables to set aside, respectively.

The /usr/src/linux-2.4/Documentation/sysctl/vm.txt file contains additional information on these various files.

/proc/sysvipc/

This directory contains information about System V IPC resources. The files in this directory relate to System V IPC calls for messages (msg), semaphores (sem), and shared memory (shm).

/proc/tty/

This directory contains information about the available and currently used tty devices on the system. Originally called a teletype device, character-based data terminals are called tty devices. In Linux, there are three different kinds of tty devices. Serial devices are used with serial connections, such as over a modem or using a serial cable. Virtual terminals create the common console connection, such as the virtual consoles available when pressing Alt- F at the system console. Pseudo terminals create a two-way communication that is used by some higher level applications, such as X11. The drivers file is a list of the current tty devices in use:

serial        /dev/cua       5    64-127   serial:callout
serial        /dev/ttyS      4    64-127   serial
pty_slave     /dev/pts     136     0-255   pty:slave
pty_master    /dev/ptm     128     0-255   pty:master
pty_slave     /dev/ttyp      3     0-255   pty:slave
pty_master    /dev/pty       2     0-255   pty:master
/dev/vc/0     /dev/vc/0      4         0   system:vtmaster
/dev/ptmx     /dev/ptmx      5         2   system
/dev/console  /dev/console   5         1   system:console
/dev/tty      /dev/tty       5         0   system:/dev/tty
unknown       /dev/vc/%d     4      1-63   console

The /proc/tty/driver/serial file lists the usage statistics and status of each of the serial tty lines. In order for tty devices to be used in a similar way as network devices, the Linux kernel enforces line discipline on the device. This allows the driver to place a specific type of header with every block of data transmitted over the device, making it possible for the remote end of the connection to be able to see that block of data as just one in a stream of data blocks. SLIP and PPP are common line disciplines, and each is commonly used to connect systems to one other over a serial link. Registered line disciplines are stored in the ldiscs file, with detailed information available in the ldisc directory.


Using sysctl

The sysctl command is used to view, set, and automate kernel settings in the /proc/sys/ directory. To get a quick overview of all settings configurable in the /proc/sys/ directory, type the sysctl -a command as root. This will create a large, comprehensive list, a small portion of which looks something like this:

net.ipv4.route.min_delay = 2
kernel.sysrq = 0
kernel.sem = 250            32000        32       128

This is the same basic information you would see if you viewed each of the files individually. The only difference is the file location. The /proc/sys/net/ipv4/route/min_delay file is signified by net.ipv4.route.min_delay, with the directory slashes replaced by dots and the proc.sys portion assumed.

The sysctl command can be use in place of echo to assign values to writable files in the /proc/sys/ directory. For instance, instead of using this command:

echo 1 > /proc/sys/kernel/sysrq

you can use this sysctl command:

sysctl -w kernel.sysrq="1"
kernel.sysrq = 1

While quickly setting single values like this in /proc/sys/ is helpful during testing, it does not work as well on a production system, as all /proc/sys/ special settings are lost when the machine is rebooted. To preserve the settings that you want to make permanently to your kernel, add them to the /etc/sysctl.conf file. Every time the system boots, the init program runs the /etc/rc.d/rc.sysinit script. This script contains a command to execute sysctl using /etc/sysctl.conf to dictate the values passed to the kernel. Any values added to /etc/sysctl.conf will take effect each time the system boots.


Additional Resources

Following are additional sources of information about /proc/.

Installed Documentation

Most of the best /proc/ documentation is available on your system.

  • /usr/src/linux-2.4/Documentation/file systems/proc.txt — Contains assorted, but limited, information about all aspects of the /proc/ directory.

  • /usr/src/linux-2.4/Documentation/sysrq.txt — An overview of System Request Key options.

  • /usr/src/linux-2.4/Documentation/sysctl — A directory containing a variety of sysctl tips, including modifying values that concern the kernel (kernel.txt), accessing file systems (fs.txt), and virtual memory use (vm.txt).

  • /usr/src/linux-2.4/Documentation/networking/ip-sysctl.txt — A look at various IP networking options.

  • /usr/src/linux-2.4 — Some of the most authoritative information on /proc/ can be found by reading the kernel source code. Make sure the kernel-source RPM is installed on your system and look in the /usr/src/linux-2.4 directory for the source code.

Useful Website

  • http://www.linuxhq.com — This site maintain a complete database of source, patches, and documentation for various versions of the Linux kernel.


Chapter 5: Gathering System Information

Before you learn how to configure your system, you should learn how to gather essential system information. For example, you should know how to find the amount of free memory, the amount of available hard-drive space, how your hard drive is partitioned, and what processes are running. This chapter describes how to retrieve this type of information from your Red Hat Linux system using simple commands and a few simple programs.

System Processes

The ps aux command displays a list of current system processes, including processes owned by other users. This list is a static list; in other words, it is a snapshot of what is running when you invoked the command. If you want a constantly updated list of running processes, use top as described below.

The ps output can be long. To prevent it from scrolling off the screen, you can pipe it through less:

ps aux | less

You can use the ps command in combination with the grep command to see if a process is running. For example, to determine if emacs is running, use the following command:

ps ax | grep emacs

The top command displays currently running processes and important information about them, including their memory and CPU usage. The list is both real-time and interactive. An example of top’s output is provided as follows:

6:14pm     up 2 days, 19:29,  5 users,  load average: 0.10, 0.06, 0.07
71 processes: 68 sleeping, 2 running, 1 zombie, 0 stopped
CPU states:   2.7% user,   0.5% system,  0.0% nice, 96.6% idle
Mem:   256812K av,  252016K used,  4796K free, 97228K shrd,  43300K buff
Swap:  265032K av,  1328K used,    263704K free,  86180K cached

PID   USER   PRI  NI  SIZE    RSS SHARE STAT %CPU %MEM  TIME COMMAND
15775 joe     5   0   11028   10M  3192  S    1.5  4.2  0:46 emacs
14429 root   15   0   63620   62M  3284  R    0.5 24.7 63:33 X
17372 joe    11   0    1056  1056   840  R    0.5  0.4  0:00 top
17356 joe     2   0    4104  4104  3244  S    0.3  1.5  0:00 gnome-terminal
14461 joe     1   0    3584  3584  2104  S    0.1  1.3  0:17 sawfish
1     root    0   0     544   544   476  S    0.0  0.2  0:06 init
2     root    0   0       0     0     0 SW    0.0  0.0  0:00 kflushd
3     root    1   0       0     0     0 SW    0.0  0.0  0:24 kupdate
4     root    0   0       0     0     0 SW    0.0  0.0  0:00 kpiod
5     root    0   0       0     0     0 SW    0.0  0.0  0:29 kswapd
347   root    0   0     556   556   460  S    0.0  0.2  0:00 syslogd
357   root    0   0     712   712   360  S    0.0  0.2  0:00 klogd
372   bin     0   0     692   692   584  S    0.0  0.2  0:00 portmap
388   root    0   0       0     0     0 SW    0.0  0.0  0:00 lockd
389   root    0   0       0     0     0 SW    0.0  0.0  0:00 rpciod
414   root    0   0     436   432   372  S    0.0  0.1  0:00 apmd
476   root    0   0     592   592   496  S    0.0  0.2  0:00 automount

To exit top, type q. Useful interactive commands that you can use with top include those shown in Table 5-1.

Table 5-1: Interactive top commands
Command | Description
Space | Immediately refresh the display
h | Display a help screen
k | Kill a process. You will be prompted for the process ID and the signal to send to it.
n | Change the number of processes displayed. You will be prompted to enter the number.
u | Sort by user.
M | Sort by memory usage.
P | Sort by CPU usage.
Tip

Applications such as Mozilla and Nautilus are thread-aware — multiple threads are created to handle multiple users or multiple requests, and each thread is given a process ID. By default, ps and top display only the main (initial) thread. To view all threads, use the command ps -m or press Shift-H in top.

If you prefer a graphical interface for top, you can use the GNOME System Monitor. To start it from the desktop, select Main Menu Button (on the Panel) > System Tools > System Monitor or type gnome-system-monitor at a shell prompt from within the X Window System. Then select the Process Listing tab.

The GNOME System Monitor allows you to search for a particular process in the list of running process as well as view all processes, your processes, or active processes. To learn more about a process, select it and click the More Info button. Details about the process will be displayed at the bottom of the window.

To stop a process, select it and click End Process. This function is useful for processes that have stopped responding to user input. To sort by the information in a specific column, click on the name of the column. The name of that column then appears in a different shade than the names of the other columns in the window.

By default, the GNOME System Monitor does not display threads. To change this, select Edit > Preferences, click the Process Listing tab, and select Show Threads. This screen also allows you to configure the update interval, what type of information to display about each process by default, and the colors of the system monitor graphs.

Click To expand
Figure 5-1: GNOME System Monitor


Memory Usage

The free command displays the total amount of physical memory and swap space for the system as well as the amount of memory that is in use, free, shared, in kernel buffers, and cached. Output from the free command might look like this:

            total   used     free     shared      buffers       cached
Mem:       256812  240668   16144     105176       50520        81848
-/+ buffers/cache: 108300  148512
Swap:      265032     780  264252

The command free -m shows the same information in megabytes, which are easier to read.

            total   used      free      shared       buffers   cached
Mem:         250     235       15         102          49        79
-/+ buffers/cache:   105      145
Swap:     258      0        258

If you prefer a graphical interface for free, use the GNOME System Monitor. To start it from the desktop, go to the Main Menu Button (on the Panel) > System Tools > System Monitor or type gnome-system-monitor at a shell prompt from within the X Window System. Then choose the System Monitor tab.


File Systems

The df command reports the system’s disk space usage. If you type df at a shell prompt, the output looks similar to the following:

Filesystem    1k-blocks    Used         Available Use% Mounted on
/dev/hda2     10325716    2902060       6899140    30%     /
/dev/hda1        15554       8656          6095    59%   /boot
/dev/hda3     20722644    2664256      17005732    14%   /home
none            256796          0        256796     0%   /dev/shm

By default, df’s output shows the partition size in 1-kilobyte blocks and the amount of used and available disk space in kilobytes. To view the information in megabytes and gigabytes, use the command df -h. The -h argument stands for human-readable format. The output looks similar to the following:

Filesystem                    Size    Used Avail Use% Mounted on
/dev/hda2                     9.8G    2.8G      6.5G    30% /
/dev/hda1                      15M    8.5M      5.9M    59% /boot
/dev/hda3                      20G    2.6G       16G    14% /home
none                          251M       0      250M     0% /dev/shm

In the list of partitions, there is an entry for /dev/shm. This entry represents the system’s virtual memory file system.

The du command displays the estimated amount of space being used by files in a directory. If you type du at a shell prompt, the disk usage for each of the subdirectories will be displayed in a list. The grand total for the current directory and subdirectories will also be shown as the last line in the list. If you do not want to see the totals for all the subdirectories, use the command du -hs to see only the grand total for the directory in human-readable format. Type du --help to see more options.

To view the system’s partitions and disk space usage in a graphical format, use the System Monitor tab.

Monitoring File Systems

Red Hat Linux provides a utility called diskcheck that monitors the amount of free disk space on the system. Based on the configuration file, it will send email to the system administrator when one or more disk drives reach a specified capacity. To use this utility, you must have the diskcheck RPM package installed. This utility is run as an hourly cron task. The following variables can be defined in /etc/diskcheck.conf:

defaultCutoff

When disk drives reach the specified percentage of total disk capacity, it will be reported. For example, if defaultCutoff = 90, an email will be sent when the monitored disk drives reach 90 percent capacity.

cutoff[/dev/partition]

Override the defaultCutoff for the partition. For example, if cutoff['/dev/hda3'] = 50 is specified, diskcheck will alert the system administrator when the partition /dev/hda3 reaches 50 percent capacity.

cutoff[/mountpoint]

Override the defaultCutoff for the mount point. For example, if cutoff['/home'] = 50 is specified, diskcheck will alert the system administrator when the mount point /home reaches 50 percent capacity.

exclude

Specify one or more partitions for diskcheck to ignore. For example, if exclude = "/dev/sda2 /dev/sda4" is specified, diskcheck will not alert the system administrator if /dev/sda2 or /dev/sda4 reaches the specified cutoff percentage.

ignore

Specify one or more file system types to ignore in the format -x filesystem-type. For example, if ignore = "-x nfs -x iso9660" is specified, the system administrator will not be alerted about nfs or iso9660 file systems’ reaching capacity.

mailTo

The email address of the system administrator to alert when partitions and mount points reach the specified capacity. For example, if mailTo = "webmaster@example.com" is specified, webmaster@example.com will be emailed alerts.

mailFrom

Specify the identity of the email sender. This is useful if the system administrator wants to filter the mail from diskcheck. For example, if mailFrom = "Disk Usage Monitor" is specified, email will be sent to the system administrator from the sender Disk Usage Monitor.

mailProg

Specify the mail program to use to send email alerts. For example, if mailProg = "/usr/sbin/sendmail" is specified, Sendmail will be used as the mail program.

You do not have to restart a service if you change the configuration file because it is read each time the cron task is run. You must have the crond service running for cron tasks to be executed. To determine if the daemon is running, use the command /sbin/service crond status. It is recommended that you start the service at boot time.


Hardware

If you are having trouble configuring your hardware or just want to know what hardware is in your system, use the Hardware Browser application to display the hardware that can be probed. To start the program from the desktop, type hwbrowser at a shell prompt. As shown in Figure 5-2, it displays your CD-ROM devices, floppy disks, hard drives and their partitions, network devices, pointing devices, system devices, and video cards. Click on the category name in the left menu, and the information will be displayed.

You can also use the lspci command to list all PCI devices. Use the command lspci -v for more verbose information or lspci -vv for very verbose output. For example, lspci can be used to determine the manufacturer, model, and memory size of a system’s video card:

01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP  \
(rev  04)
(prog-if 00 [VGA])
Subsystem: Matrox Graphics, Inc. Millennium G400 Dual Head Max
Flags: medium devsel, IRQ 16
Memory at f4000000 (32-bit, prefetchable) [size=32M]
Memory at fcffc000 (32-bit, non-prefetchable) [size=16K]
Memory at fc000000 (32-bit, non-prefetchable) [size=8M]
Expansion ROM at 80000000 [disabled] [size=64K]
Capabilities: [dc] Power Management version 2
Capabilities: [f0] AGP version 2.0

lspci is also useful for identifying the network card in your system if you do not know the manufacturer or model number.

Click To expand
Figure 5-2: Hardware Browser


Additional Resources

To learn more about gathering system information, refer to the following resources in installed documentation.

  • ps --help — Displays a list of options that can be used with ps.

  • top manual page — Type man top to learn more about top and its many options.

  • free manual page — type man free to learn more about free and its many options.

  • df manual page — Type man df to learn more about the df command and its many options.

  • du manual page — Type man du to learn more about the du command and its many options.

  • /proc — The contents of the /proc directory can also be used to gather more detailed system information. Refer to Chapter 4 for additional information about the /proc directory.


Part II: Basic System Administration

Chapter List

Chapter 6: General System Configuration
Chapter 7: Users and Groups
Chapter 8: Printer Configuration
Chapter 9: X Servers and Clients
Chapter 10: Automated Tasks
Chapter 11: Redundant Array of Independent Disks (RAID)
Chapter 12: Kernel Management


Chapter 6: General System Configuration

This chapter deals with the most basic aspects of configuring a Red Hat Linux system: setting the time and date, controlling access to the console, and installing and upgrading software.

The Time and Date Properties Tool allows the user to configure the system date and time. In addition, the user can also configure the time zone and set up the Network Time Protocol (NTP) daemon to synchronize the system with a time server. In order to make changes in the time and date configuration, the user must have root privileges. This tool is an X Window–based application, so the X Window System must be running in order to use this tool. To start the application from the desktop, go to the Main Menu Button (on the Panel) > System Settings > Date & Time or type redhat-config-date at a shell prompt (for example, in an XTerm window or a GNOME terminal window).

Time and Date Properties

As shown in Figure 6-1, the first tabbed window that appears is for configuring the system date and time and the NTP daemon (ntpd).

Click To expand
Figure 6-1: Time and Date properties

To change the date, use the arrows to the left and right of the month. Use the arrows to the left and right of the year to change the year, and click on the day of the week to change it. Changes will not take place until you click the Apply button.

To change the time, use the up and down arrow buttons beside the Hour, Minute, and Second fields in the Time section. Changes will not take place until you click the Apply button.

Note

Changing the date and time will change the system clock as well as the hardware clock. Clicking Apply or OK is equivalent to executing the date and hwclock commands with the selected date and time.

The Network Time Protocol (NTP) daemon synchronizes the system clock with a remote time server or time source (such as a satellite). The application allows you to configure an NTP daemon to synchronize your system clock with a remote server. To enable this feature, click the Enable Network Time Protocol button. This will enable the Server pull-down menu. You can choose one of the predefined servers or type a server name in the pull-down menu.

Your system will not start synchronizing with the NTP server until you click Apply. After you click Apply, the configuration will be saved and the NTP daemon will be started (or restarted if it is already running). If you want this daemon to start automatically at boot time, execute the command

/sbin/chkconfig --level 345 ntpd on

to enable ntpd for runlevels 3, 4, and 5. For more information on NTP, read the NTP documentation available in the /usr/share/doc/ntp-version directory.

The NTP server is written to the /etc/ntp.conf and /etc/ntp/step-tickers files. Clicking the Apply button will apply any changes that you have made to the date and time, the NTP daemon settings, and the time zone settings. Clicking the OK button will apply the changes and then exit the program.

Warning

If you configured a medium or high security level during installation or with the Security Level Configuration Tool, the firewall rules will block the connection to the NTP port. To allow NTP to work, run the Security Level Configuration Tool, select Customize, and add udp:ntp to the other ports.


Time Zone Configuration

To configure the system time zone, click the Time Zone tab. The time zone can be changed either by using the interactive map or by choosing the desired time zone from the list below the map. To use the map, click on the city that represents the desired time zone. A red X will appear, and the time zone selection will change in the list below the map. Click Apply to save the changes. Click OK to apply the changes and exit the program.

If your system clock is set to use UTC, select the System clock uses UTC option. UTC stands for the Universal Time Zone, also known as Greenwich Mean Time (GMT). Other time zones are determined by adding to or subtracting from the UTC time.


Console Access

Users logged in at the console have special privileges. Consequently, an administrator may wish to restrict access to console functions as a matter of security. This section describes the procedures used to restrict access to the console and to specific console functions.

When normal (non-root) users log in to a computer locally, they are given two types of special permissions:

  • They can run certain programs that they would not otherwise be able to run

  • They can access certain files (normally special device files used to access diskettes, CD-ROMs, and so on) that they would not otherwise be able to access

Since there are multiple consoles on a single computer and multiple users can be logged in to the computer locally at the same time, one of the users has to “win” the race to access the files. The first user to log in at the console owns those files. Once the first user logs out, the next user who logs in will own the files.

In contrast, every user who logs in at the console will be allowed to run programs that accomplish tasks normally restricted to the root user. If the X Window System is running, these actions can be included as menu items in a graphical user interface. As shipped, the console-accessible programs include halt, poweroff, and reboot.


Disabling Shutdown Via Ctrl-Alt-Del

By default, /etc/inittab specifies that your system is set to shut down and reboot the system in response to a Ctrl-Alt-Del key combination used at the console. If you would like to completely disable this ability, you will need to comment out the following line in /etc/inittab by putting a hash mark (#) in front of it:

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

Alternatively, you may just want to allow certain non-root users the right to shutdown the system from the console using Ctrl-Alt-Del. You can restrict this privilege to certain users by taking the following steps:

  1. Add an -a option to the /etc/inittab line shown above, so that it reads:

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

    The -a flag tells shutdown to look for the /etc/shutdown.allow file, which you will create in the next step.

  2. Create a file named shutdown.allow in /etc. The shutdown.allow file should list the usernames of any users who are allowed to shut down the system using Ctrl-Alt-Del. The format of the /etc/shutdown.allow file is a list of usernames, one per line, like the following:

    stephen
jack
sophie

According to this example shutdown.allow file, stephen, jack, and sophie are allowed to shut down the system from the console using Ctrl-Alt-Del. When that key combination is used, the shutdown -a in /etc/inittab checks to see if any of the users in /etc/shutdown.allow (or root) are logged in on a virtual console. If one of them is, the shutdown of the system will continue; if not, an error message will be written to the system console instead.

For more information on shutdown.allow, see the shutdown man page.


Disabling Console Program Access

In order to disable access by users to console programs, run this command as root:

rm -f /etc/security/console.apps/*

In environments where the console is otherwise secured (BIOS and boot loader passwords are set, Ctrl-Alt-Delete is disabled, the power and reset switches are disabled, and so forth), you may not want to allow any user at the console to run poweroff, halt, and reboot, which are accessible from the console by default.

To remove these abilities, run the following commands as root:

rm -f /etc/security/console.apps/poweroff
rm -f /etc/security/console.apps/halt
rm -f /etc/security/console.apps/reboot


Disabling All Console Access

The PAM pam_console.so module manages console file permissions and authentication. (See Chapter 25 for more information on configuring PAM.) If you want to disable all console access, including program and file access, comment out all lines that refer to pam_console.so in the /etc/pam.d directory. As root, the following script will do the trick:

cd /etc/pam.d
for i in * ; do
sed ‘/[^#]. *pam_console.so/s/^/#/’ < $i > foo && mv foo $i

done


Defining the Console

The pam_console.so module uses the /etc/security/console.perms file to determine the permissions for users at the system console. The syntax of the file is very flexible; you can edit the file so that these instructions no longer apply. However, the default file has a line that looks like this:

console =tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9]

When users log in, they are attached to some sort of named terminal, either an X server with a name like :0 or mymachine.example.com:1.0 or a device like /dev/ttyS0 or /dev/pts/2. The default is to define that local virtual consoles and local X servers are considered local, but if you want to consider the serial terminal next to you on port /dev/ttyS1 to also be local, you can change that line to read:

console =tty[0-9][0-9]* :[0-9]\.[0-9] :[0-9] /dev/ttyS1


Making Files Accessible from the Console

In /etc/security/console.perms, there is a section with lines like:

floppy =/dev/fd[0-1]* /dev/floppy/*
sound =/dev/dsp* /dev/audio* /dev/midi* /dev/mixer* /dev/sequencer \
/dev/sound/*
cdrom =/dev/cdrom* /dev/cdwriter*

You can add your own lines to this section, if necessary. Make sure that any lines you add refer to the appropriate device. For example, you could add the following line:

scanner =/dev/scanner

(Of course, make sure that /dev/scanner is really your scanner and not, say, your hard drive.) That’s the first step. The second step is to define what is done with those files. Look in the last section of /etc/security/console.perms for lines similar to:

console    0660 floppy  0660 root.floppy
console    0600 sound   0640 root
console    0600 cdrom   0600 root.disk

and add a line like:

console    0600 scanner 0600 root

Then, when you log in at the console, you will be given ownership of the /dev/scanner device, and the permissions will be 0600 (readable and writable by you only). When you log out, the device will be owned by root and still have 0600 (readable and writable by root only) permissions.


Enabling Console Access for Other Applications

If you wish to make other applications accessible to console users, you will have to do a bit more work. First of all, console access works only for applications that reside in /sbin or /usr/sbin, so the application you wish to run must be there. After verifying that, perform the following steps:

  1. Create a link from the name of your application, such as the foo program used as an example in this section, to the /usr/bin/consolehelper application:

    cd /usr/bin
ln -s consolehelper foo

  2. Create the file /etc/security/console.apps/foo:

    touch /etc/security/console.apps/foo

  3. Create a PAM configuration file for the foo service in /etc/pam.d/. An easy way to do this is to start with a copy of the halt service’s PAM configuration file and then modify the file if you want to change the behavior:

    cp /etc/pam.d/halt /etc/pam.d/foo

Now, when you run /usr/bin/foo, it will call consolehelper, which will authenticate the user with the help of /usr/sbin/userhelper. To authenticate the user, consolehelper will ask for the user’s password if /etc/pam.d/foo is a copy of /etc/pam.d/halt (otherwise, it will do precisely what is specified in /etc/pam.d/foo) and then run /usr/sbin/foo with root permissions.

In the PAM configuration file, an application can be configured to use the pam_timestamp module to remember (cache) a successful authentication attempt. When an application is started and proper authentication is provided (the root password), a timestamp file is created. By default, a successful authentication is cached for five minutes. During this time, any other application that is configured to use pam_timestamp and run from the same session is automatically authenticated for the user — the user does not have to enter the root password again.

This module is included in the pam package. To enable this feature, the PAM configuration file in /etc/pam.d/ must include the following lines:

auth sufficient /lib/security/pam_timestamp.so
session optional /lib/security/pam_timestamp.so

The first line that begins with auth should be after any other auth sufficient lines, and the line that begins with session should be after any other session optional lines. If an application configured to use pam_timestamp is successfully authenticated from the Main Menu Button (on the Panel), an icon is displayed in the notification area of the panel if you are running the GNOME desktop environment. After the authentication expires (the default is five minutes), the icon disappears. The user can select to forget the cached authentication by clicking on the icon and selecting the option to forget authentication.


The floppy Group

If, for whatever reason, console access is not appropriate for you and you need to give non-root users access to your system’s diskette drive, you can do so with the floppy group. Simply add the user(s) to the floppy group using the tool of your choice. Here is an example showing how gpasswd can be used to add user fred to the floppy group:

[root@bigdog root]# gpasswd -a fred floppy
Adding user fred to group floppy
[root@bigdog root]#

Now user fred will now be able to access the system’s diskette drive from the console.


Red Hat Network and RPM

Red Hat Linux consists of various software applications and utilities, known as RPM packages. A package is just a file that contains a software program. This section explains three ways to update your system: using Red Hat Network, using the online Errata List, and using the Red Hat Linux Installation CD-ROMs.

Red Hat Network

Red Hat Network is an Internet solution for managing one or more Red Hat Linux systems. All Security Alerts, Bug Fix Alerts, and Enhancement Alerts (collectively known as Errata Alerts) can be downloaded directly from Red Hat using the Red Hat Update Agent standalone application or through the RHN Web interface available at http://rhn.redhat.com/.

Red Hat Network saves users time by sending them email when updated packages are released. Users do not have to search the Web for updated packages or security alerts. By default, Red Hat Network installs the packages as well. Users do not have to learn how to use RPM or worry about resolving software package dependencies; RHN does it all.

Each Red Hat Network account comes with:

  • Errata Alerts — learn when Security Alerts, Bug Fix Alerts, and Enhancement Alerts are issued for all the systems in your network through the Basic interface

  • Automatic email notifications — receive an email notification when an Errata Alert is issued for your system

  • Scheduled Errata Updates — schedule delivery of Errata Updates (with optional automatic installation)

  • Package installation — Schedule package installation on one or more systems with the click of a button

  • Red Hat Update Agent — use the Red Hat Update Agent to download the latest software packages for your system (with optional package installation)

  • Red Hat Network website — manage multiple systems, download individual packages, and schedule actions such as Errata Updates through a secure Web browser connection from any computer

To start using Red Hat Network, follow these three basic steps:

  1. Create a System Profile by running the Red Hat Network Registration Client rhn_register) on the system you want to register.

  2. Log in to RHN at http://rhn.redhat.com/ and entitle the system to a service offering. Everyone receives a free Red Hat Network account for one system. Additional accounts must be purchased.

  3. Start scheduling updates through the RHN website, or download and install Errata Updates using the Red Hat Update Agent.

For more detailed instructions, read the Red Hat Network User Reference Guide available at http://www.redhat.com/docs/manuals/RHNetwork/.

Tip

Red Hat Linux includes the Red Hat Network Alert Notification Tool, a convenient panel applet that displays visible alerts when there is an update for your Red Hat Linux system. Refer to the following URL for more information about the applet: http://rhn.redhat.com/help/basic/applet.html.

Errata List

It is recommended that new users use Red Hat Network to download and install/upgrade packages. Updating Errata packages from the Red Hat Linux Errata website is recommended for more experienced Red Hat Linux users, as it requires users to resolve software dependencies manually. (A software dependency is when a package is dependent on other packages’ being installed.)

All Security Alerts, Bug Fix Alerts, and Enhancement Alerts (collectively known as Errata Alerts) can also be downloaded from the Red Hat website at http://www.redhat.com/apps/support/errata/. Click on the Red Hat Linux version you are using to view a list of all available errata for Red Hat Linux. Click on the name of the Errata Alert that you want to apply to your system. Instructions for updating the packages are on the individual Errata pages. Red Hat, Inc., tests and approves the RPMs posted on this site. RPMs downloaded from other sites are not supported.

Installation CD-ROMs

Place one of the installation CDs in your CD-ROM drive. Inserting a CD in the CD-ROM drive should automatically open the file manager. In the file manager screen, click on /mnt/cdrom/RedHat/RPMS. Scroll through the files on the right and look for the packages you want. Open a terminal and log in as root by typing:

su -

Next, use the rpm command to install the packages. The -Uvh option that follows the command specifies that you want to install or upgrade the package, that you want to see verbose messages, and that you want to see hash marks (#) while the package is installing. In this example, the documentation files, which all begin with rhl, would be installed. The string rhl-*.rpm tells your system to install all files that begin with rhl and end in .rpm (* is a wildcard and keeps you from having to type each of the long file names manually). In place of rhl, put whatever comes before the first hyphen in the name of the package you want to install.

rpm -Uvh rhl-*.rpm

Press Enter. Type exit at the command line and press Enter again. This takes you out of the root login and back to your user account.

Now that the package is installed, it should appear in the appropriate place in the panel’s main menu.


Package Management Tool

During installation, users select an installation type such as “Workstation” or “Server.” Software packages are installed based on this selection. Because people use their computers differently, users might want to install or remove packages after installation. The Package Management Tool allows users to perform these actions.

To start the application, go to the Main Menu button (on the Panel) > System settings > Packages, or type redhat-config-packages at the shell prompt.

The interface for this application is similar to the one used during installation. Packages are divided into package groups, which contain a list of standard packages and extra packages that have common functionality. For example, the Graphical Internet group contains a Web browser, email client, and other graphical programs used to connect to the Internet. The standard packages cannot be selected for removal unless the entire package group is removed. The extra packages are optional packages that can be selected for installation or removal, as long as the package group is selected.

The main window shows a list of package groups. If the package group has a checkmark in the checkbox beside it, packages from that group are currently installed. To view the individual packages list for a group, click the Details button beside it. The individual packages with a checkmark beside them are currently installed.

Click To expand
Figure 6-2: The Package Management Tools

Installing Packages

To install the standard packages in a package group that is not currently installed, check the checkbox beside it. To customize the packages to be installed within the group, click the Details button beside it. The list of standard and extra packages is displayed, as shown in Figure 6-3. Clicking on the package name displays at the bottom of the window the amount of disk space required to install the package. Checking the checkbox beside the package name marks it for installation.

Click To expand
Figure 6-3: Individual package selection

You can also select individual packages from already installed package groups by clicking the Details button and checking any of the extra packages not already installed.

After selecting package groups and individual packages to install, click the Update button on the main window. The application will then compute the amount of disk space required to install the packages as well as any package dependencies and display a summary window. If there are package dependencies, they will be automatically added to the list of packages to install. Click the Show Details button to view the complete list of packages to be installed.

Click Continue to start the installation process. When it is finished, an Update Complete message will appear.

Click To expand
Figure 6-4: Package Installation Summary
Click To expand
Figure 6-5: Package Removal Summary
Tip

If you use Nautilus to browse the files and directories on your computer, you can also use it to install packages. In Nautilus, go to the directory that contains an RPM package (they usually end in .rpm) and double-click on the RPM icon.

Removing Packages

To remove all the packages installed within a package group, uncheck the checkbox beside it. To remove individual packages, click the Details button beside the package group and uncheck the individual packages.

When you are finished selecting packages to remove, click the Update button in the main window. The application computes the amount of disk space that will be freed, as well as the software package dependencies. If other packages depend on the packages you selected to remove, they will be automatically added to the list of packages to be removed. Click the Show Details button to view the list of packages to be removed.

Click Continue to start the removal process. When it is finished, an Update Complete message will appear.

Tip

You can combine the installation and removal of packages by selecting package groups/packages to be installed/removed and then clicking Update. The Completed System Preparation window will display the number of packages to be installed and removed.


Chapter 7: Users and Groups

Control of users and groups is a core element of Red Hat Linux system administration. Users can be either people, meaning accounts tied to physical users, or logical users, meaning accounts that exist for specific applications to use. Both types of users have a unique User ID (UID) and Group ID (GID).

Groups are logical expressions of organization. Groups tie users together, giving them permissions to read, write, or execute files. When a file is created, it is assigned a user and group. It is also assigned separate read, write, and execute permissions for the file’s owner, group, and everyone else. The user and group of a particular file, as well as the access permissions on the file, can be changed by root or, in most cases, by the creator of the file. Proper management of users and groups and effective management of file permissions are among the most important tasks a system administrator undertakes in the course of his or her duties.

Tools for User and Group Creation

Managing users and groups can be a tedious task, but Red Hat Linux provides a few tools and conventions to make management easier for administrators. You can use tools like useradd or groupadd to create new users and groups from the shell prompt.

The “Modifying User Properties” section of this chapter explains file permission concepts and walks you through the command-line steps for managing users. You can also use the graphical User Manager tool, described in the “User and Group Creation” section of this chapter.


Standard Users

Table 7-1 shows the standard users set up by the installation process in the /etc/passwd file. The Group ID (GID) in this table is the primary group for the user. See the next section for a listing of standard groups.

Table 7-1: Standard users
User | UID | GID | Home directory | Shell
root | 0 | 0 | /root | /bin/bash
bin | 1 | 1 | /bin | /sbin/nologin
daemon | 2 | 2 | /sbin | /sbin/nologin
adm | 3 | 4 | /var/adm | /sbin/nologin
lp | 4 | 7 | /var/spool/lpd | /sbin/nologin
sync | 5 | 0 | /sbin | /bin/sync
shutdown | 6 | 0 | /sbin | /sbin/shutdown
halt | 7 | 0 | /sbin | /sbin/halt
mail | 8 | 12 | /var/spool/mail | /sbin/nologin
news | 9 | 13 | /var/spool/news |
uucp | 10 | 14 | /var/spool/uucp | /sbin/nologin
operator | 11 | 0 | /root | /sbin/nologin
games | 12 | 100 | /usr/games | /sbin/nologin
gopher | 13 | 30 | /usr/lib/gopher-data | /sbin/nologin
ftp | 14 | 50 | /var/ftp | /sbin/nologin
nobody | 99 | 99 | / | /sbin/nologin
vcsa | 69 | 69 | /dev | /sbin/nologin
rpm | 37 | 37 | /var/lib/rpm | /bin/bash
wnn | 49 | 49 | /var/lib/wnn | /bin/bash
ntp | 38 | 38 | /etc/ntp | /sbin/nologin
ntp | 38 | 38 | /etc/ntp | /sbin/nologin
nscd | 28 | 28 | / | /bin/false
apache | 48 | 48 | /var/www | /bin/false
mysql | 27 | 27 | /var/lib/mysql | /bin/bash
mailnull | 47 | 47 | /var/spool/mqueue | /sbin/nologin
smmsp | 51 | 51 | /var/spool/mqueue | /sbin/nologin
rpc | 32 | 32 | / | /sbin/nologin
xfs | 43 | 43 | /etc/X11/fs | /sbin/nologin
gdm | 42 | 42 | /var/gdm | /sbin/nologin
rpcuser | 29 | 29 | /var/lib/nfs | /sbin/nologin
nsfnobody | 65534 | 65534 | /var/lib/nfs | /sbin/nologin
ident | 98 | 98 | / | /sbin/nologin
radvd | 75 | 75 | / | /bin/false
sshd | 74 | 74 | /var/empty/sshd | /sbin/nologin
postgres | 26 | 26 | /var/lib/pgsql | /bin/bash
squid | 23 | 23 | /var/spool/squid | /dev/null
named | 25 | 25 | /var/named | /bin/false
pcap | 77 | 77 | /var/arpwatch | /sbin/nologin
amanda | 33 | 6 | var/lib/amanda/ | /bin/bash
mailman | 41 | 41 | /var/mailman | /bin/false
netdump | 34 | 34 | /var/crash | /bin/bash
ldap | 55 | 55 | /var/lib/ldap | /bin/false
postfix | 89 | 89 | /var/spool/postfix | /bin/true
privoxy | 100 | 101 | /etc/privoxy |
Pvm | 24 | 24 | /usr/share/pvm3 | /bin/bash


Standard Groups

Table 7-2 shows the standard groups set up by the installation program. Groups are stored on Red Hat Linux in the /etc/group file.

Table 7-2: Standard groups
Group | GID | Members
root | 0 | root
bin | 1 | root, bin, daemon
daemon | 2 | root, bin, daemon
sys | 3 | root, bin, adm
adm | 4 | root, adm, daemon
tty | 5 |
disk | 6 | root
lp | 7 | daemon, lp
mem | 8 |
kmem | 9 |
wheel | 10 | root
mail | 12 | mail
news | 13 | news
uucp | 14 | uucp
man | 15 |
games | 20 |
gopher | 30 |
dip | 40 |
ftp | 50 |
lock | 54 |
nobody | 99 |
users | 100 |
slocate | 21 |
floppy | 19 |
vcsa | 69 |
rpm | 37 | rpm
utmp | 22 |
wnn | 49 |
ntp | 38 |
nscd | 28 |
apache | 48 |
mysql | 27 |
mailnull | 47 |
smmsp | 51 |
rpc | 32 |
xfs | 43 |
gdm | 42 |
rpcuser | 29 |
nfsnobody | 65534 |
ident | 98 |
radvd | 75 |
sshd | 74 |
postgres | 26 |
squid | 23 |
named | 25 |
pcap | 77 |
wine | 66 |
Mailman | 41 |
netdump | 34 |
ldap | 55 |
postdrop | 90 |
postfix | 89 |
privoxy | 101 |
pvm | 24 |


User Private Groups

Red Hat Linux uses a user private group (UPG) scheme, which makes UNIX groups easier to use. The UPG scheme does not add or change anything in the standard UNIX way of handling groups; it simply offers a new convention. Whenever you create a new user, by default, that user has a unique group. The scheme works as follows.

User Private Group

Every user has a primary group; the user is the only member of that group.

umask = 002

Traditionally on UNIX systems, the umask is 022, which prevents other users and other members of a user’s primary group from modifying a user’s files. Since every user has their own private group in the UPG scheme, this “group protection” is not needed. A umask of 002 will prevent users from modifying other users’ private files. The umask is set in /etc/profile.

setgid bit on Directories

If you set the setgid bit on a directory (with chmod g+s directory), files created in that directory will have their group set to the directory’s group.

Many IT organizations like to create a group for each major project and then assign people to the group if they need to access that group’s files. Using this traditional scheme, managing files has been difficult because when someone creates a file, it is associated with the primary group to which the individual belongs. When a single person works on multiple projects, it is difficult to associate the right files with the right group. Using the UPG scheme, however, groups are automatically assigned to files created within a directory with the setgid bit set, which makes managing group projects that share a common directory very simple.

For example, say you have a big project called devel, with many people editing the devel files in a devel directory. Make a group called devel, chgrp the devel directory so that it belongs to the devel group devel, and add all of the devel users to the devel group.

You can add a user to a group using the graphical User Manager tool (see the “User and Group Configuration” section later in this chapter), or, if you prefer to use the command line, use the /usr/sbin/groupadd groupname command to create a group. The /usr/bin/gpasswd -a loginname groupname command will add a user loginname to a group. (See the groupadd and gpasswd man pages if you need more information on their options.) The /etc/group file contains the group information for your system. If you created the devel group, added users to the devel group, changed the group for devel directory to the devel group, and set the setgid bit for the devel directory, all devel users will be able to edit the devel files and create new files in the devel directory. The files they create will always retain their devel group status, so other devel users will always be able to edit them.

If you have multiple projects like devel and users who are working on multiple projects, these users will never have to change their umask or group when they move from project to project. If set correctly, the setgid bit on each project’s main directory “selects” the proper group for all files created in that directory. Since each user’s home directory is owned by the user and his or her private group, it is safe to set the setgid bit on the home directory. However, by default, files are created with the primary group of the user, so the setgid bit would be redundant.

User Private Group Rationale

Although the User Private Group (UPG) has existed in Red Hat Linux for quite some time, many people still have questions about it, such as why UPG is necessary. To illustrate its use, consider the following scenario.

You would like to have a group of people work on a set of files in the /usr/lib/emacs/site-lisp/ directory. You trust a few people to modify the directory but certainly not everyone. So first create an emacs group:

/usr/sbin/groupadd emacs

In order to associate the contents of the directory with the emacs group, type:

chown -R root.emacs /usr/lib/emacs/site-lisp

Now, it is possible to add the proper users to the group with gpasswd:

/usr/bin/gpasswd -a              username         emacs

Allow the users to actually create files in the directory with the following command:

chmod 775 /usr/lib/emacs/site-lisp

When a user creates a new file, it is assigned the group of the user’s default private group. To prevent this, use the following command, which causes everything in the directory to be created with the emacs group:

chmod 2775 /usr/lib/emacs/site-lisp

If the new file needs to be mode 664 for another user in the emacs group to be able to edit it, make the default umask 002.

At this point, by making the default umask 002, you can easily set up groups that users can take advantage of without any extra work every time users write files to the group’s common directory. Just create the group, add the users, and do the above chown and chmod on the group’s directories.


Shadow Utilities

If you are in a multi-user environment and not using a networked authentication scheme such as Kerberos, consider using Shadow Utilities (also known as shadow passwords) for the enhanced protection offered for your system’s authentication files. During the installation of Red Hat Linux, shadow password protection for your system is enabled by default, as are MD5 passwords (an alternative and arguably more secure method of encrypting passwords for storage on your system).

The use of shadow passwords offers a few distinct advantages over the previous standard of storing passwords on UNIX and Linux systems, including:

  • Improved system security by moving the encrypted passwords (normally found in /etc/passwd) to /etc/shadow, which is readable only by root

  • Information concerning password aging (how long it has been since a password was last changed)

  • Control over how long a password can remain unchanged before the user is required to change it

  • The ability to use the /etc/login.defs file to enforce a security policy, especially concerning password aging

The shadow-utils package contains a number of utilities that support:

  • Conversion from normal to shadow passwords and back (pwconv, pwunconv)

  • Verification of the password, group, and associated shadow files (pwck, grpck)

  • Industry-standard methods of adding, deleting, and modifying user accounts (useradd, usermod, and userdel)

  • Industry-standard methods of adding, deleting, and modifying user groups (groupadd, groupmod, and groupdel)

  • Industry-standard method of administering the /etc/group file using gpasswd

There are some additional points of interest concerning these utilities:

  • The utilities will work properly whether shadowing is enabled or not.

  • The utilities have been slightly modified to support Red Hat’s user private group scheme. For a description of the modifications, see the useradd man page. For more information on user private groups, see the “User Private Groups” section of this chapter.

  • The adduser script has been replaced with a symbolic link to /usr/sbin/useradd.

  • The tools in the shadow-utils package are not Kerberos-, NIS-, Hesiod-, or LDAP-enabled. New users will be local only. For more information on Kerberos and LDAP, see Chapters 17 and 23.


User and Group Configuration

User Manager allows you to view, modify, add, and delete local users and groups. To use User Manager, you must be running the X Window System, have root privileges, and have the redhat-config-users RPM package installed. To start User Manager from the desktop, go to the Main Menu Button (on the Panel) > System Settings > Users & Groups or type redhat-config-users at a shell prompt (for example, in an XTerm or a GNOME terminal).

Click To expand
Figure 7-1: User Manager

To view a list of all local users on the system, click the Users tab. To view a list of all local groups on the system, click the Groups tab. If you need to find a specific user or group, type the first few letters of the name in the Filter by field. Press Enter or click the Apply filter button. The filtered list will be displayed. To sort the users or groups, click on the column name. The users or groups will be sorted by the value of that column.

Red Hat Linux reserves user IDs above 500 for system users. By default, User Manager does not display system users. To view all users, including the system users, uncheck Preferences > Filter system users and groups from the pull-down menu.

Adding a New User

To add a new user, click the New User button. A window as shown in Figure 7-2 will appear. Type the username and full name for the new user in the appropriate fields. Type the user’s password in the Password and Confirm Password fields. The password must be at least six characters.

Figure 7-2: New User
Tip

The longer the user’s password, the more difficult it is for someone else to guess it and log in to the user’s account without permission. It is also recommended that the password not be based on a word and that the password be a combination of letters, numbers, and special characters.

Select a login shell. If you are not sure which shell to select, accept the default value of /bin/bash. The default home directory is /home/username. You can change the home directory that is created for the user, or you can choose not to create the home directory by unselecting Create home directory.

Red Hat Linux uses a user private group (UPG) scheme. The UPG scheme does not add or change anything in the standard UNIX way of handling groups; it simply offers a new convention. Whenever you create a new user, by default, a unique group with the same name as the user is created. If you do not want to create this group, unselect Create a private group for the user.

To specify a user ID for the user, select Specify user ID manually. If the option is not selected, the next available user ID starting with number 500 will be assigned to the new user. Red Hat Linux reserves user IDs above 500 for system users.

Click OK to create the user.

To configure more advanced user properties such as password expiration, modify the user’s properties after adding the user. Refer to the “Modifying User Properties” section of this chapter for more information. To add the user to more user groups, click the User tab, select the user, and click Properties. In the User Properties window, select the Groups tab. Select the groups that you want the user to be a member of, select the primary group for the user, and click OK.

Modifying User Properties

To view the properties of an existing user, click the Users tab, select the user from the user list, and click Properties from the button menu (or choose File > Properties from the pull-down menu). A window similar to the one shown in Figure 7-3 will appear.

Click To expand
Figure 7-3: User Properties

The User Properties window is divided into tabbed pages.

User Data

Basic user information configured when you added the user. Use this tab to change the user’s full name, password, home directory, and/or login shell.

Account Info

Select Enable account expiration if you want the account to expire on a certain date. Enter the date in the provided fields. Select User account is locked to lock the user account so that the user can not log in to the system.

Password Info

This tab shows the date that the user last changed his or her password. To force the user to change his or her password after a certain number of days, select Enable password expiration. You can also set the number of days before the user is allowed to change the password, the number of days before the user is warned to change the password, and days before the account becomes inactive.

Groups

Select the groups that you want the user to be a member of and the user’s primary group.

Adding a New Group

To add a new user group, click the New Group button. A window similar to the one shown in Figure 7-4 will appear. Type the name of the new group to create. To specify a group ID for the new group, select Specify group ID manually and select the GID. Red Hat Linux reserves group IDs lower than 500 for system groups. Click OK to create the group. The new group will appear in the group list.

Figure 7-4: New Group

To add users to the group, see the next section.

Modifying Group Properties

To view the properties of an existing group, select the group from the group list and click Properties from the button menu (or choose File > Properties from the pull-down menu). A window similar to the one shown in Figure 7-5 will appear.

Figure 7-5: Group properties

The Group Users tab displays which users are members of the group. Select additional users to add them to the group, and unselect users to remove from the group. Click OK or Apply to modify the users in the group.


Chapter 8: Printer Configuration

Printer configuration has long been a headache for Linux and UNIX administrators. Red Hat Linux provides the Printer Configuration Tool for streamlining the task of configuring LPRng, the default printing system. As an alternative to LPRng, Red Hat Linux also includes the Common Unix Printing System (CUPS), which can be configured through a Web interface.

The Printer Configuration Tool allows users to configure a printer in Red Hat Linux. It helps maintain the /etc/printcap configuration file, print spool directories, and print filters. Starting with version 8.0, Red Hat Linux ships with two printer systems. The Printer Configuration Tool configures the printing system called LPRng. LPRng is also the default printing system. This chapter focuses on using the Printer Configuration Tool to configure LPRng. For more information on the alternate printing system called CUPS, refer to the “Configuring CUPS” section of this chapter.

To use the Printer Configuration Tool, you must have root privileges. To start the application, select Main Menu Button (on the Panel) > System Settings > Printing, or type redhat-config-printer. This command automatically determines whether to run the graphical or text-based version. You can also force the Printer Configuration Tool to run as a text-based application by using the command redhat-config-printer-tui from a shell prompt. To add a printer using the command-line version, refer to the “Command-Line Configuration” section of this chapter.

Warning

Do not edit the /etc/printcap file. Each time the printer daemon (lpd) is started or restarted, a new /etc/printcap file is dynamically created.

If you want to add a printer without using the Printer Configuration Tool, edit the /etc/printcap.local file. The entries in /etc/printcap.local are not displayed in the Printer Configuration Tool but are read by the printer daemon. If you upgrade your system from a previous version of Red Hat Linux, your existing configuration file is converted to the new format used by this application. Each time a new configuration file is generated, the old file is saved as /etc/printcap.old.

Click To expand
Figure 8-1: The Printer Configuration Tool

Five types of print queues can be configured:

  • Local Printer — a printer attached directly to your computer through a parallel or USB port. In the main printer list as shown in Figure 8-1, the Queue Type for a local printer is set to LOCAL.

  • Unix Printer (lpd Spool) — a printer attached to a different UNIX system that can be accessed over a TCP/IP network (for example, a printer attached to another Red Hat Linux system on your network). In the main printer list as shown in Figure 8-1, the Queue Type for a remote UNIX printer is set to LPD.

  • Windows Printer (SMB) — a printer attached to a different system that is sharing a printer over a SMB network (for example, a printer attached to a Microsoft Windows machine). In the main printer list as shown in Figure 8-1, the Queue Type for a remote Windows printer is set to SMB.

  • Novell Printer (NCP Queue) — a printer attached to a different system that uses Novell’s NetWare network technology. In the main printer list as shown in Figure 8-1, the Queue Type for a remote Novell printer is set to NCP.

  • JetDirect Printer — a printer connected directly to the network through HP JetDirect instead of to a computer. In the main printer list as shown in Figure 8-1, the Queue Type for a JetDirect printer is set to JETDIRECT.

    Note

    If you add a new print queue or modify an existing one, you need to restart the printer daemon (lpd) for the changes to take effect.

Clicking the Apply button saves any changes that you have made and restarts the printer daemon. The changes are not written to the /etc/printcap configuration file until the printer daemon (lpd) is restarted. Alternatively, you can choose File > Save Changes and then choose File > Restart lpd to save your changes and then restart the printer daemon.

If a printer appears in the main printer list with the Queue Type set to INVALID, the Printer Configuration Tool is missing options that are required for the printer to function properly. To remove this printer from the list, select it from the list and click the Delete button.

Adding a Local Printer

To add a local printer such as one attached to the parallel or USB port of your computer, click the New button in the main Printer Configuration Tool window. The window shown in Figure 8-2 will appear. Click Next to proceed.

Click To expand
Figure 8-2: Adding a printer

You will then see the screen shown in Figure 8-3. Enter a unique name for the printer in the Queue Name text field. This can be any descriptive name for your printer. The printer name cannot contain spaces and must begin with a letter a through z or A through Z. The valid characters are a through z, A through Z, 0 through 9, -, and _ (underscore). Select Local Printer from the Queue Type menu and click Next.

The Printer Configuration Tool attempts to detect your printer device and model as shown in Figure 8-4. If your printer device is not shown, click Custom Device. Type the name of your printer device and click OK to add it to the printer device list. A printer device attached to the parallel port is usually referred to as /dev/lp0. A printer device attached to the USB port is usually referred to as /dev/usblp0. If your printer model does not appear, you will be given the opportunity to select it in the next step. Click Next to continue.

Click To expand
Figure 8-3: Adding a local printer
Click To expand
Figure 8-4: Local printer device

If the Printer Configuration Tool detects your printer model, it displays the recommended print driver. Skip to the section “Selecting the Print Driver and Finishing” to continue.

Adding a Remote UNIX Printer

To add a remote UNIX printer, such as one attached to a different Linux system on the same network, click the New button in the main Printer Configuration Tool window. The window shown in Figure 8-2 will appear. Click Next to proceed.

You will then see the screen shown in Figure 8-5. Enter a unique name for the printer in the Queue Name text field. The printer name cannot contain spaces and must begin with a letter a through z or A through Z. The valid characters are a through z, A through Z, 0 through 9, -, and _ (underscore). Select Unix Printer from the Queue Type menu and click Next.

Text fields for the following options appear as shown in Figure 8-6:

  • Server — The hostname or IP address of the remote machine to which the printer is attached.

  • Queue — The remote printer queue. The default printer queue is usually lp. By default, the Strict RFC1179 Compliance option is not chosen. If you are having problems printing to a non-Linux lpd queue, choose this option to disable enhanced LPRng printing features.

Click Next to continue.

Click To expand
Figure 8-5: Adding a remote printer

The next step is to select the type of printer that is connected to the remote system. Skip to the section “Selecting the Print Driver and Finishing” to continue.

Click To expand
Figure 8-6: Choosing the printer server
Note

The remote machine must be configured to allow the local machine to print on the desired queue. As root, create the file /etc/hosts.lpd on the remote machine to which the printer is attached. On separate lines in the file, add the IP address or hostname of each machine that should have printing privileges.

Adding a Samba (SMB) Printer

To add a printer that is accessed using the SMB protocol (such as a printer attached to a Microsoft Windows system), click the New button in the main Printer Configuration Tool window. The window shown in Figure 8-2 will appear. Click Next to proceed.

You will see the screen shown in Figure 8-7. Enter a unique name for the printer in the Queue Name text field. The printer name cannot contain spaces and must begin with a letter a through z or A through Z. The valid characters are a through z, A through Z, 0 through 9, -, and _ (underscore). Select Windows Printer from the Queue Type menu and click Next. If the printer is attached to a Microsoft Windows system, choose this queue type.

Click To expand
Figure 8-7: Adding an SMB printer

Text fields for the following options appear as shown in Figure 8-8:

  • Share — The name of the shared printer on which you want to print. This name must be the same name defined as the Samba printer on the remote Windows machine. Notice the syntax of //machinename/sharename.

  • User — The name of the user you must log in as to access the printer. This user must exist on the Windows system, and the user must have permission to access the printer. The default user name is typically guest for Windows servers, or nobody for Samba servers.

  • Host IP — The hostname or IP address of the remote system that is sharing the SMB printer.

  • Password — The password (if required) for the user specified in the User field.

  • Workgroup — The name of the workgroup on the machine running Samba.

Click the Translate \n => \r\n button to translate the end-of-line characters to a form that is readable by a Microsoft Windows system. Click Next to continue.

The next step is to select the type of printer that is connected to the remote SMB system. Skip to the section “Selecting the Print Driver and Finishing” to continue.

Click To expand
Figure 8-8: Choosing the print server
Note

If you require a username and password for an SMB (LAN Manager) print queue, they are stored unencrypted in the spool directory, which only root or lp may read. Thus, it is possible for others to learn the username and password if they have root access. To avoid this, the username and password to access the printer should be different from the username and password used for the user’s account on the local Red Hat Linux system. If they are different, then the only possible security compromise would be unauthorized use of the printer. If there are file shares from the SMB server, it is recommended that they also use a different password from the one for the print queue.

Adding a Novell NetWare (NCP) Printer

To add a Novell NetWare (NCP) printer, click the New button in the main Printer Configuration Tool window. The window shown in Figure 8-2 will appear. Click Next to proceed.

You will see the screen shown in Figure 8-9. Enter a unique name for the printer in the Queue Name text field. The printer name cannot contain spaces and must begin with a letter a through z or A through Z. The valid characters are a through z, A through Z, 0 through 9, -, and _ (underscore). Select Novell Printer from the Queue Type menu and click Next.

Text fields for the following options appear below the Queue Type menu as shown in Figure 8-10:

  • Server — The hostname or IP address of the NCP system to which the printer is attached.

  • Queue — The remote queue for the printer on the NCP system.

  • User — The name of the user you must log in as to access the printer.

  • Password — The password for the user specified in the User field above.

    Click To expand
    Figure 8-9: Adding an NCP printer

    Click To expand
    Figure 8-10: Choosing the print server

The next step is to select the type of printer that is connected to the remote NCP system. Skip to the section “Selecting the Print Driver and Finishing” to continue.

Note

If you require a username and password for a NCP (NetWare) print queue, they are stored. Thus, it is possible for another person to learn the username and password. To avoid this, the username and password to use the printer should be different from the username and password used for the user’s account on the local Red Hat Linux system. If they are different, then the only possible security compromise would be unauthorized use of the printer.

Adding a JetDirect Printer

To add a JetDirect printer, click the New button in the main Printer Configuration Tool window. The window shown in Figure 8-2 will appear. Click Next to proceed.

You will see the screen shown in Figure 8-11. Enter a unique name for the printer in the Queue Name text field. The printer name cannot contain spaces and must begin with a letter a through z or A through Z. The valid characters are a through z, A through Z, 0 through 9, -, and _ (underscore). Select JetDirect Printer from the Queue Type menu and click Next.

Click To expand
Figure 8-11: Adding a JetDirect printer

Text fields for the following options appear below the Queue Type menu as shown in Figure 8-12:

  • Printer IP — The hostname or IP address of the JetDirect printer.

  • Port — The port on the JetDirect printer that is listening for print jobs. The default port is 9100.

    Click To expand
    Figure 8-12: Choosing a print server

The next step is to select the type of printer that is connected to the JetDirect system. Skip to the section “Selecting the Print Driver and Finishing” to continue.


Selecting the Print Driver and Finishing

After you’ve selected the queue type of the printer, the next step in adding a printer is to select the print driver. You will see a window similar to the one shown in Figure 8-13. If you are configuring a local printer and the model was autodetected, the recommended driver is autoselected and marked with an asterisk (*). If it was not autodetected, select the driver from the list. The printers are divided by manufacturers. Click the arrow beside the manufacturer for your printer. Find your printer from the expanded list and click the arrow beside the printer name. A list of drivers for your printer will appear. Select one.

Tip

To learn more about the print drivers, go to http://www.linuxprinting.org/printer_list.cgi.
Tip

You can select a different print driver after adding a printer by starting the Printer Configuration Tool, selecting the printer from the list, clicking Edit, clicking the Driver tab, selecting a different print driver, and applying the changes.

Click To expand
Figure 8-13: Selecting a print driver

The print driver processes the data that you want to print into a format the printer can understand. Since a local printer is attached directly to your computer, you need to select a print driver to process the data that is sent to the printer. If you are configuring a remote printer (LPD, SMB, or NCP), the remote print server usually has its own print driver. If you select an additional print driver on your local computer, the data will be filtered more than once, and the data will be converted to a format that the printer cannot understand. To make sure the data is not filtered more than once, first try selecting Raw Print Queue or PostScript Printer if you are configuring a remote printer.

After applying the changes, print a test page to test this configuration. If the test fails, the remote print server might not have a print driver configured. Try selecting a print driver according to the manufacturer and model of the remote printer, applying the changes, and printing another test page.

Confirming Printer Configuration

The last step is to confirm your printer configuration. Click Apply to add the print queue if the settings are correct. Click Back to modify the printer configuration if necessary. Click the Apply button in the main window to save your changes to the /etc/printcap configuration file and restart the printer daemon (lpd). After applying the changes, print a test page to ensure that the configuration is correct. Refer to the section “Printing a Test Page” for details.

If you need to print characters beyond the basic ASCII set (including those used for languages such as Japanese), you need to go to your driver options and select Prerender PostScript. Refer to the section “Modifying Existing Printers” for details. You can also configure options such as paper size if you edit the print queue after adding it.

Printing a Test Page

After you have configured your printer, print a test page to make sure the printer is functioning properly. To print a test page, select the printer that you want to test from the printer list and select the appropriate test page from the Test pull-down menu. If you change the print driver or modify the driver options, print a test page to test the different configuration.

Modifying Existing Printers

To delete an existing printer, select the printer and click the Delete button on the toolbar. The printer will be removed from the printer list. Click Apply to save the changes and restart the printer daemon.

To set the default printer, select the printer from the printer list and click the Default button on the toolbar. The default printer icon appears in the first column of the printer list beside the default printer.

If you want to modify an imported printer’s settings, note that you cannot do so directly. You must override the printer. You can override only an imported printer that has been imported using the alchemist libraries. Imported printers have a symbol beside them in the first column of the printer list. To override the printer, select the printer and choose File > Override Queue from the pull-down menu. After you’ve overridden a printer, the original imported printer will have a symbol beside it in the first column of the printer list.

After adding your printer(s), you can edit settings by selecting the printer from the printer list and clicking the Edit button. The tabbed window shown in Figure 8-14 will appear. The window contains the current values for the printer that you selected to edit. Make any changes, and click OK. Click Apply in the main Printer Configuration Tool window to save the changes and restart the printer daemon.

Names and Aliases

If you want to rename a printer, change the value of Queue Name in the Names and Aliases tab. Click OK to return to the main window. The name of the printer should change in the printer list. Click Apply to save the change and restart the printer daemon.

A printer alias is an alternate name for a printer. To add an alias for an existing printer, click the Add button in the Name and Aliases tab, enter the name of the alias, and click OK. Click OK again to return to the main window. Click Apply to save the aliases and restart the printer daemon. A printer can have more than one alias.

Queue Type

The Queue Type tab shows the queue type that you selected when adding the printer and its settings. You can change the queue type of the printer or just change the settings. After making modifications, click OK to return to the main window. Click Apply to save the changes and restart the printer daemon. Depending on which queue type you choose, you will see different

Click To expand
Figure 8-14: Editing a printer

options. Refer to the section of this chapter that describes your particular printer; options unique to your printer are listed there.

Driver

The Driver tab shows which print driver is currently being used. This is the same list that you used when you added the printer. If you change the print driver, click OK to return to the main window. Click Apply to save the changes and restart the printer daemon.

Driver Options

The Driver Options tab displays advanced printer options. Options vary for each print driver. Common options include:

  • Select Send Form-Feed (FF) if the last page of your print job is not ejected from the printer (for example, the form feed light flashes). If selecting this option does not force the last page out of the printer, try selecting Send End-of-Transmission (EOT) instead. Some printers require both Send Form-Feed (FF) and Send End-of-Transmission (EOT) to eject the last page.

  • Select Send End-of-Transmission (EOT) if sending a form-feed does not work. Refer to Send FF above.

  • Select Assume Unknown Data is Text if your print driver does not recognize some of the data sent to it. Select it only if you are having problems printing. If this option is selected, the print driver will assume that any data that it cannot recognize is text and try to print it as text. If you select this option and Convert Text to PostScript, the print driver will assume the unknown data is text and then convert it to PostScript.

  • Select Prerender PostScript if you are printing characters beyond the basic ASCII set (such as Japanese characters) but they are not printing correctly. This option will prerender nonstandard PostScript fonts so that they print correctly. If your printer does not support the fonts you are trying to print, try selecting this option. For example, you should select this option if you are printing Japanese fonts to a non-Japanese printer. Extra time is required to perform this action. Do not choose it unless you are having problems printing the correct fonts. You should also select this option if your printer cannot handle PostScript level 3. This option converts it to PostScript level 1.

  • Convert Text to Postscript is selected by default. If your printer can print plain text, try unselecting this when printing plain text documents to decrease the time it takes to print.

  • Page Size allows you to select the paper size for your printer, such as US Letter, US Legal, A3, and A4.

  • Effective Filter Locale defaults to C. If you are printing Japanese characters, select ja_JP. Otherwise, accept the default of C.

  • Media Source defaults to Printer default. Change this option to use paper from a different tray.

If you modify the driver options, click OK to return to the main window. Click Apply to save the changes and restart the printer daemon.

Saving the Configuration File

When you save your printer configuration using the Printer Configuration Tool, it creates its own configuration file, which is used to create the /etc/printcap file that the printer daemon (lpd) reads. You can use the command-line options to save or restore this file. If you save your /etc/printcap file and overwrite your existing /etc/printcap file with the saved file, your printer configuration will not be restored. Each time the printer daemon is restarted, it creates a new /etc/printcap file from the special Printer Configuration Tool configuration file. If you have configured a backup system for your configuration files, you should use the following method to save your printer configuration. If you added any custom settings in the /etc/printcap.local file, you should save it as part of your backup system also.

To save your printer configuration, type this command as root:

/usr/sbin/redhat-config-printer-tui --Xexport > settings.xml

Your configuration is saved to the file settings.xml. If you save this file, you can restore your printer settings. This is useful if your printer configuration is deleted, you reinstall Red Hat Linux and no longer have your printer configuration file, or you want to use the same printer configuration on multiple systems. To restore the configuration, type this command as root:

/usr/sbin/redhat-config-printer-tui --Ximport < settings.xml

If you already have a configuration file (you have configured one or more printers on the system already) and you try to import another configuration file, the existing configuration file will be overwritten. If you want to keep your existing configuration and add the configuration in the saved file, you can merge the files with the following command (as root):

/usr/sbin/redhat-config-printer-tui --Ximport --merge < settings.xml

Your printer list will then consist of the printers you configured on the system as well as the printers you imported from the saved configuration file. If the imported configuration file has a print queue with the same name as an existing print queue on the system, the print queue from the imported file will override the existing printer.

After importing the configuration file (with or without the merge command), you must restart the printer daemon with the command /sbin/service lpd restart or by starting the Printer Configuration Tool and clicking Apply.


Command-Line Configuration

If you do not have X installed and you do not want to use the text-based version of the Printer Configuration Tool, you can add a printer using the command line. This method is useful if you want to add a printer from a script or in the process of a kickstart installation.

Adding a Printer

To add a printer, type this command:

redhat-config-printer-tui --Xadd-local options

Following are the available options:

--device=node

Required. The device node to use. For example, /dev/lp0.

--make=make

Required. The IEEE 1284 MANUFACTURER string or the printer manufacturer’s name as in the foomatic database if the manufacturer string is not available.

--model=model

Required. The IEEE 1284 MODEL string or the printer model in the foomatic database if the model string is not available.

--name=name

Optional. The name to be given to the new queue. If one is not given, a name based on the device node (such as lp0) will be used.

--as-default

Optional. Set this as the default queue.

After adding the printer, use the following command to start/restart the printer daemon, lpd:

service lpd restart

Removing a Printer

You can also remove a printer queue with the command line. To remove a printer queue, type the following command:

redhat-config-printer-tui --Xremove-local options

Following are the available options:

--device=node

Required. The device node used (for example, /dev/lp0).

--make=make

Required. The IEEE 1284 MANUFACTURER string, or (if none is available) the printer manufacturer’s name as in the foomatic database.

--model=model

Required. The IEEE 1284 MODEL string, or (if none is available) the printer model as in the foomatic database.

After removing the printer from the Printer Configuration Tool configuration, use the following command to restart the printer daemon for the changes to take effect:

service lpd restart

If you removed all printers and do not want to run the printer daemon anymore, execute the following command:

service lpd stop


Managing Your Print Jobs

When you send a print job to the printer daemon, such as printing a text file from Emacs or printing an image from The GIMP, the print job is added to the print spool queue. The print spool queue is a list of print jobs that have been sent to the printer and information about each print request such as the status of the request, the username of the person who sent the request, the hostname of the system that sent the request, the job number, and more. To view the list of print jobs in the print spool, open a shell prompt and type lpq. The last few lines will look similar to the following:

Rank     Owner/ID        Class    Job Files     Size    Time
active user@localhost+902  A    902 sample.txt  2050 01:20:46

To cancel a print job, find the job number of the request with the command lpq and then use the command lprm job number. For example, lprm 902 would cancel the print job in the previous example. You must have proper permissions to cancel a print job. You cannot cancel print jobs that were started by other users unless you are logged in as root on the machine to which the printer is attached.

You can also print a file directly from a shell prompt. For example, the command

lpr sample.txt

will print the text file sample.txt. The print filter determines what type of file it is and converts it to a format the printer can understand.


Configuring CUPS

CUPS (Common Unix Printing System) can be used instead of the default LPRng printing system. Some of the advantages of CUPS are:

  • Support for IPP (next-generation network printing protocol)

  • Autodetection of network printers

  • Web interface configuration tool

  • Support for PPD printer description files

  • Support for a wide range of printers

Switching Print Systems

To use CUPS instead of LPRng, run the Printer System Switcher application. Start it by selecting the Main Menu Button (on the Panel) > Extras > System Settings > Printer System Switcher, or type redhat-switch-printer at a shell prompt (for example, in an XTerm window or GNOME terminal window).

The program automatically detects if the X Window System is running. If it is running, the program starts in graphical mode as shown in Figure 8-15. If X is not detected, it starts in text mode. To force it to run in text mode, use the command redhat-switch-printer-nox.

If you selected CUPS, you must make sure the lpd service is stopped and CUPS is started:

/sbin/service lpd stop
/sbin/service cups start
Click To expand
Figure 8-15: Printer System Switcher

If you selected LPRng, you must make sure CUPS is stopped and the lpd service is started:

/sbin/service cups stop
/sbin/service lpd start

Also use chkconfig, ntsysv, or the Services Configuration Tool to configure your system to start CUPS automatically and disable the lpd service.

CUPS Configuration Interface

After starting the CUPS daemon, open a Web browser and connect to http://localhost:631 as shown in Figure 8-16.

Click To expand
Figure 8-16: CUPS configuration tool

To add a printer, click Manage Printers and then click the Add Printer button. For more information, click the Help button.


Additional Resources

To learn more about printing under Red Hat Linux, refer to the following resources.

Installed Documentation

  • man printcap — The man page for the /etc/printcap printer configuration file.

  • man lpr — The man page for the lpr command, which allows you to print files from the command line.

  • man lpd — The man page for the LPRng printer daemon.

  • man lprm — The man page for the command-line utility to remove print jobs from the LPRng spool queue.

  • man mpage — The man page for the command-line utility to print multiple pages on one sheet of paper.

  • man cupsd — The man page for the CUPS printer daemon.

  • man cupsd.conf — The man page for the CUPS printer daemon configuration file.

  • man classes.conf — The man page for the class configuration file for CUPS.

Useful Websites

  • http://www.linuxprinting.org — GNU/Linux Printing contains a large amount of information about printing in Linux.

  • http://www.cups.org/ — Documentation, FAQs, and pointers to newsgroups about CUPS.


Chapter 9: X Servers and Clients

The heart of Red Hat Linux is the kernel, but for many users, the face of the operating system is the graphical environment provided by the X Window System, also called simply X. This chapter is an introduction to the behind-the-scenes world of XFree86, the open-source implementation of X provided with Red Hat Linux.

The Power of X

Linux began as a powerful, server-based operating system, excelling at efficiently processing complicated programs requiring high CPU utilization and handling requests from hundreds or thousands of clients through network connections. However, because of its open nature and stability, Linux has quickly developed into a popular GUI-based operating system for workstations, both in the home or in the workplace.

In the UNIX world, windowing environments have existed for decades, predating many of the current mainstream operating systems. The X Window System is now the dominant graphical user interface (GUI) for UNIX-like operating systems. To create this GUI for the user, X uses a client-server architecture. An X server process is started, and X client processes can connect to it via a network or local loopback interface. The server process handles the communication with the hardware, such as the video card, monitor, keyboard, and mouse. The X client exists in the user space, issuing requests to the X server.

On Red Hat Linux systems, the XFree86 server fills the role of the X server. As a large-scope open-source software project, with hundreds of developers around the world, XFree86 features rapid development, a wide degree of support for various hardware devices and architectures, and the ability to run on different operating systems and platforms.

Most Red Hat Linux desktop users are unaware of the XFree86 server running on their system. They are much more concerned with the particular desktop environment in which they spend most of their time. The Red Hat Linux installation program does an excellent job of configuring your XFree86 server during the installation process, ensuring that X performs optimally when first started.

The X server performs many difficult tasks using a wide array of hardware, requiring detailed configuration. If some aspect of your system changes, such as the monitor or video card, XFree86 will need to be reconfigured. In addition, if you are troubleshooting a problem with XFree86 that cannot be solved using a configuration utility, such as the X Configuration Tool (redhat-config-xfree86), you may need to access its configuration file directly.

Tip

The X Configuration Tool is capable of configuring XFree86 while the X server is active. To activate the configuration program from the command line, type redhat-config-xfree86. To start the X Configuration Tool while in an active X session, go to the Main Menu Button (on the Panel) > System Settings > Display. After using the X Configuration Tool during an X session, you will need to log out of the current X session, then log back in for the changes to take effect.


XFree86

Red Hat Linux 8.0 uses XFree86 version 4.2 as the base X Window System, which includes the various necessary X libraries, fonts, utilities, documentation, and development tools.

Note

Red Hat no longer provides the older XFree86 version 3 server packages. Before upgrading to the latest version of Red Hat Linux, be sure that your video card is compatible with XFree86 version 4 by checking the Red Hat Hardware Compatibility List located at http://hardware.redhat.com/hcl/.

The X server includes many cutting-edge XFree86 technology enhancements such as hardware 3D acceleration support, the XRender extension for anti-aliased fonts, a modular driver-based design, support for modern video hardware and input devices, and many other features. The Red Hat Linux installation program installs the base components of XFree86. You may choose to install any optional XFree86 packages.

The X Window System resides primarily in two locations in the file system.

/usr/X11R6/ directory

A directory containing X client binaries (the bin directory), assorted header files (the include directory), libraries (the lib directory), man pages (the man directory), and various other X documentation (the /usr/X11R6/lib/X11/doc/ directory).

/etc/X11/ directory

The /etc/X11/ directory hierarchy contains all of the configuration files for the various components that make up the X Window System. This includes configuration files for the X server itself, the X font server (xfs), the X Display Manager (xdm), and many other base components.

Display managers such as gdm and kdm, as well as various window managers and other X tools, also store their configuration in this hierarchy. XFree86 version 4 server is a single binary executable — /usr/X11R6/bin/XFree86. This server dynamically loads various X server modules at runtime from the /usr/X11R6/lib/modules/ directory, including video drivers, font engine drivers, and other modules as needed. Some of these modules are automatically loaded by the server, whereas some are optional features that you must specify in the XFree86 server’s configuration file, /etc/X11/XF86Config, before they can be used. The video drivers are located in the /usr/X11R6/lib/modules/drivers/ directory. The DRI hardware accelerated 3D drivers are located in the /usr/X11R6/lib/modules/dri/ directory.

XFree86 Server Configuration Files

The XFree86 server configuration files are stored in the /etc/X11/ directory. The XFree86 version 4 server uses /etc/X11/XF86Config. When Red Hat Linux is installed, the configuration files for XFree86 are created using information gathered during the installation process.

While there is rarely a need to manually edit these files, it is useful to know about the various sections and optional parameters found in them. Each section begins with a Section section-name line and ends with an EndSection line. Within each of the sections, you will find several lines containing an option name and at least one option value, occasionally seen in quotes. The following list explores the most useful sections of an XFree86 version 4 file and the roles of various popular settings.

Device

Specifies information about the video card used by the system. You must have at least one Device section in your configuration file. You may have multiple Device sections in the case of multiple video cards or multiple settings that can run a single card. The following options are required or widely used:

  • BusID — Specifies the bus location of the video card. This option is necessary only for systems with multiple cards and must be set so that the Device section will use the proper settings for the correct card.

  • Driver — Tells XFree86 which driver to load in order to use the video card.

  • Identifier — Provides a unique name for this video card. Usually, this name is set to the exact name of the video card used in the Device section.

  • Screen — An optional setting used when a video card has more than one head, or connector, to go out to a separate monitor. If you have multiple monitors connected to one video card, separate Device sections must exist for each of them with a different Screen value for each Device section. The value accepted by this option is a number starting at 0 and increasing by one for each head on the video card.

  • VideoRam — The amount of RAM available on the video card in kilobytes. This setting is not normally necessary since the XFree86 server can usually probe the video card to autodetect the amount of video RAM. But since there are some video cards XFree86 cannot correctly autodetect, this option allows you to specify the amount of video RAM.

DRI

Direct Rendering Infrastructure (DRI) is an interface that primarily allows 3D software applications to take advantage of the 3D hardware acceleration capabilities on modern supported video hardware. In addition, DRI can improve 2D hardware acceleration performance when using drivers that have been enhanced to use the DRI for 2D operations. This section is ignored unless DRI is enabled in the Module section.

Note

Since different video cards use DRI in different ways, before changing any DRI values, read the /usr/X11R6/lib/X11/doc/README.DRI file for specific information about your particular video card.

Files

This section sets paths for services vital to the XFree86 server, such as the font path. Common options include:

  • FontPath — Sets the locations where the XFree86 server can find fonts. Different fixed paths to directories holding font files can be placed here, separated by commas. By default, Red Hat Linux uses xfs as the font server and points FontPath to unix/:7100. This tells the XFree86 server to obtain font information by using UNIX-domain sockets for inter-process communication (IPC). See the “Fonts” section of this chapter for more information concerning XFree86 and fonts.

  • ModulePath — Allows you to set up multiple directories to use for storing modules loaded by the XFree86 server.

  • RgbPath — Tells the XFree86 server where the RGB color database is located on the system. This database file defines all valid color names in XFree86 and ties them to specific RGB values.

InputDevice

Configures an input device such as a mouse or keyboard used to convey information to the system using the XFree86 server. Most systems have at least two InputDevice sections, keyboard and mouse. Each section includes these two lines:

  • Driver — Tells XFree86 the name of the driver to load to use the device.

  • Identifier — Sets the name of the device, usually the name of the device followed by a number, starting with 0 for the first device. For example, the first keyboard InputDevice would have an Identifier of Keyboard0.

Most InputDevice sections contain lines assigning specific options to that device. Each of these lines start with Option and contains the name of the option in quotes, followed by the value to assign to that option. Mice usually receive options such as Protocol, PS/2, and Device, which designates the mouse to use for this section. The InputDevice section is well commented, allowing you to configure additional options for your particular devices by uncommenting certain lines.

Module

Tells the XFree86 server which modules from the /usr/X11R6/lib/modules/ directory to load. Modules provide the XFree86 server with additional functionality.

Warning

You should not edit these values.

Monitor

Refers to the type of monitor used by the system. While one Monitor section is the minimum, there may be several Monitor sections, one for each monitor in use by the machine.

Warning

Be careful when manually editing values in the options of the Monitor section. Inappropriate values in this section could damage or destroy your monitor. Consult the documentation that came with your monitor for the safe operating parameters available.

The following options are usually configured during installation or when using the X Configuration Tool:

  • HorizSync — Tells XFree86 the range of horizontal sync frequencies compatible with the monitor in kHz. These values are used as a guide by the XFree86 server so that it will know whether to use a particular Modeline entry’s values with this monitor.

  • Identifier — Provides a unique name for this monitor, usually numbering each monitor starting at 0. The first monitor would be named Monitor0, the second Monitor1, and so on.

  • Modeline — Used to specify the video modes used by the monitor at particular resolutions, with certain horizontal sync and vertical refresh resolutions. Modeline entries are usually preceded by a comment that explains what the mode line specifies. If your configuration file does not include comments for the various mode lines, you can scan over the values (also called mode descriptions) to determine what the mode line is attempting to do. See the XF86Config man page for detailed explanations of each mode description section.

  • ModelName — An optional parameter that displays the model name of the monitor.

  • VendorName — An optional parameter that displays the name of the vendor that manufactured the monitor.

  • VertRefresh — Lists the vertical refresh range frequencies supported by the monitor, in kHz. These values are used as a guide by the XFree86 server so that it will know whether to use a particular Modeline entry’s values with this monitor.

Screen

Binds together a particular Device and Monitor that can be utilized as a pair and contain certain settings. You must have at least one Screen section in your configuration file. The following options are common:

  • DefaultDepth — Tells the Screen section the default color depth to try, in bits. 8 is the default, 16 provides thousands of colors, and 32 displays millions of colors.

  • Device — Signifies the name of the Device section to use with this Screen section.

  • Identifier — Identifies the Screen section so that it can be referred to by a ServerLayout section and be utilized.

  • Monitor — Tells the name of the Monitor section to be used with this Screen section.

You may also have a Display subsection within the Screen section that tells the XFree86 server the color depth (Depth) and resolution (Mode) to try first when using this particular monitor and video card.

ServerFlags

Contains miscellaneous global XFree86 server settings. These settings may be overridden by options placed in the ServerLayout section. Among the most useful settings:

  • DontZap — Prevents the use of the Ctrl-Alt-Backspace key combination to immediately terminate the XFree86 server.

  • DontZoom — Prevents cycling through configured video resolutions using the Ctrl-Alt-Keypad-Plus and Ctrl-Alt-Keypad-Minus key combinations.

ServerLayout

Binds a Screen section with the necessary InputDevice sections and various options to create a unified collection of preferences used by the XFree86 server as it starts. If you have more than one ServerLayout section, and the one to use is not specified on the command line when you bring up the XFree86 server, the first ServerLayout section in the configuration file is used. The following options are used in a ServerLayout section:

  • Identifier — A unique name used to describe this ServerLayout section.

  • InputDevice — The names of any InputDevice sections to be used with the XFree86 server. Most users will only have two lines here, Keyboard0 and Mouse0, the first keyboard and mouse configured for the system. The options CoreKeyboard and CorePointer refer to the fact that these are the preferred keyboard and mouse, respectively, to use with the XFree86 server.

  • Screen — The name of the Screen section to use. The number to the left of the name of the Screen section refers to the particular screen number to use in a multi-head configuration. For standard single-head video cards, this value is 0. The numbers to the right give the X and Y absolute coordinates for the upper-left corner of the screen, by default 0 0. Following is an example of a typical screen entry:

    Screen           0    "Screen0" 0 0

For more information, refer to the XF86Config man page.

To review the current configuration of your XFree86 server, type the xset -q command. This provides you with information about the keyboard, pointer, screen saver, and font paths.


Desktop Environments and Window Managers

The configuration of an XFree86 server is useless until accessed by an X client that will use it to display a program using the hardware controlled by the X server. X clients are programs designed to take advantage of the X server’s hardware, usually to provide interactivity with a user. You do not have to run a complicated window manager in conjunction with a particular desktop environment to use X client applications. Assuming that you are not already in an X environment and do not have an .xinitrc file in your home directory, type the xinit command to start X with a basic terminal window (the default xterm application). You will see that this basic environment utilizes your keyboard, mouse, video card, and monitor with the XFree86 server, using the server’s hardware preferences. Type exit at the xterm prompt to leave this basic X environment.

Of course, most computer users require more features and utility from their GUI. Developers have added layers of features to create highly developed and interactive environments that utilize the full power of the XFree86 server. These layers break into two fundamental groups based on their purpose.

Window Managers

Window managers are X client programs that control the way other X clients are positioned, resized, or moved. Window managers can also provide title bars to windows, keyboard focus by keyboard or mouse, and user-specified key and mouse button bindings. Window managers work with a collection of different X clients, wrapping around the program, making it look a certain way and appear on the screen in a particular place. Four window managers are included with Red Hat Linux 8.0:

  • twm — The minimalist Tab Window Manager, which provides the most basic toolset of any of the window managers.

  • mwm — The default window manager for the GNOME desktop environment, mwm stands for Metacity Window Manager. It is a simple and efficient window manager that supports custom themes.

These window managers can be run as individual X clients to gain a better sense of their differences. Type the xinit path-to-window-manager command, where path-to-window-manager is the location of the window manager binary file. The binary file can be found by typing which window-manager-name or by looking for the name of the window manager in a bin directory.

Desktop Environments

A desktop environment brings together assorted X clients that can be run together using similar methods, utilizing a common development environment. Desktop environments are different from window managers, which control only the appearance and placement of X client windows. Desktop environments contain advanced features that allow X clients and other running processes to communicate with one another. This allows all applications written to work in that environment to commonly integrate and be used in new ways, such as permitting drag-and-drop behavior with text.

GNOME is the default desktop environment for Red Hat Linux, using the GTK2 base widget toolkit and miscellaneous other widgets that extend the base functionality. KDE, another desktop environment, uses a different toolkit called Qt. GNOME and KDE both contain advanced productivity applications, such as word processors, spreadsheets, and control panel devices that allow you to have complete control of the look and feel of your user experience. Both environments can run standard X client applications, and most KDE applications can run in GNOME, if the Qt libraries are installed.

When you start X using the startx command, a pre-specified desktop environment is utilized. To change the default desktop environment used when X starts, open a terminal and type switchdesk. This brings up a graphical utility that allows you to select the desktop environment or window manager to use the next time X starts.

Desktop environments utilize window managers to provide the consistency in appearance between different applications. KDE contains its own window manager, called kwm, specifically for this functionality.

Tip

For information on the customization of the GNOME and KDE desktop environments, see the Official Red Hat Linux User’s Guide (Red Hat Press/Wiley, 2003).


Runlevels

Most users run X from runlevels 3 or 5. Runlevel 3 places your system in multi-user mode with full networking capabilities. The machine will boot to a text-based login prompt with all necessary preconfigured services started. Most servers are run in runlevel 3, as X is not necessary to provide any services utilized by most users. Runlevel 5 is similar to 3, except that it automatically starts X and provides a graphical login screen. Many workstation users prefer this method, because they never have to see a command prompt.

The default runlevel used when your system boots can be found in the /etc/inittab file. If you have a line in that file that looks like id:3:initdefault:, then your system will boot to runlevel 3. If you have a line that looks like id:5:initdefault:, your system is set to boot into runlevel 5. As root, change the runlevel number in this file to set a different default. Save the file and restart your system to verify that it boots to the correct runlevel.

Runlevel 3: startx

When in runlevel 3, the preferred way to start an X session is to type startx . startx, a front end to the xinit program, launches the XFree86 server and connects the X clients to it. Because you must already be logged in to the system at runlevel 3 to be able to type commands, startx is designed only to bring up certain X clients, such as a desktop environment, in a particular manner. It does not provide any user authentication.

When startx begins, it looks for an .xinitrc file in the user’s home directory to define the X clients to run. If it does not find that file present, it runs the system default /etc/X11/xinit/xinitrc script instead. The startx script then does the same thing with the .xserverrc file, looking for it in the user’s home directory and then running the default /etc/X11/xinit/xserverrc script if it cannot be found. Since many different X clients exist, the xinitrc files are very important. The xserverrc script is less important. It only sets the X server to connect to the X clients. Since the default X server is already configured with the /etc/X11/X link, Red Hat Linux does not install a default xserverrc.

The default xinitrc script then looks for user-defined files and default system files, including .Xresources, .Xmodmap, and .Xkbmap, in the user’s home directory and Xresources, Xmodmap, and Xkbmap in the /etc/X11/ directory. The Xmodmap and Xkbmap files, if they exist, are used by the xmodmap utility to configure the keyboard. The Xresources files are read to assign specific preference values to particular applications.

After setting these options, the xinitrc script executes all scripts located in the /etc/X11/xinit/xinitrc.d/ directory. One important script in this directory is xinput, which configures settings such as the default language to use and the desktop environment to start from (/etc/sysconfig/desktop).

Next, the xinitrc script tries to execute .Xclients in the user’s home directory and turns to /etc/X11/xinit/Xclients if it cannot be found. The purpose of the Xclients file is to start the desktop environment or, possibly, just a basic window manager. The .Xclients script in the user’s home directory starts the user-specified desktop environment or window manager in the .Xclients-default file. If .Xclients does not exist in the user’s home directory, the standard /etc/X11/init/Xclients script attempts to start another desktop environment, trying GNOME first and then KDE. If a desktop environment cannot be found by this point, Xclients attempts the default window manager listed in the .wm_style file in the user’s home directory. If this fails, it cycles through a predefined list of window managers.

The preferred X client applications should now have started, along with the XFree86 server. If you need more details concerning starting X in runlevel 3, refer to the startx and xinit man pages and read through the scripts named above.

Runlevel 5: prefdm

Runlevel 5 uses a slightly different method to start X. When the system starts, no one is logged in to the system by default. In order to start a session, a user must log in to the system. In runlevel 5, users authenticating themselves at the console use a display manager, a special X client that allows them to submit their login names and passwords.

Depending on the desktop environments installed on your specific Red Hat Linux system, three different display managers are available to handle the user authentication. The xdm display manager is the original X authentication tool. xdm allows you to log in and start an X session only, nothing more. The gdm display manager, designed to work with the GNOME desktop environment, and kdm display manager, used with the KDE desktop environment, allow you to set the desktop environment, or session, you would like to use after authentication. Additionally, you can restart or halt the system from the login screen. The gdm display manager also allows you to configure the language you would like to use.

When the system enters runlevel 5, a line in the /etc/inittab file specifies that the prefdm script is executed in order to determine the preferred display manager to bring up for user authentication. The prefdm script uses the preferences stated in the /etc/sysconfig/desktop file to find the proper display manager. If no desktop environment is specified, prefdm cycles through the gdm, kdm, and xdm display managers to find one to use. Once one is found, prefdm launches it to handle the user login.

Each of the display managers looks to the /etc/X11/xdm/Xsetup_0 file to set up the login screen. Once the user logs into the system, the /etc/X11/xdm/GiveConsole script runs to assign ownership of the console to the user. Then, the /etc/X11/xdm/Xsession script runs to accomplish many of the tasks normally done by the xinitrc script when starting X in runlevel 3, including setting system and user resources, as well as running the scripts in the /etc/X11/xinit/xinitrc.d/ directory.

Users can specify which desktop environment they want to utilize when they authenticate using the gdm or kdm display managers by selecting it from the Session menu. If the desktop environment is not specified in the display manager, the /etc/X11/xdm/Xsession script will check the .xsession and .Xclients files in the user’s home directory to decide which desktop environment to load. As a last resort, the /etc/X11/xinit/Xclients file is used to select a desktop environment or window manager to use in the same way as runlevel 3.

When the user finishes an X session on the default display (:0) and logs out, the /etc/X11/xdm/TakeConsole script runs and reassigns ownership of the console to the root user. The original display manager, which continued running after the user logged in, takes control by spawning a new display manager. This restarts the XFree86 server, displays a new login window, and starts the entire process over again. For more information about how display managers control user authentication, read the xdm man page.


Fonts

Red Hat Linux uses xfs (X Font Server) to provide fonts to the XFree86 server and the X client applications that connect to it. While it is possible to circumvent xfs and place the paths to font directories in your XF86Config configuration file, using xfs has several advantages:

  • It is easier to add and remove fonts, including editing the font path. The font path is a collection of paths in the file system where font files are stored. The xfs service keeps the font path out of the XFree86 configuration files, making it easier to edit.

  • Fonts may be stored on one machine acting as a networked font server and can be shared among multiple X servers over the network. A common set of fonts can be maintained in one place and easily shared among all users.

  • More types of fonts are supported. xfs can handle TrueType, Type1, and bitmap fonts.

The XFree86 configuration files know whether to use xfs or hard-coded font paths because of the FontPath setting in their Files sections. By default, the FontPath is set to unix/:7100. This tells the XFree86 server to connect to port 7100 using an inner-machine communication link. The xfs server listening on this port will respond with font information when queried by the XFree86 server.

The xfs service must be running when X is started. If it is not, you will be returned to a command prompt with an error similar to failed to set default font path unix/:7100. Check to see if xfs is running by using the ps aux | grep xfs command. By default, xfs is set to start in runlevels 2, 3, 4, and 5, covering all runlevels where you would run X. If xfs is not running on your system, you can start it as root using the /sbin/service xfs start command. Use the /usr/sbin/ntsysv, serviceconf, or /sbin/chkconfig utilities to force it to start at the correct runlevels. For more on configuring services for a particular runlevel, refer to Chapter 21.

xfs Configuration

The /etc/rc.d/init.d/xfs script starts the xfs server. Several options can be configured in the /etc/X11/fs/config file:

  • alternate-servers — Sets a list of alternate font servers to be used if this font server is not available. A comma must separate every font server in the list.

  • catalogue — An ordered list of font paths to use that contain the font files. A comma must follow every font path before a new font path can be started in the list. You can use the string :unscaled immediately after the font path to make the unscaled fonts in that path load first. Then, you can specify the entire path again, so that other, scaled fonts will also be loaded.

  • client-limit — Sets the number of clients this font server will service before refusing to handle any more. The default is 10.

  • clone-self — Decides if the font server will clone a new version of itself when the client-limit is hit. By default, this option is on. Set it to off to disable this feature.

  • default-point-size — Sets the default point size for any font that does not specify this value. The value for this option is set in decipoints. The default of 120 corresponds to 12-point fonts.

  • default-resolutions — Specifies a list of resolutions supported by the XFree86 server. Each resolution in the list must be separated by a comma.

  • deferglyphs — Tells xfs whether to defer the loading of glyphs, images used to visually represent a font. You can disable this feature (none), enable this feature for all fonts (all), or turn this this feature on only for 16-bit fonts (16), which are largely used with Asian languages.

  • error-file — Allows you to specify the path and file name of a location where xfs errors can be logged.

  • no-listen — Tells xfs not to listen using a particular protocol. By default, this option is set to tcp to prevent xfs from listening on TCP ports, primarily for security reasons. If you plan on using xfs to serve fonts to networked workstations on a LAN, remove the tcp from this line.

  • port — Specifies the TCP port that xfs will listen on if no-listen does not exist or is commented out.

  • use-syslog — Tells xfs to use the system error log if set to on.

Adding Fonts

When using xfs, adding fonts to your system is rather straightforward. Use the chkfontpath --list command to see the font paths currently configured on your system. To add new fonts in a new directory, follow these instructions as the root user:

  1. Create a font directory, such as /usr/share/fonts, and place the fonts inside that directory. Be sure to set the permissions correctly. It is necessary only that the files can be read; no other permissions are necessary.

  2. Type the chkfontpath --add font-directory-path command, where font-directory-path is the full path to the directory holding the fonts. This will add this font path to the xfs configuration file.

    Note

    You must have a fonts.dir file in your new font directory for the chkfontpath command to work correctly. The creation of the fonts.dir file, as well as any other files used by xfs with these fonts, is beyond the scope of this book.

  3. Restart xfs using the /sbin/service xfs restart command. You will also need to restart your X session.

  4. Typing the chkfontpath --list command will show the new font path. Any fonts you added will be available for use.

    Tip

    The Red Hat Support website contains more information on this subject. See http://www.redhat.com/support for additional help documents.


Additional Resources

Much more can be said about the XFree86 server, the clients that connect to it, and the assorted desktop environments and window managers. Advanced users interested in tweaking their XFree86 configuration will find these additional sources of information useful.

Installed Documentation

  • /usr/X11R6/lib/X11/doc/README — Briefly describes the XFree86 architecture and how to get additional information about the XFree86 project as a new user.

  • /usr/X11R6/lib/X11/doc/README.Config — Explains the advanced configuration options open to XFree86 version 3 users.

  • /usr/X11R6/lib/X11/doc/RELNOTES — For advanced users who want to read about the latest features available in XFree86.

  • man XF86Config — Contains information about the XFree86 configuration files, including the meaning of and syntax for the different sections within the files.

  • man XFree86 — The primary man page for all XFree86 information. Details the difference between local and network X server connections, explores common environmental variables, lists command-line options, and provides helpful administrative key combinations.

  • man Xserver — Describes the X display server.

Useful Websites

  • http://www.xfree86.org — Home page of the XFree86 project, which produces the XFree86 open-source version of the X Window System. XFree86 is bundled with Red Hat Linux to control the necessary hardware and provide a GUI environment.

  • http://dri.sourceforge.net — Home page of the DRI (Direct Rendering Infrastructure) project. The DRI is the core hardware 3D acceleration component of XFree86.

  • http://www.redhat.com/mirrors/LDP/HOWTO/XFree86-HOWTO — A HOWTO document detailing the manual installation and custom configuration of XFree86.

  • http://www.gnome.org — The home page of the GNOME project.

  • http://www.kde.org — The home page of the KDE desktop environment.

Related Books

  • The Concise Guide to XFree86 for Linux by Aron Hsiao (Que) — Provides an expert’s view of the operation of XFree86 on Linux systems.

  • The New XFree86 by Bill Ball (Prima Publishing) — Discusses XFree86 and its relationship with popular desktop environments, such as GNOME and KDE.

  • Beginning GTK+ and GNOME by Peter Wright (Wrox Press, Inc.) — Introduces programmers to the GNOME architecture, showing them how to get started with GTK+.

  • GTK+/GNOME Application Development by Havoc Pennington (New Riders Publishing) — An advanced look into the heart of GTK+ programming, focusing on sample code and a thorough look at the available APIs.

  • KDE 2.0 Development by David Sweet and Matthias Ettrich (Sams Publishing) — Instructs beginning and advanced developers how to take advantage of the many environment guidelines required to build Qt applications for KDE.


Chapter 10: Automated Tasks

Some tasks — particularly those that are processor- or disk-intensive — are best performed when system demand is low. This may be at a certain time of the day, week, or month, or when the system load is low. In addition, the administrator may find that automating repetitive tasks such as backups or disk space checks will significantly reduce personal workload.

In Linux, tasks can be configured to run automatically within a specified period of time, on a specified date, or when the system load average is below a specified number. Red Hat Linux comes preconfigured to run important system tasks to keep the system updated. For example, the slocate database used by the locate command is updated daily. A system administrator can use automated tasks to perform periodic backups, monitor the system, run custom scripts, and more. Red Hat Linux comes with four automated tasks utilities: cron, anacron, at, and batch.

cron

cron is a daemon that can be used to schedule the execution of recurring tasks according to a combination of the time, day of the month, month, day of the week, and week. cron assumes that the system is on continuously. If the system is not on when a task is scheduled, it is not executed. To configure tasks based on time periods instead of exact times, refer to the “at and batch” section of this chapter.

To use the cron service, you must have the vixie-cron RPM package installed, and the crond service must be running. To determine if the package is installed, use the rpm -q vixie-cron command. To determine if the service is running, use the command /sbin/service crond status.

Configuring cron Tasks

The main configuration file for cron, /etc/crontab, contains the following lines:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

The first four lines are variables used to configure the environment in which the cron tasks are run. The value of the SHELL variable tells the system which shell environment to use (in this example, the bash shell), and the PATH variable defines the path used to execute commands.

The output of the cron tasks is emailed to the username defined with the MAILTO variable. If the MAILTO variable is defined as an empty string (MAILTO=""), email will not be sent. The HOME variable can be used to set the home directory to use when executing commands or scripts.

Each line in the /etc/crontab file represents a task and has the format:

minute     hour     day     month     dayofweek       command

  • minute — any integer from 0 to 59

  • hour — any integer from 0 to 23

  • day — any integer from 1 to 31 (must be a valid day if a month is specified)

  • month — any integer from 1 to 12 (or the short name of the month such as jan, feb, and so on)

  • dayofweek — any integer from 0 to 7, where 0 or 7 represents Sunday (or the short name of the week such as sun, mon, and so on)

  • command — the command to execute. The command can either be a command such as ls /proc >> /tmp/proc or the command to execute a custom script that you wrote.

For any of the above values, an asterisk (*) can be used to specify all valid values. For example, an asterisk for the month value means execute the command every month within the constraints of the other values. A hyphen (-) between integers specifies a range of integers. For example, 1-4 means the integers 1, 2, 3, and 4. A list of values separated by commas (,) specifies a list. For example, 3, 4, 6, 8 indicates those four specific integers.

The forward slash (/) can be used to specify step values. The value of an integer can be skipped within a range by following the range with / integer. For example, 0-59/2 can be used to define every other minute in the minute field. Step values can also be used with an asterisk. For instance, the value */3 can be used in the month field to run the task every third month.

Any lines that begin with a hash mark (#) are comments and are not processed. As you can see from the /etc/crontab file, it uses the run-parts script to execute the scripts in the /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly directories on an hourly, daily, weekly, or monthly basis respectively. The files in these directories should be shell scripts.

If a cron task needs to be executed on a schedule other than hourly, daily, weekly, or monthly, it can be added to the /etc/cron.d directory. All files in this directory use the same syntax as /etc/crontab. Here is an example:

# record the memory usage of the system every Monday
# at 3:30AM in the file /tmp/meminfo
30 3 * * mon cat /proc/meminfo >> /tmp/meminfo
# run custom script the first day of every month at 4:10AM
10 4 1 * * /root/scripts/backup.sh

Users other than root can configure cron tasks by using the crontab utility. All user-defined crontabs are stored in the /var/spool/cron directory and are executed using the usernames of the users that created them. To create a crontab as a user, log in as that user and type crontab -e to edit the user’s crontab using the editor specified by the VISUAL or EDITOR environment variable. The file uses the same format as /etc/crontab. When the changes to the crontab are saved, the crontab is stored according to username and written to the file /var/spool/cron/username.

The cron daemon checks the /etc/crontab file, the /etc/cron.d/ directory, and the /var/spool/cron directory every minute for any changes. If any changes are found, they are loaded into memory. Thus, the daemon does not need to be restarted if a crontab file is changed.

Controlling Access to cron

The /etc/cron.allow and /etc/cron.deny files are used to restrict access to cron. The format of both access control files is one username on each line. Whitespace is not permitted in either file.

The cron daemon (crond) does not have to be restarted if the access control files are modified. The access control files are read each time a user tries to add or delete a cron task. The root user can always use cron, regardless of the user names listed in the access control files.

If the file cron.allow exists, only users listed in it are allowed to use cron, and the cron.deny file is ignored. If cron.allow does not exist, all users listed in cron.deny are not allowed to use cron.

Starting and Stopping the Service

To start the cron service, use the command /sbin/service crond start. To stop the service, use the command /sbin/service crond stop. It is recommended that you start the service at boot time.


anacron

anacron is a task scheduler similar to cron except that it does not require the system to run continuously. It can be used to run the daily, weekly, and monthly jobs usually run by cron.

To use the anacron service, you must have the anacron RPM package installed, and the anacron service must be running. To determine if the package is installed, use the rpm -q anacron command. To determine if the service is running, use the command /sbin/service anacron status.

Configuring anacron Tasks

anacron tasks are listed in the configuration file /etc/anacrontab. Each line in the configuration file corresponds to a task and has the format:

period         delay    job-identifier      command

  • period — frequency (in days) to execute the command

  • delay — delay time in minutes

  • job-identifier — description of the task, used in anacron messages and as the name of the job’s timestamp file; can contain any non-blank characters (except slashes).

  • command — command to execute

For each task, anacron determines if the task has been executed within the period specified in the period field of the configuration file. If it has not been executed within the given period, anacron executes the command specified in the command field after waiting the number of minutes specified in the delay field. After the task is completed, anacron records the date in a timestamp file in the /var/spool/anacron directory. Only the date is used (not the time), and the value of the job-identifier field is used as the file name for the timestamp file.

Environment variables such as SHELL and PATH can be defined at the top of /etc/anacrontab as with the cron configuration file. The default configuration file looks similar to the following:

# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# These entries are useful for a Red Hat Linux system.
1         5         cron.daily                  run-parts /etc/cron.daily
7         10        cron.weekly                 run-parts /etc/cron.weekly
30        15        cron.monthly                run-parts /etc/cron.monthly

As you can see in the previous example, anacron for Red Hat Linux is configured to make sure the daily, weekly, and monthly cron tasks are run.

Starting and Stopping the Service

To start the anacron service, use the command /sbin/service anacron start. To stop the service, use the command /sbin/service anacron stop. It is recommended that you start the service at boot time.


at and batch

While cron and anacron are used to schedule recurring tasks, the at command is used to schedule a one-time task at a specific time. The batch command is used to schedule a one-time task to be executed when the system’s load average drops below 0.8.

To use at or batch you must have the at RPM package installed, and the atd service must be running. To determine if the package is installed, use the rpm -q at command. To determine if the service is running, use the command /sbin/service atd status.

Configuring at Jobs

To schedule a one-time job at a specific time, type at time, where time is the time to execute the command. The argument time can be one of the following:

  • HH:MM format — For example, 04:00 specifies 4:00 a.m. If the time is already past, it is executed at the specified time the next day.

  • midnight — Specifies 12:00 a.m.

  • noon — Specifies 12:00 p.m.

  • teatime — Specifies 4:00 p.m.

  • month-name day year format — For example, January 15 2005 specifies the 15th day of January in the year 2005. The year is optional.

  • MMDDYY, MM/DD/YY, or MM.DD.YY formats — For example, 011505 for the 15th day of January in the year 2005.

  • now + time — time is in minutes, hours, days, or weeks. For example, now + 5 days specifies that the command should be executed at the same time in five days. The time must be specified first, followed by the optional date.

For more information about the time format, read the /usr/share/doc/at version/timespec text file.

After typing the at command with the time argument, you will see the at> prompt. Type the command to be executed, press Enter, and press Ctrl-D. More than one command can be specified by typing each command followed by the Enter key. After typing all the commands, press Enter to go to a blank line and press Ctrl-D.

Alternatively, a shell script can be entered at the prompt, pressing Enter after each line in the script and pressing Ctrl-D on a blank line to exit. If a script is entered, the shell used is the shell set in the user’s SHELL environment, the user’s login shell, or /bin/sh (whichever is found first).

If the set of commands or script tries to display information to the standard output, the output is emailed to the user. Use the command atq to view pending jobs. Refer to the “Viewing Pending Jobs” section for more information. Use of the at command can be restricted. Refer to the section “Controlling Access to at and batch” for details.

Configuring batch Jobs

To execute a one-time task when the load average is below 0.8, use the batch command. After typing the batch command, you will see the at> prompt. Type the command to be executed, press Enter, and press Ctrl-D. More than one command can be specified by typing each command followed by the Enter key. After typing all the commands, press Enter to go to a blank line and press Ctrl-D.

Alternatively, a shell script can be entered at the prompt, pressing Enter after each line in the script, and pressing Ctrl-D on a blank line to exit. If a script is entered, the shell used is the shell set in the user’s SHELL environment, the user’s login shell, or /bin/sh (whichever is found first). As soon as the load average is below 0.8, the set of commands or script is executed.

If the set of commands or script tries to display information to standard out, the output is emailed to the user. Use the command atq to view pending jobs. Refer to the “Viewing Pending Jobs” section below for more information. Use of the batch command can be restricted. Refer to the section “Controlling Access to at and batch” for details.

Viewing Pending Jobs

To view pending at and batch jobs, use the atq command. It displays a list of pending jobs, with each job on a line. Each line is in the format job number, date, hour, job class, and username. Users can view only their own jobs. If the root user executes the atq command, all jobs for all users are displayed.

Additional Command-Line Options

Additional command line options for at and batch are shown in Table 10-1.

Table 10-1: at and batch command-line options
Option | Description
-f | Read the commands or shell script from a file instead of specifying them at the prompt.
-m | Send email to the user when the job has been completed.
-v | Display the time that the job will be executed.

Controlling Access to at and batch

The /etc/at.allow and /etc/at.deny files can be used to restrict access to the at and batch commands. The format of both access control files is one username on each line. Whitespace is not permitted in either file. The at daemon (atd) does not have to be restarted if the access control files are modified. The access control files are read each time a user tries to execute the at or batch commands.

The root user can always execute at and batch commands, regardless of the access control files. If the file at.allow exists, only users listed in it are allowed to use at or batch, and the at.deny file is ignored. If at.allow does not exist, all users listed in at.deny are not allowed to use at or batch.

Starting and Stopping the Service

To start the at service, use the command /sbin/service atd start. To stop the service, use the command /sbin/service atd stop. It is recommended that you start the service at boot time.


Additional Resources

To learn more about configuring automated tasks, refer to the following resources.

Installed Documentation

  • cron man page — overview of cron.

  • crontab man pages, sections 1 and 5 — The man page in section 1 contains an overview of the crontab file. The man page in section 5 contains the format for the file and some example entries.

  • /usr/share/doc/at version/timespec contains more detailed information about the times that can be specified for cron jobs.

  • anacron man page — description of anacron and its command-line options.

  • anacrontab man page — brief overview of the anacron configuration file.

  • /usr/share/doc/anacron version/README describes anacron and why it is useful.

  • at man page — description of at and batch and their command-line options.


Chapter 11: Redundant Array of Independent Disks (RAID)

This chapter introduces the concept of RAID, which allows an administrator to combine multiple small, inexpensive disk drives into an array to accomplish performance or redundancy goals not attainable with one large and expensive drive. This array of drives appears to the computer as a single logical storage unit or drive. RAID can be managed at either the hardware or software levels. This chapter deals primarily with software RAID.

What Is RAID?

RAID is a method in which information is spread across several disks, using techniques such as disk striping (RAID Level 0), disk mirroring (RAID level 1), and disk striping with parity (RAID Level 5) to achieve redundancy, lower latency and/or increased bandwidth for reading from or writing to disks, and maximize the ability to recover from hard-disk crashes.

The underlying concept of RAID is that data may be distributed across each drive in the array in a consistent manner. To do this, the data must first be broken into consistently sized chunks (often 32K or 64K in size, although different sizes can be used). Each chunk is then written to a hard drive in RAID according to the RAID level used. When the data is to be read, the process is reversed, giving the illusion that multiple drives are actually one large drive.


Who Should Use RAID?

Anyone who needs to keep large quantities of data on hand (such as a system administrator) can benefit by using RAID technology. Primary reasons to use RAID include:

  • Enhanced speed

  • Increased storage capacity using a single virtual disk

  • Lessened impact of a disk failure


Hardware RAID versus Software RAID

There are two possible RAID approaches: hardware RAID and software RAID.

Hardware RAID

The hardware-based system manages the RAID subsystem independently from the host and presents to the host only a single disk per RAID array. An example of a hardware RAID device is one that connects to a SCSI controller and presents the RAID arrays as a single SCSI drive. An external RAID system moves all RAID handling “intelligence” into a controller located in the external disk subsystem. The whole subsystem is connected to the host via a normal SCSI controller and appears to the host as a single disk.

RAID controllers also come in the form of cards that act like a SCSI controller to the operating system but handle all of the actual drive communications themselves. In these cases, you plug the drives into the RAID controller just as you would into a SCSI controller, but then you add them to the RAID controller’s configuration, and the operating system never knows the difference.

Software RAID

Software RAID implements the various RAID levels in the kernel disk (block device) code. It offers the cheapest possible solution, as expensive disk controller cards or hot-swap chassis are not required. A hot-swap chassis allows you to remove a hard drive without having to power down your system. Software RAID also works with cheaper IDE disks as well as SCSI disks. With today’s fast CPUs, software RAID performance can easily beat the performance of hardware RAID.

The MD driver in the Linux kernel is an example of a RAID solution that is completely hardware independent. The performance of a software-based array is dependent on the server CPU performance and load. For information on configuring Software RAID in the Red Hat Linux installation program, refer to the “Software RAID Configuration” section of this chapter.

For those interested in learning more about what software RAID has to offer, here is a brief list of the most important features:

  • Threaded rebuild process

  • Kernel-based configuration

  • Portability of arrays between Linux machines without reconstruction

  • Backgrounded array reconstruction using idle system resources

  • Hot-swappable drive support

  • Automatic CPU detection to take advantage of certain CPU optimizations


RAID Levels and Linear Support

RAID supports various configurations, including levels 0, 1, 4, 5, and linear. These RAID types are defined as follows.

Level 0

RAID level 0, often called “striping,” is a performance-oriented striped data mapping technique. This means the data being written to the array is broken down into strips and written across the member disks of the array, allowing high I/O performance at low inherent cost but providing no redundancy. The storage capacity of a level 0 array is equal to the total capacity of the member disks in a hardware RAID or the total capacity of member partitions in a software RAID.

Level 1

RAID level 1, or “mirroring,” has been used longer than any other form of RAID. Level 1 provides redundancy by writing identical data to each member disk of the array, leaving a “mirrored” copy on each disk. Mirroring remains popular because of its simplicity and high level of data availability. Level 1 operates with two or more disks that may use parallel access for high data-transfer rates when reading but more commonly operate independently to provide high I/O transaction rates. Level 1 provides very good data reliability and improves performance for read-intensive applications but at a relatively high cost. The storage capacity of the level 1 array is equal to the capacity of one of the mirrored hard disks in a hardware RAID or one of the mirrored partitions in a software RAID.

Note

RAID level 1 comes at a high cost because you write the same information to all of the disks in the array, which wastes drive space. For example, if you have RAID level 1 set up so that your root (/) partition exists on two 40GB drives, you have 80GB total but are able to access only 40GB of that 80GB. The other 40GB acts like a mirror of the first 40GB.

Level 4

Level 4 uses parity concentrated on a single disk drive to protect data. Level 4 is better suited to transaction I/O than large file transfers. Because the dedicated parity disk represents an inherent bottleneck, level 4 is seldom used without accompanying technologies such as write-back caching. Although RAID level 4 is an option in some RAID partitioning schemes, it is not an option allowed in Red Hat Linux RAID installations. The storage capacity of hardware RAID level 4 is equal to the capacity of member disks, minus the capacity of one member disk. The storage capacity of software RAID level 4 is equal to the capacity of the member partitions, minus the size of one of the partitions if they are of equal size.

Note

Parity information is calculated based on the contents of the rest of the member disks in the array. This information can then be used to reconstruct data when one disk in the array fails. The reconstructed data can then be used to satisfy I/O requests to the failed disk before it is replaced and to repopulate the failed disk after it has been replaced.
Note

RAID level 4 takes up the same amount of space as RAID level 5, but level 5 has more advantages. For this reason, level 4 is not supported under Red Hat 8.0.

Level 5

This is the most common type of RAID. By distributing parity across some or all of an array’s member disk drives, RAID level 5 eliminates the write bottleneck inherent in level 4. The only performance bottleneck is the parity calculation process. With modern CPUs and software RAID, that usually is not a very big problem. As with level 4, the result is asymmetrical performance, with reads substantially outperforming writes. Level 5 is often used with write-back caching to reduce the asymmetry. The storage capacity of hardware RAID level 5 is equal to the capacity of member disks, minus the capacity of one member disk. The storage capacity of software RAID level 5 is equal to the capacity of the member partitions, minus the size of one of the partitions if they are of equal size.

Linear RAID

Linear RAID is a simple grouping of drives to create a larger virtual drive. In linear RAID, the chunks are allocated sequentially from one member drive, going to the next drive only when the first is completely filled. This grouping provides no performance benefit, as it is unlikely that any I/O operations will be split between member drives. Linear RAID also offers no redundancy and, in fact, decreases reliability — if any one member drive fails, the entire array cannot be used. The capacity is the total of all member disks.


Software RAID Configuration

Software RAID can be configured during the graphical installation of Red Hat Linux or during a kickstart installation. You can use fdisk or Disk Druid to create your RAID configuration, but these instructions will focus mainly on using Disk Druid to complete this task. Before you can create a RAID device, you must first create RAID partitions, using the following step-by-step instructions.

Tip

If you are using fdisk to create a RAID partition, remember that instead of creating a partition as type 83, which is Linux native, you must create the partition as type fd (Linux RAID). Also, for best performance, partitions within a given RAID array should span identical cylinders on drives.

  1. On the Disk Partitioning Setup screen, select Manually partition with Disk Druid.

  2. In Disk Druid, choose New to create a new partition.

You will not be able to enter a mount point (you will be able to do that once you have created your RAID device).

  1. Choose software RAID from the File System Type pull-down menu as shown in Figure 11-1.

  2. For Allowable Drives, select the drive(s) on which RAID will be created. If you have multiple drives, all drives will be selected here, and you must deselect those drives which will not have the RAID array on them.

  3. Enter the size that you want the partition to be.

  4. Select Fixed size to make the partition the specified size, select Fill all space up to (MB) and enter a size in MBs to give range for the partition size, or select Fill to maximum allowable size to make it grow to fill all available space on the hard disk. If you make more than one partition growable, they will share the available free space on the disk.

    Click To expand
    Figure 11-1: Creating a new RAID partition

  5. Select Force to be a primary partition if you want the partition to be a primary partition.

  6. Select Check for bad blocks if you want the installation program to check for bad blocks on the hard drive before formatting it.

  7. Click OK to return to the main screen.

Repeat these steps to create as many partitions as needed for your RAID setup. Notice that not all the partitions have to be RAID partitions. For example, you can configure only the /home partition as a software RAID device.

Once you have all of your partitions created as software RAID partitions, follow these steps:

  1. Select the RAID button on the Disk Druid main partitioning screen.

  2. Next, Figure 11-2 will appear, where you can make a RAID device.

  3. Enter a mount point.

  4. Choose the file system type for the partition.

  5. Choose your RAID level. You can choose from RAID 0, RAID 1, and RAID 5.

    Note

    If you are making a RAID partition of /boot, you must choose RAID level 1, and it must use one of the first two drives (IDE first, SCSI second). If you are not creating a RAID partition of /boot, and you are making a RAID partition of /, it must be RAID level 1 and it must use one of the first two drives (IDE first, SCSI second).

  6. Select which partitions will go into this RAID array and click OK.

    Click To expand
    Figure 11-2: Making a RAID device

  7. A spare partition can be specified for RAID 1 and RAID 5. If a software RAID partition fails, the spare will automatically be used as a replacement. For each spare you want to specify, you must create an additional software RAID partition (in addition to the partitions for the RAID device). In the previous step, select the partitions for the RAID device and the partition(s) for the spare(s). Select the number of spares.

  8. Select whether you want the partition formatted.

  9. The RAID device will appear in the Drive Summary list as shown in Figure 11-3. At this point, you can continue with your installation process. Refer to Appendix A for further instructions.

    Click To expand
    Figure 11-3: Creating a RAID array


Chapter 12: Kernel Management

The kernel is the core of the Linux operating system. The kernel controls such things as access to hardware, memory allocation, and so forth. This chapter discusses management of the kernel, including upgrading a kernel from Red Hat RPM packages and building a custom kernel. Ordinarily, it should not be necessary to install a new kernel manually. However, the administrator may wish to do so in cases where a new kernel release includes desired features not contained in the current kernel.

The Red Hat Linux kernel is custom built by the Red Hat kernel team to ensure its integrity and compatibility with supported hardware. Before Red Hat releases a kernel, the kernel must pass a rigorous set of quality assurance tests. Official Red Hat Linux kernels are packaged in RPM format so that they are easy to upgrade and verify.

For example, the kernel RPM package creates the initrd image; it is not necessary to use the mkinitrd command after installing a different kernel if you install the kernel from the Red Hat RPM package. The RPM package also modifies the boot loader configuration file to include the new kernel if either GRUB or LILO is installed. (You do need to set the new kernel as the default kernel to boot.)

Warning

Building your own custom kernel is not supported by the Red Hat Linux Installation Support Team.

The 2.4 Kernel

Red Hat Linux ships with a custom 2.4 kernel, which offers the following features:

  • Kernel source directory is /usr/src/linux-2.4 instead of /usr/src/linux

  • Support for the ext3 file system

  • Multi-processor (SMP) support

  • USB support

  • Preliminary support for IEEE 1394, also referred to as FireWire, devices.


Preparing to Upgrade

Before you upgrade your kernel, you must take a few precautionary steps. The first step is to make sure you have a working boot diskette for your system in case a problem occurs. If the boot loader is not configured properly to boot the new kernel, you will not be able to boot your system unless you have a boot diskette.

To create a boot diskette for your system, you need to determine which version of the kernel you are currently running. Execute the following command:

uname -r

You must be root to create a boot diskette for your system. Log in as root at a shell prompt, and type the following command (where kernelversion is the output of the uname -r command):

/sbin/mkbootdisk kernelversion
Tip

Refer to the mkbootdisk man page for more options.

Reboot your machine with the boot diskette and verify that the diskette works before continuing. You will probably not have to use the diskette, but you should store it in a safe place just in case.

To determine which kernel packages you have installed, execute the following command at a shell prompt:

rpm -qa | grep kernel

The output will contain some or all of the following packages, depending on what type of installation you performed (your version numbers and packages may differ):

kernel-2.4.18-7.95
kernel-debug-2.4.18-7.95
kernel-source-2.4.18-7.95
kernel-doc-2.4.18-7.95
kernel-pcmcia-cs-3.1.27-12
kernel-smp-2.4.18-7.95

From the output, you can determine which packages you need to download for the kernel upgrade. For a single-processor system, the only required package is the kernel package. If you have a computer with more than one processor, you need the kernel-smp package, which contains support for multiple processors. It is recommended that you also install the kernel package in case the multi-processor kernel does not work properly for your system. If you have a computer with more than 4GB of memory, you need the kernel-bigmem package. Again, it is recommended that you also install the kernel package for debugging purposes. The kernel-bigmem package is built for the i686 architecture only.

If you are upgrading the kernel on a laptop or are using PCMCIA, the kernel-pcmcia-cs package is also required. You do not need the kernel-source package unless you plan to recompile the kernel yourself or plan to perform kernel development. The kernel-doc package contains kernel development documentation and is not required. The kernel-util package includes utilities that can be used to control the kernel or the system’s hardware and is not required.

Red Hat builds kernels that are optimized for different x86 versions. The options are athlon for AMD Athlon and AMD Duron systems; i686 for Intel Pentium II, Intel Pentium III, and Intel Pentium 4 systems; and i586 for Intel Pentium and AMD K6 systems. If you do not know the version of your x86 system, use the kernel built for the i386 version; it is built for all x86-based systems.

The x86 version of the RPM package is included in the file name. For example, kernel-2.4.18-7.95.athlon.rpm is optimized for AMD Athlon and AMD Duron systems, and kernel-2.4.18-7.95.i686.rpm is optimized for Intel Pentium II, Intel Pentium III, and Intel Pentium 4 systems. When you have determined which packages you need in order to upgrade your kernel, select the proper versions of the kernel, kernel-smp, and kernel-bigmem packages to match the architecture of your machine. Use the i386 versions of the other packages.


Obtaining the Upgraded Kernel

There are several ways to determine if there is an updated kernel available for your system.

  • Go to http://www.redhat.com/apps/support/errata/, choose the version of Red Hat Linux you are using, and view the errata for it. Kernel errata are usually under the Security Advisories section. From the list of errata, click the kernel errata to view the detailed errata report for it. In the errata report, there is a list of required RPM packages and a link to download them from the Red Hat FTP site. You can also download them from a Red Hat FTP mirror site. A list of mirror sites is available at http://www.redhat.com/download/mirror.html.

  • Use Red Hat Network to download the kernel RPM packages and then manually upgrade to the latest kernel. Or, if you have elected to let the Red Hat Update Agent upgrade packages for you, Red Hat Network can upload the latest kernel, upgrade the kernel on your system, create an initial RAM disk if needed, and configure the boot loader to boot the new kernel. All you have to do is reboot into the new kernel. For more information, refer to the Red Hat Network User Reference Guide available at http://www.redhat.com/docs/manuals/RHNetwork/.

If there is an updated kernel for the version of Red Hat Linux you are running, obtain the appropriate packages using one of these methods. If you used Red Hat Network to upgrade your kernel automatically, you are finished — just reboot your system to use the new kernel. If you downloaded only the RPM packages from the Red Hat Linux errata page or from Red Hat Network, proceed to the next section.


Performing the Upgrade

Now that you have the necessary kernel RPM packages, you can upgrade your existing kernel. At a shell prompt as root, change to the directory that contains the kernel RPM packages and follow these instructions.

Tip

It is strongly recommended that you keep the old kernel in case you have problems with the new kernel.

Use the -i argument with the rpm command if you want to keep the old kernel, as shown in the following command. Note that, if you use the --U option to upgrade the kernel package, the installation process will overwrite the currently installed kernel (the kernel version and x86 version might vary):

rpm -ivh kernel-2.4.18-7.95.i386.rpm

For a multi-processor system, install the kernel-smp packages as well (the kernel version and x86 version might vary):

rpm -ivh kernel-smp-2.4.18-7.95.i386.rpm

If the system is i686-based and contains more than 4GB of RAM, install the kernel-bigmem package built for the i686 architecture as well (the kernel version might vary):

rpm -ivh kernel-bigmem-2.4.18-7.95.i686.rpm

If you plan to upgrade the kernel-source, kernel-docs, or kernel-utils packages, you probably do not need to keep the older versions. Use the following commands to upgrade these packages (the versions might vary):

rpm -Uvh kernel-source-2.4.18-7.95.i386.rpm
rpm -Uvh kernel-docs-2.4.18-7.95.i386.rpm
rpm -Uvh kernel-utils-2.4.18-7.95.i386.rpm

If you are using PCMCIA (for example, on a laptop), you also need to install the kernel-pcmcia-cs package and keep the old version. If you use the -i switch, the installation process will probably return a conflict because the older kernel needs this package in order to boot with PCMCIA support. To work around this, use the --force switch as follows (the version might vary):

rpm -ivh --force kernel-pcmcia-cs-3.1.24-2.i386.rpm

If you are using the ext3 file system or a SCSI controller, you need an initial RAM disk. The purpose of the initial RAM disk is to allow a modular kernel to have access to modules that it might need to boot from before the kernel has access to the device where the modules normally reside.

The initial RAM disk is created with the mkinitrd command. However, the Red Hat kernel RPM package performs this step for you. To verify that it was created, use the command ls --l /boot. You should see the file initrd-2.4.18-7.95.img (the version should match the version of the kernel you just installed).

Now that you have installed the new kernel, you need to configure the boot loader to boot the new kernel.


Configuring the Boot Loader

The kernel RPM package configures the GRUB or LILO boot loader to boot the newly installed kernel if either boot loader is installed. However, it does not configure the boot loader to boot the new kernel by default. It is always a good idea to confirm that the boot loader has been configured correctly. This is a crucial step. If the boot loader has been configured incorrectly, you will not be able to boot your system. If this happens, boot your system with the boot diskette you created earlier and try configuring the boot loader again.

GRUB

If you selected GRUB as your boot loader, confirm that the file /boot/grub/grub.conf contains a title section with the same version as the kernel package you just installed (if you installed the kernel-smp and/or kernel-bigmem packages, you will have a title section for that package has well):

# NOTICE:   You have a /boot partition.      This means that
#           all kernel paths are relative to /boot/
default=0
timeout=30
splashimage=(hd0,0)/grub/splash.xpm.gz
title Red Hat Linux (2.4.18-7.95)
          root (hd0,0)
          kernel /vmlinuz-2.4.18-7.95 ro root=/dev/hda3
          initrd /initrd-2.4.18-7.95.img

If you created a separate /boot partition, the paths to the kernel and initrd image are relative to the /boot partition.

To configure GRUB to boot the new kernel by default, change the value of the default variable to the title section number for the title section that contains the new kernel. The count starts with 0. For example, if the new kernel is the second title section, set the default to 1. You can begin testing your new kernel by rebooting your computer and watching the messages to ensure that your hardware has been detected properly.

LILO

If you selected LILO as your boot loader, confirm that the file /etc/lilo.conf contains an image section with the same version as the kernel package you just installed:

boot=/dev/had
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
linear
default=linux

image=/boot/vmlinuz-2.4.18-7.95
 label=linux
          initrd=initrd-2.4.18-7.95.img
 read-only
 root=/dev/hda5

The kernel RPM package activates the changes by running the command /sbin/lilo. To configure LILO to boot the new kernel by default, set the default variable to the value of label in the image section for the new kernel. You must run the /sbin/lilo command as root in order to enable the changes. After running it, you will see output similar to the following:

Added linux *

The * after linux means that the section labeled linux is the default kernel that LILO will boot. You can begin testing your new kernel by rebooting your computer and watching the messages to ensure your hardware has been detected properly.


Building a Custom Kernel

Many people new to Linux often ask, “Why should I build my own kernel?” Given the advances that have been made in the use of kernel modules, the most appropriate response to that question is, “Unless you already know why you need to build your own kernel, you probably do not need to.” In the past, you had to recompile the kernel if you added new hardware on your system. In other words, the kernel was static. Improvements in the Linux 2.0.x kernels allowed for many hardware drivers to be modularized into components that are loaded on demand. However, major problems existed when users had multiple kernels that had been compiled for different configuration options on their system — for example, SMP versus UP kernels. Further Linux 2.4.x kernel modularization advancements allow for multiple kernels to coexist more easily, but they cannot share modules. Unless you are recompiling a customized kernel for your system, you will not see many changes in how kernel modules are handled.

Building a Modularized Kernel

The instructions in this section apply to building a modularized kernel. If you are interested in building a monolithic kernel instead, see the section “Building a Monolithic Kernel.” The following steps will guide you through building a custom kernel for the x86 architecture:

Note

This example uses 2.4.18-7.95 as the kernel version. Your kernel version might differ. To determine your kernel version, type the command uname -r. Replace 2.4.18-7.95 with your kernel version.

  1. The most important step is to make sure that you have a working emergency boot diskette in case you make a mistake. If you did not make a boot diskette during the installation, use the mkbootdisk command to make one now. The standard command is similar to mkbootdisk --device /dev/fd0 2.4.x (where 2.4.x is the full version of your kernel, such as 2.4.18-7.95). When done, test the boot disk to make sure that it will boot the system.

  2. You must have the kernel-source package installed. Type rpm -q kernel-source to determine the package version, if it is installed. If it is not installed, install it from one of the Red Hat Linux CD-ROMs or the Red Hat FTP site available at ftp://ftp.redhat.com (a list of mirrors is available at http://www.redhat.com/mirrors.html). Refer to Chapter 6 for information on installing RPM packages.

  3. Open a shell prompt and change to the directory /usr/src/linux-2.4. All commands from this point forward must be executed from this directory.

  4. It is important that you begin a kernel build with the source tree in a known condition. Therefore, it is recommended that you begin with the command make mrproper. This will remove any configuration files along with the remains of any previous builds that may be scattered around the source tree. If you already have an existing configuration file that works (/usr/src/linux-2.4/.config) and you want to use it, back it up to a different directory before running this command and copy it back afterwards.

  5. Now you need a configuration file that will determine which components to include in your new kernel. If you are running the X Window System, the recommended method is to use the command make xconfig. Components are listed in different levels of menus and are selected using a mouse. You can select Y (yes), N (no), or M (module). After choosing your components, click the Save and Exit button to create the configuration file /usr/src/linux-2.4/.config and exit the Linux Kernel Configuration program.

If you want to use the settings of a default Red Hat Linux kernel, copy the the configuration file from the /usr/src/linux-2.4/configs directory to /usr/src/linux-2.4/.config. Then, run the make xconfig command and make only the desired changes. Be sure to save your changes to the configuration file. Other available methods for kernel configuration are listed below:

  • make config — An interactive text program. Components are presented in a linear format and you answer them one at a time. This method does not require the X Window System and does not allow you to change your answers to previous questions.

  • make menuconfig — A text-mode, menu-driven program. Components are presented in a menu of categories; you select the desired components in the same manner used in the text-mode Red Hat Linux installation program. Toggle the tag corresponding to the item you want included: [*] (built-in), [ ] (exclude), M (module), or (module capable). This method does not require the X Window System.

  • make oldconfig — This is a non-interactive script that will set up your configuration file to contain the default settings. If you are using the default Red Hat Linux kernel, the script will create a configuration file for the kernel that shipped with Red Hat Linux for your architecture. This is useful for setting up your kernel with known working defaults and then turning off features that you do not want.

Note

To use kmod and kernel modules, you must answer Yes to kmod support and module version (CONFIG_MODVERSIONS) support during the configuration.

  1. After creating a /usr/src/linux-2.4/.config file, use the command make dep to set up all the dependencies correctly.

  2. Use the command make clean to prepare the source tree for the build.

  3. It is recommended that you give the custom kernel you are building a modified version number so that you do not overwrite your existing kernel. The method described here is the easiest to recover from in the event of a mishap. If you are interested in other possibilities, details can be found at http://www.redhat.com/mirrors/LDP/HOWTO/Kernel-HOWTO.html or in the Makefile in /usr/src/linux-2.4. By default, /usr/src/linux-2.4/Makefile includes the word custom at the end of the line beginning with EXTRAVERSION. Appending the string will allow you to have the old working kernel and the new kernel, version 2.4.18-7.95custom, on your system at the same time. To give the kernel an unique name, you can also append the date to the end of the string.

  4. Build the kernel with make bzImage.

  5. Build any modules you configured with make modules.

  6. Use the command make modules_install to install the kernel modules (even if you did not build any). Make sure that you type the underscore (_). This will install the kernel modules into the directory path /lib/modules/KERNELVERSION/kernel/drivers (where KERNELVERSION is the version specified in the Makefile). In the example it would be /lib/modules/2.4.18-7.95custom/kernel/drivers/.

  7. Use make install to copy your new kernel and its associated files to the proper directories. In addition to installing the kernel files in the /boot directory, this command also executes the /sbin/new-kernel-pkg script, which builds a new initrd image and adds new entries to the boot loader configuration file. If you have a SCSI adapter and you compiled the SCSI driver as a module or if you built your kernel with ext3 support as a module (the default in Red Hat Linux), the initrd image is required.

  8. Even though the initrd image and boot loader modifications are made for you, verify that they were done correctly.

Making an initrd Image

An initrd image is needed to load a SCSI module at boot time or if you compiled the kernel with ext3 support as a module. To verify that a new initrd file was created, view the contents of the /boot directory. You should see the file initrd-2.4.18-7.95custom.img, where 2.4.18-7.95custom is the name of the kernel you just built. If it does not exist, use the /sbin/mkinitrd shell script to create it:

/sbin/mkinitrd /boot/initrd-2.4.18-7.95custom.img 2.4.18-7.95custom

In the above example, /boot/initrd-2.4.18-7.95custom.img is the file name of the new initrd image. 2.4.18-7.95custom is the kernel whose modules (from /lib/modules) should be used in the initrd image. This is not necessarily the same as the version number of the currently running kernel.

Building a Monolithic Kernel

To build a monolithic kernel (that is, a kernel which does not use modules), follow the same steps as building a modularized kernel, with a few exceptions.

  • When configuring the kernel, do not compile anything as a module. In other words, answer only Yes or No to the questions. Also, answer No to kmod support and module version (CONFIG_MODVERSIONS) support.

  • Omit the following steps:

    • make modules

    • make modules_install

  • Edit lilo.conf to include the line append=nomodules or append nomodules to the kernel line in grub.conf.


Kernel Modules

The Linux kernel has a modular design. At boot time, only a minimal resident kernel is loaded into memory. Thereafter, whenever a user requests a feature that is not present in the resident kernel, a kernel module is dynamically loaded into memory. After a specified period of inactivity, the module may be removed from memory.

The mechanism that supports dynamic loading of modules is a kernel thread called kmod. Modules are not loaded unless they are needed. When the kernel requests a module, the module is loaded along with all its module dependencies. Red Hat Linux also includes a cron task that removes all unused modules every ten minutes. The cron task is located in the file /etc/cron.d/kmod.

When you install Red Hat Linux, the hardware on your system is probed and you provide information about how the system will typically be used and which programs should be loaded. Based on this probing and the information you provide, the installation program decides which modules need to be loaded at boot time. The installation program sets up the dynamic loading mechanism to work transparently. If you build your own custom kernel, you can make all of these decisions for yourself.

If you add new hardware after installation and the hardware requires a kernel module, you need to set up the dynamic loading mechanism. Kudzu runs when the system boots and usually detects new hardware. You can also add the new driver by editing the module configuration file, /etc/modules.conf.

For example, if your system included a model SMC EtherPower 10 PCI network adapter at the time of installation, the module configuration file will contain the following line:

alias etho0 tulip

After installation, if you install a second, identical network adapter on your system, add the following line to /etc/modules.conf:

alias eth1 tulip

Kernel Module Utilities

You can also use a group of commands to list, load, or unload kernel modules. These commands are useful if you want to try different modules or see if a module has been loaded successfully. The command /sbin/lsmod displays a list of currently loaded modules, as shown in Listing 12-1.

Listing 12-1: Sample lsmod output
Start example
Module               Size      Used by
sr_mod              15264        0 (autoclean)
mga                 95984        1
agpgart             23392        3
nfs                 79008        1 (autoclean)
lockd               52464        1 (autoclean) [nfs]
sunrpc              61328        1 (autoclean) [nfs lockd]
autofs              11264        4 (autoclean)
3c59x               25344        1 (autoclean)
ipchains            38976        0 (unused)
ide-scsi             8352        0
scsi_mod            95104        2 [sr_mod ide-scsi]
ide-cd              26848        0
cdrom               27232        0 [sr_mod ide-cd]
usb-uhci            20720        0 (unused)
usbcore             49664        1 [usb-uhci]
End example

As you can see in this example, lsmod displays the size, use count, and referring modules for each module currently loaded.

To load a kernel module, you can use the command /sbin/insmod followed by the kernel module name. By default, insmod tries to load the module from the /lib/modules/kernel-version/kernel/drivers subdirectories. There is a subdirectory for each type of module, such as the net subdirectory for network interface drivers. Some kernel modules have module dependencies, meaning that other modules must be loaded first before the dependent module can be loaded. To resolve these dependencies, you can either load the module dependencies and then load the module you want, or you can use the command /sbin/modprobe followed by the module name to load the desired module along with its dependencies.

For example, the command

/sbin/modprobe tulip

loads the tulip network interface mdoule.

Another useful kernel module utility is modinfo. You can use the command /sbin/modinfo to display information about a kernel module. The general syntax is

/sbin/modinfo [options] module

Options include –d, which displays a brief description of the module, and –p, which lists the parameters that the module supports. For a complete list of options, refer to the modinfo man page by typing man modinfo.


Additional Resources

For more information on the Linux kernel, refer to these resources.

Installed Documentation

  • /usr/src/linux-2.4/Documentation — Advanced documentation on the Linux kernel and its modules. These documents are written for users interested in contributing to the kernel source code and understanding how the kernel works.

  • lsmod man page — A description and explanation of lsmod output.

  • insmod man page — A description and list of command-line options.

  • modprobe man page — A description and list of command-line options.

  • rmmod man page — A description and list of command-line options.

  • modinfo man page — A description and list of command-line options.

  • /usr/src/linux-2.4/Documentation/kmod.txt — A description of kmod and why it replaced kerneld.

  • /usr/src/linux-2.4/Documentation/modules.txt — How to compile and use kernel modules.

Useful Websites

  • http://www.redhat.com/mirrors/LDP/HOWTO/Kernel-HOWTO.html — The Linux Kernel HOWTO from the Linux Documentation Project.

  • http://www.kernel.org/pub/linux/docs/lkml/ — The linux-kernel mailing list.


Part III: Network Administration

Chapter List

Chapter 13: Network Configuration
Chapter 14: Network Scripts
Chapter 15: Dynamic Host Configuration Protocol (DHCP)
Chapter 16: BIND Configuration
Chapter 17: Lightweight Directory Access Protocol (LDAP)
Chapter 18: Email
Chapter 19: Apache HTTP Server Configuration
Chapter 20: Network File System (NFS) and Samba


Chapter 13: Network Configuration

The Red Hat Linux Network Administration Tool is designed to let the administrator configure a machine’s network settings quickly and easily via a straightforward graphical interface. Using this tool, the administrator can quickly configure the hardware and device settings, as well as configure the list of hosts on the local network (/etc/hosts) and DNS settings.

The Network Administration Tool can be used to configure the following types of network interfaces:

  • Ethernet

  • ISDN

  • modem

  • xDSL

  • token ring

  • CIPE

  • wireless devices

To use the Network Administration Tool, you must be running the X Window System and have root privileges. To start the application, type redhat-config-network at a shell prompt (for example, in an XTerm window or a GNOME terminal window).

Tip

Go to the Red Hat Hardware Compatibility List (http://hardware.redhat.com/hcl/) to determine if Red Hat Linux supports your hardware device.

Overview

To configure a network connection with the Network Administration Tool, perform the following steps:

  1. Add the physical hardware device to the hardware list.

  2. Add a network device associated with the physical hardware device.

  3. Configure any hosts that cannot be looked up through DNS.

  4. Configure the hostname and DNS settings.

This chapter discusses each of these steps for each type of network connection.


Establishing an Ethernet Connection

To establish an Ethernet connection, you need a network interface card (NIC), a network cable (usually a CAT5 cable), and a network to connect to. There are different speeds to networks; make sure your NIC is compatible with the network to which you want to connect. To add an Ethernet connection, follow these steps:

  1. Click the Devices tab.

  2. Click the Add button.

  3. Select Ethernet connection from the Device Type list, and click Forward.

  4. If you have already added the network interface card to the hardware list, select it from the Ethernet card list. Otherwise, select Other Ethernet Card to add the hardware device.

    Note

    The installation program usually detects supported Ethernet devices and prompts you to configure them. If you configured any Ethernet devices during the installation, they will already appear in the hardware list on the Hardware tab.

  5. If you selected Other Ethernet Card, the Select Ethernet Adapter window appears. Select the manufacturer and model of the Ethernet card. Select the device name. If this is the system’s first Ethernet card, select eth0 as the device name; if this is the second Ethernet card, select eth1, and so on. The Network Administration Tool also allows you to configure the resources for the NIC. Click Forward to continue.

  6. On the Configure Network Settings page as shown in Figure 13-1, choose between DHCP and a static IP address. If the device receives a different IP address each time the network is started, do not specify a hostname. Click Forward to continue.

  7. Click Apply on the Create Ethernet Device page. After configuring the Ethernet device, it appears in the device list as shown in Figure 13-2.

Be sure to click Apply to save the changes.

After adding the Ethernet device, you can edit its configuration by selecting the device from the device list and clicking Edit. For example, when the device is added, it is configured to start at boot time by default. You can edit its configuration to modify this setting. When the device is added, it is not activated, as seen by its Inactive status. To activate the device, select it from the device list and click the Activate button.


Establishing an ISDN Connection

An ISDN connection is an Internet connection established with an ISDN modem card through a special phone line installed by the phone company. To add an ISDN connection, follow these steps:

  1. Click the Devices tab.

    Click To expand
    Figure 13-1: Ethernet settings

  2. Click the Add button.

  3. Select ISDN connection from the Device Type list, and click Forward.

  4. Select the ISDN adapter from the pull-down menu. Then configure the resources and D channel protocol for the adapter. Click Forward to continue.

  5. If your ISP is in the pre-configured list, select it. Otherwise, enter the required information about your ISP account. If you do not know the values, contact your ISP. Click Forward.

  6. On the Create Dialup Connection page, click Apply. After configuring the ISDN device, it appears in the device list as an ippp device as shown in Figure 13-4.

Be sure to click Apply to save the changes.

After adding the modem device, you can edit its configuration by selecting the device from the device list and clicking Edit. For example, when the device is added, it is configured not to start at boot time by default. Edit its configuration to modify this setting. Compression, PPP options, login name, password, and more can be changed. When the device is added, it is not activated, as seen by its Inactive status. To activate the device, select it from the device list and click the Activate button.

Click To expand
Figure 13-2: Ethernet device


Establishing a Modem Connection

A modem can be used to configure an Internet connection over an active phone line. An Internet Service Provider (ISP) account (also called a dial-up account) is required. To add a modem connection, follow these steps:

Click To expand
Figure 13-3: ISDN settings

  1. Click the Devices tab.

  2. Click the Add button.

  3. Select Modem connection from the Device Type list, and click Forward.

  4. If there is a modem already configured in the hardware list (on the Hardware tab), the Network Administration Tool assumes you want to use it to establish a modem connection. If there is not a modem already configured, it tries to detect any modems in the system. This probe might take a while.

  5. After probing, the window in Figure 13-5 appears.

  6. Configure the baud rate, flow control, and modem volume. If you do not know these values, accept the defaults. If you do not have touch tone dialing, uncheck the corresponding checkbox.

  7. Click Forward.

  8. If your ISP is in the pre-configured list, select it. Otherwise, enter the required information about your ISP account. If you do not know the values, contact your ISP. Click Forward.

  9. On the Create Dialup Connection page, click Apply. After configuring the modem device, it appears in the device list as shown in Figure 13-6.

    Click To expand
    Figure 13-4: ISDN device

Be sure to click Apply to save the changes.

After adding the modem device, you can edit its configuration by selecting the device from the device list and clicking Edit. For example, when the device is added, it is configured not to start at boot time by default. Edit its configuration to modify this setting. Compression, PPP options, login name, password, and more can be changed. When the device is added, it is not activated, as seen by its Inactive status. To activate the device, select it from the device list and click the Activate button.

Click To expand
Figure 13-5: Modem settings
Click To expand
Figure 13-6: Modem device


Establishing an xDSL Connection

DSL stands for Digital Subscriber Lines. There are different types of DSL, such as ADSL, IDSL, and SDSL. The Network Administration Tool uses the term xDSL to mean all types of DSL connections. Some DSL providers require you to configure your system to obtain an IP address through DHCP with an Ethernet card.

Some DSL providers require you to configure a PPPoE (Point-to-Point Protocol over Ethernet) connection with an Ethernet card. Ask your DSL provider which method to use. If you are required to use DHCP, refer to the “Establishing an Ethernet Connection” section to configure your Ethernet card. If you are required to use PPPoE, follow these steps:

  1. Click the Devices tab.

  2. Click the Add button.

  3. Select xDSL connection from the Device Type list, and click Forward.

  4. If your Ethernet card is already in the hardware list, select the Ethernet Device from the pull-down menu from the page shown in Figure 13-7. Otherwise, the Select Ethernet Adapter window appears.

    Click To expand
    Figure 13-7: xDSL settings

    Note

    The installation program usually detects supported Ethernet devices and prompts you to configure them. If you configured any Ethernet devices during the installation, they will already appear in the hardware list on the Hardware tab.

  5. If the Select Ethernet Adapter window appears, select the manufacturer and model of the Ethernet card. Select the device name. If this is the system’s first Ethernet card, select eth0 as the device name; if this is the second Ethernet card, select eth1, and so on. The Network Administration Tool also allows you to configure the resources for the NIC. Click Forward to continue.

  6. Enter the provider name, login name, and password.

  7. Click Forward.

  8. On the Create DSL Connection page, click Apply. After configuring the DSL connection, it appears in the device list as shown in Figure 13-8.

    Click To expand
    Figure 13-8: xDSL device

Be sure to click Apply to save the changes.

After adding the xDSL connection, you can edit its configuration by selecting the device from the device list and clicking Edit. For example, when the device is added, it is configured not to start at boot time by default. Edit its configuration to modify this setting. When the device is added, it is not activated, as seen by its Inactive status. To activate the device, select it from the device list and click the Activate button.


Establishing a Token Ring Connection

A token ring network is a network in which all the computers are connected in a circular pattern. A token, or a special network packet, travels around the token ring and allows computers to send information to one another.

To add a token ring connection, follow these steps:

Tip

For more information on using a token ring under Linux, refer to the Linux Token Ring Project website at http://www.linuxtr.net.

  1. Click the Devices tab.

  2. Click the Add button.

  3. Select Token Ring connection from the Device Type list, and click Forward.

  4. If you have already added the token ring card to the hardware list, select it from the Ethernet card list. Otherwise, select Other Tokenring Card to add the hardware device.

  5. If you selected Other Tokenring Card, the Select Token Ring Adapter window as shown in Figure 13-9 appears. Select the manufacturer and model of the adapter. Select the device name. If this is the system’s first token ring card, select tr0; if this is the second token ring card, select tr1, and so on. The Network Administration Tool also allows the user to configure the resources for the adapter. Click Forward to continue.

  6. On the Configure Network Settings page, choose between DHCP and static IP address. You may specify a hostname for the device. If the device receives a dynamic IP address each time the network is started, do not specify a hostname. Click Forward to continue.

  7. Click Apply on the Create Ethernet Device page. After configuring the token ring device, it appears in the device list as shown in Figure 13-10.

    Click To expand
    Figure 13-9: Token Ring settings

    Click To expand
    Figure 13-10: Token Ring device

Be sure to click Apply to save the changes.

After adding the device, you can edit its configuration by selecting the device from the device list and clicking Edit. For example, you can configure whether the device is started at boot time. When the device is added, it is not activated, as seen by its Inactive status. To activate the device, select it from the device list and click the Activate button.


Establishing a CIPE Connection

CIPE stands for Crypto IP Encapsulation. It is used to configure an IP tunneling device. For example, CIPE can be used to grant access from the outside world into a virtual private network (VPN). If you need to set up a CIPE device, contact your system administrator for the correct values.

Click To expand
Figure 13-11: CIPE settings


Establishing a Wireless Connection

Wireless Ethernet devices are becoming increasingly popular. The configuration is similar to the Ethernet configuration except that it allows you to configure ESSID (the name of the wireless network), mode, frequency, channel, transmit rate, and key for your wireless device. To add a wireless Ethernet connection, follow these steps:

  1. Click the Devices tab.

  2. Click the Add button.

  3. Select Wireless connection from the Device Type list, and click Forward.

  4. If you have already added the wireless network interface card to the hardware list, select it from the Ethernet card list. Otherwise, select Other Ethernet Card to add the hardware device.

    Note

    The installation program usually detects supported wireless Ethernet devices and prompts you to configure them. If you configured them during the installation program, they will already appear in the hardware list on the Hardware tab.

  5. If you selected Other Ethernet Card, the Select Ethernet Adapter window appears. Select the manufacturer and model of the Ethernet card and the device. If this is the first Ethernet card for the system, select eth0; if this is the second Ethernet card for the system, select eth1, and so on. The Network Administration Tool also allows the user to configure the resources for the wireless network interface card. Click Forward to continue.

  6. On the Configure Wireless Connection page as shown in Figure 13-12, configure the ESSID, mode, frequency, channel, transmit rate, and key for your wireless device.

    Click To expand
    Figure 13-12: Wireless settings

  7. On the Configure Network Settings page, choose between DHCP and static IP address. You may specify a hostname for the device. If the device receives a dynamic IP address each time the network is started, do not specify a hostname. Click Forward to continue.

  8. Click Apply on the Create Wireless Device page. After configuring the wireless device, it appears in the device list as shown in Figure 13-13.

    Click To expand
    Figure 13-13: Wireless device

Be sure to click Apply to save the changes.

After adding the wireless device, you can edit its configuration by selecting the device from the device list and clicking Edit. For example, you can configure the device to activate at boot time. When the device is added, it is not activated, as seen by its Inactive status. To activate the device, select it from the device list and click the Activate button.


Managing Hosts

The Hosts tab allows you to add, edit, or remove hosts to or from the /etc/hosts file. This file contains IP addresses and their corresponding hostnames. When your system tries to resolve a hostname to an IP address or determine the hostname for an IP address, it refers to the /etc/hosts file before using the nameservers (if you are using the default Red Hat Linux configuration). If the IP address is listed in the /etc/hosts file, the nameservers are not used. If your network contains computers whose IP addresses are not listed in DNS, it is recommended that you add them to the /etc/hosts file.

To add an entry to the /etc/hosts file, click Add in the Hosts tab, provide the requested information, and click OK. Click Apply to write the entry to the file.

Warning

Do not remove the localhost entry.
Tip

To change lookup order, edit the /etc/host.conf file. The line order hosts, bind specifies that the /etc/hosts file takes precedence over the nameservers. Changing the line to order bind, hosts configures your system to resolve hostnames and IP addresses using the nameservers first. If the IP address cannot be resolved through the nameservers, your system looks for the IP address in the /etc/hosts file.

Click To expand
Figure 13-14: Hosts configuration


Managing DNS Settings

The DNS tab allows you to configure the system’s hostname, domain, nameservers, and search domain. Nameservers are used to look up other hosts on the network.

Note

The nameservers section does not configure the system to be a nameserver.

If the DNS server names are retrieved from DHCP (or retrieved from the ISP of a modem connection) do not add primary, secondary, or tertiary DNS servers.

Click To expand
Figure 13-15: DNS configuration


Activating Devices

Network devices can be configured to activate at boot time or not to start at boot time. For example, a network device for a modem connection is usually not configured to start at boot time, whereas an Ethernet connection is usually configured to activate at boot time. If your network device is configured not to start at boot time, you can use Red Hat Control Network to activate it after boot time. To start it, select Main Menu Button (on the Panel) > System Tools > Network Device Control or type redhat-control-network.

Click To expand
Figure 13-16: Activating devices

To activate a device, select it from the list and click the Activate button. To stop the device, select it from the list and click Deactivate.


Working with Profiles

Multiple logical network devices can be created for each physical hardware device. For example, if you have one Ethernet card in your system (eth0), you can create logical network devices with different nicknames and different configuration options, all associated with eth0. Logical network devices are different from device aliases. Logical network devices associated with the same physical device must exist in different profiles and cannot be activated simultaneously. Device aliases are also associated with the same physical hardware device, but device aliases associated with the same physical hardware can be activated at the same time. Refer to the “Device Aliases” section of this chapter for details about creating device aliases.

Profiles can be used to create multiple configuration sets for different networks. A configuration set can include logical devices as well as hosts and DNS settings. After configuring the profiles, you can use the Network Administration Tool to switch back and forth between them.

By default, there is one profile called Common. To create a new profile, click the New button in the Active Profile frame. Enter a unique name for the profile. After creating a new profile, if all the devices are not listed for all the profiles, add them by clicking the Add button. If a device already exists for the physical device, use the Copy button to copy the existing device. If you use the Add button, a network alias will be created, which is not correct. The device name should not end with a colon followed by a number.

In the list of devices, there is a column of checkboxes labeled Profile. For each profile, you can check or uncheck devices. Only the checked devices are included for the currently selected profile. For example, Figure 13-17 shows a profile called Office with the logical device eth0_office. It is configured to activate the first Ethernet card using DHCP.

Click To expand
Figure 13-17: Office profile

Notice that the Home profile as shown in Figure 13-18 activates the eth0_home logical device, which is associated with eth0 and is configured to use a static IP address.

Click To expand
Figure 13-18: Home profile

You can also configure eth0 to activate in the Office profile only and activate a ppp (modem) device only in the Home profile. Another example is to have the Common profile activate eth0 and an Away profile activate a ppp device for use while traveling.

A profile cannot be activated at boot time. Only the devices in the Common profile, which are set to activate at boot time, are activated at boot time. After the system has booted, execute the following command to enable a profile (replace profilename with the name of the profile):

redhat-config-network-cmd --profile profilename


Device Aliases

Device aliases are virtual devices associated with the same physical hardware, but they can be activated at the same time to have different IP addresses. They are commonly represented as the device name followed by a colon and a number (for example, eth0:1). They are useful if you want to have more than one IP address for a system but the system has only one network card.

If you have configured a device such as eth0, click the Add button in the Network Administration Tool to create an alias for the device. Select the network device and configure the network settings. The alias will appear in the device list with a device name followed by a colon and the alias number.

Warning

If you are configuring an Ethernet device to have an alias, neither the device nor the alias can be configured to use DHCP. You must configure the IP addresses manually.

Figure 13-19 shows an example of one alias for the eth0 device. Notice the eth0:1 device — the first alias for eth0. The second alias for eth0 would have the device name eth0:2, and so on. To modify the settings for the device alias, such as whether to activate it at boot time and the alias number, select it from the list and click the Edit button.

Click To expand
Figure 13-19: Network device alias example

Select the alias and click the Activate button to activate the alias. If you have configured multiple profiles, select which profiles in which to include it. To verify that the alias has been activated, use the command /sbin/ifconfig. The output should show the device and the device alias with different IP address:

eth0      Link encap:Ethernet    HWaddr 00:A0:CC:60:B7:G4
          inet addr:192.168.100.5      Bcast:192.168.100.255
Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST      MTU:1500    Metric:1
          RX packets:161930 errors:1 dropped:0 overruns:0 frame:0
          TX packets:244570 errors:0 dropped:0 overruns:0 carrier:0
          collisions:475 txqueuelen:100
          RX bytes:55075551 (52.5 Mb)      TX bytes:178108895 (169.8 Mb)
          Interrupt:10 Base address:0x9000

eth0:1    Link encap:Ethernet    HWaddr 00:A0:CC:60:B7:G4
          inet addr:192.168.100.42      Bcast:192.168.100.255
Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST      MTU:1500    Metric:1
          Interrupt:10 Base address:0x9000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1    Mask:255.0.0.0
          UP LOOPBACK RUNNING    MTU:16436    Metric:1
          RX packets:5998 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5998 errors:0 dropped:0 overruns:0
carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1627579 (1.5 Mb)      TX bytes:1627579 (1.5 Mb)


Chapter 14: Network Scripts

Using Red Hat Linux, all network communications occur between configured interfaces and physical networking devices connected to the system. The different types of interfaces that exist are as varied as the physical devices they support. The configuration files for network interfaces and the scripts to activate and deactivate them are located in the /etc/sysconfig/network-scripts/ directory. While the existence of interface files can differ from system to system, the three different types of files that exist in this directory — interface configuration files, interface control scripts, and network function files — work together to enable Red Hat Linux to use various network devices. This chapter explores the relationship between these files and how they are used.

Network Configuration Files

Before we review the interface configuration files themselves, let us itemize the primary configuration files used by Red Hat Linux to configure networking. Understanding the role these files play in setting up the network stack can be helpful when customizing your system. The primary network configuration files are as follows.

/etc/hosts

The main purpose of this file is to resolve hostnames that cannot be resolved any other way. It can also be used to resolve hostnames on small networks with no DNS server. Regardless of the type of network the computer is on, this file should contain a line specifying the IP address of the loopback device (127.0.0.1) as localhost.localdomain. For more information, see the hosts man page.

/etc/resolv.conf

This file specifies the IP addresses of DNS servers and the search domain. Unless configured to do otherwise, the network initialization scripts populate this file. For more information on this file, see the resolv.conf man page.

/etc/sysconfig/network

Specifies routing and host information for all network interfaces.

/etc/sysconfig/network-scripts/ifcfg-interface-name

For each network interface on a Red Hat Linux system, there is a corresponding interface configuration script. Each of these files provides information specific to a particular network interface. See the “Interface Configuration Files” section of this chapter for more information on this type of file and what directives it accepts.

Warning

The /etc/sysconfig/networking/ directory is used by the Network Administration Tool (redhat-config-network), and its contents should not be edited manually. For more information about configuring network interfaces using the Network Administration Tool, see Chapter 13.


Interface Configuration Files

Interface configuration files control the operation of individual network interface devices. As your Red Hat Linux system boots, it uses these files to determine what interfaces to bring up and how to configure them. These files are usually named ifcfg-name, where name refers to the name of the device that the configuration file controls.

Ethernet Interfaces

One of the most common interface files is ifcfg-eth0, which controls the first network interface card, or NIC, in the system. A system with multiple NICs will also have multiple ifcfg-eth files, each one having a unique number at the end of the file name. Because each device has its own configuration file, you can control how each individual interface functions.

Following is a sample ifcfg-eth0 file for a system using a fixed IP address:

DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
NETWORK=10.0.1.0
NETMASK=255.255.255.0
IPADDR=10.0.1.27
USERCTL=no

The values required in an interface configuration file can change based on other values. For example, the ifcfg-eth0 file for an interface using DHCP looks quite a bit different from that for a system using a fixed IP address, because IP information is provided by the DHCP server:

DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes

Most of the time you will probably want to use a GUI utility, such as the Network Administration Tool (redhat-config-network), to make changes to the various interface configuration files.

You can also edit the configuration file for a given network interface manually. Following is a listing of the parameters one can expect to configure in an interface configuration file. Within each of the interface configuration files, the following values are common:

  • BOOTPROTO=protocol, where protocol is one of the following:

    • none — No boot-time protocol should be used.

    • bootp — The BOOTP protocol should be used.

    • dhcp — The DHCP protocol should be used.

  • BROADCAST=address, where address is the broadcast address. This directive is deprecated.

  • DEVICE=name, where name is the name of the physical device (except for dynamically allocated PPP devices, where it is the logical name).

  • DNS{1,2}=address, where address is a nameserver address to be placed in /etc/resolv.conf if the PEERDNS directive is set to yes.

  • IPADDR=address, where address is the IP address.

  • NETMASK=mask, where mask is the netmask value.

  • NETWORK=address, where address is the network address. This directive is deprecated.

  • ONBOOT=answer, where answer is one of the following:

    • yes — This device should be activated at boot time.

    • no — This device should not be activated at boot time.

  • PEERDNS=answer, where answer is one of the following:

    • yes — Modify /etc/resolv.conf if the DNS directive is set. If you are using DCHP, yes is the default.

    • no — Do not modify /etc/resolv.conf.

  • SRCADDR=address, where address is the specified source IP address for outgoing packets.

  • USERCTL=answer, where answer is one of the following:

    • yes — Non-root users are allowed to control this device.

    • no — Non-root users are not allowed to control this device.

Dial-up Interfaces

If you connect to the Internet via PPP dial-up connection, you need a configuration file for that interface as well. This file is created automatically for you when you use wvdial, the Network Administration Tool, or Kppp to create a dial-up account. In addition, any changes to dial-up account settings are reflected in these interface configuration files. The Official Red Hat Linux User’s Guide (Red Hat Press/Wiley, 2003) contains instructions for using these GUI-based dial-up connection tools. You can also create and edit this file manually.

A typical ifcfg-ppp0 file looks like this:

DEVICE=ppp0
NAME=test
WVDIALSECT=test
MODEMPORT=/dev/modem
LINESPEED=115200
PAPNAME=test
USERCTL=true
ONBOOT=no
PERSIST=no
DEFROUTE=yes
PEERDNS=yes
DEMAND=no
IDLETIMEOUT=600

Serial Line Internet Protocol (SLIP) is another dial-up interface, although it is less commonly used. SLIP files have interface configuration file names such as ifcfg-sl0. Among the options not already discussed that may be used in these files are the following:

  • DEFROUTE=answer, where answer is one of the following:

    • yes — Set this interface as the default route.

    • no — Do not set this interface as the default route.

  • DEMAND=answer, where answer is one of the following:

    • yes — This interface will allow pppd to initiate a connection when someone attempts to use it.

    • no — A connection must be manually established for this interface.

  • IDLETIMEOUT=value, where value is the number of seconds of idle activity before the interface disconnects itself.

  • INITSTRING=string, where string is the initialization string passed to the modem device. This option is used primarily with SLIP interfaces.

  • LINESPEED=value, where value is the baud rate of the device. Possible standard values here are 57600, 38400, 19200, and 9600.

  • MODEMPORT=device, where device is the name of the serial device that is used to establish the connection for the interface.

  • MTU=value, where value is the Maximum Transfer Unit (MTU) setting for the interface. The MTU refers to the largest number of bytes of data a frame can carry, not counting its header information. In some dial-up situations, setting this to a value of 576 will result in fewer dropped packets and slightly improve the throughput for a connection.

  • NAME=name, where name is the reference to the title given to a collection of dial-up connection configurations.

  • PAPNAME=name, where name is the username given during the Password Authentication Protocol (PAP) exchange that allows you to connect to a remote system.

  • PEERDNS=answer, where answer is one of the following:

    • yes — Modify the dd system’s /etc/resolv.conf file entries to use the DNS servers provided by the remote system when a connection is established.

    • no — The /etc/resolv.conf file will not be modified.

  • PERSIST=answer, where answer is one of the following:

    • yes — This interface should be kept active at all times, even if deactivated after a modem hangup.

    • no — This interface should not be kept active at all times.

  • REMIP=address, where address is the remote system’s IP address. This is usually left unspecified.

  • WVDIALSECT=name, where name associates this interface with a dialer configuration in /etc/wvdial.conf, which contains the phone number to be dialed and other important information for the interface.

Other Interfaces

Other common interface configuration files that use these options include ifcfg-lo, which controls the IP protocol’s local loopback device; ifcfg-irlan0, which arranges settings for the first infrared device; ifcfg-plip0, which controls the first PLIP device; and ifcfg-tr0, used with the first Token Ring device. A local loopback interface is often used in testing, as well as a variety of applications that require an IP address pointing back to the same system. Any data sent to the loopback device is immediately returned to the host’s network layer.

Warning

Never edit the loopback interface script, /etc/sysconfig/network-scripts/ifcfg-lo, manually. Doing so can prevent the system from operating correctly.

An infrared interface allows information between devices, such as a laptop and a printer, to flow over an infrared link that works in a similar way to an Ethernet device except that it commonly occurs over a peer-to-peer connection. A Parallel Line Interface Protocol (PLIP) connection works much the same way, except that it utilizes a parallel port. Token Ring topologies are not as common on local area networks as they once were, having been eclipsed by Ethernet.

Alias and Clone Files

Two lesser-used types of interface configuration files found in the /etc/sysconfig/network-scripts/ directory are alias and clone files. alias interface configuration files take names in the format of ifcfg-if-name:alias-value, and they allow an alias to point to an interface. For example, a ifcfg-eth0:0 file could be configured to specify DEVICE=eth0:0 and a static IP address of 10.0.0.2, serving as an alias of an Ethernet interface already configured to receive its IP information via DHCP in ifcfg-eth0. At that point, the eth0 device is bound to a dynamic IP address, but it can always be referred to on that system via the fixed 10.0.0.2 IP address.

A clone interface configuration file should follow this naming convention: ifcfg-if-name-clone-name. While an alias file is another way to refer to an existing interface configuration file, a clone file is used to specify additional options when specifying an interface. For example, if you have a standard DHCP Ethernet interface called eth0, it may look similar to this:

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp

Since USERCTL is set to no if it is not specified, users cannot bring this interface up and down. To give users this ability, create a clone by copying ifcfg-eth0 to ifcfg-eth0-user and add the following line:

USERCTL=yes

When a user brings up the eth0 interface with the ifup eth0-user command, the configuration options from ifcfg-eth0 and ifcfg-eth0-user are combined. While this is a very basic example, this method can be used with a variety of options and interfaces. The easiest way to create alias and clone interface configuration files is to use the GUI-based Network Administration Tool. For more on using this tool, see Chapter 13.


Interface Control Scripts

The interface control scripts activate and deactivate system interfaces. There are two primary interface control scripts, /sbin/ifdown and /sbin/ifup, that call on control scripts located in the /etc/sysconfig/network-scripts/ directory.

The two interface control scripts are ifdown and ifup and are symbolic links to scripts in the /sbin/ directory. When either of these scripts is called, they require a value of the interface to be specified, such as:

ifup eth0
Determining IP information for eth0... done.

At that point, the /etc/rc.d/init.d/functions and /etc/sysconfig/network-scripts/network-functions files are used to perform a variety of tasks. See the “Network Functions” section of this chapter for more information. After verifying that an interface has been specified and that the user executing the request is allowed to control the interface, the correct script for the type of interface device brings the interface up or down. The following interface control scripts are the most common:

  • ifup-aliases — Configures IP aliases from interface configuration files when more than one IP address is associated with an interface.

  • ifdown-cipcb and ifup-cipcb — Used to bring Crypto IP Encapsulation (CIPE) connections up and down.

  • ifdown-ipv6 and ifup-ipv6 — Contains IPv6-related function calls using environment variables in various interface configuration files and /etc/sysconfig/network.

  • ifup-ipx — Used to bring up an IPX interface.

  • ifup-plip — Used to bring up a PLIP interface.

  • ifup-plusb — Used to bring up a USB interface for network connections.

  • ifdown-post and ifup-post — Contains commands to be executed after an interface is brought up or down.

  • ifdown-ppp and ifup-ppp — Used to bring a PPP interface up or down.

  • ifup-routes — Adds static routes for a device as its interface is brought up.

  • ifdown-sit and ifup-sit — Contains function calls related to bringing up and down an IPv6 tunnel within an IPv4 connection.

  • ifdown-sl and ifup-sl — Used to bring a SLIP interface up or down.

Be aware that removing or modifying any scripts in the /etc/sysconfig/network-scripts/ directory can cause interface connections to act strangely or fail. Only advanced users should modify scripts related to a network interface.

You can also use the init script /etc/rc.d/init.d/network to activate and deactivate all network interfaces configured to start at boot time with the command:

/sbin/service network action

where action is either start, stop, or restart. You can also use the command /sbin/service/network status to view a list of configured devices and currently active devices.


Network Functions

Red Hat Linux makes use of several files that contain important functions used in various ways to bring interfaces up and down. Rather than force each interface configuration file to contain the same functions as another, these functions are grouped together in a few files that can be accessed when needed.

The most common network functions file is network-functions, located in the /etc/sysconfig/network-scripts/ directory. This file contains a variety of common IPv4 functions useful to many interface control scripts, such as contacting running programs that have requested information about changes in an interface’s status, setting hostnames, finding a gateway device, seeing if a particular device is down or not, and adding a default route.

As the functions required for IPv6 interfaces are different from those required for IPv4 interfaces, a network-functions-ipv6 file exists specifically to hold this information. IPv6 support must be enabled in the kernel in order to communicate via that protocol. A function in this file checks for the presence of IPv6 support. Additionally, functions that configure and delete static IPv6 routes, create and remove tunnels, add and remove IPv6 addresses to an interface, and test for the existence of an IPv6 address on an interface can also be found in this file.


Additional Resources

More information concerning network scripts can be found in the following places.

  • /usr/share/doc/initscripts version/sysconfig.txt — A comprehensive guide to available options for network configuration files, including IPv6 options not covered in this chapter.

  • /usr/share/doc/iproute-version/ip-cref.ps — This PostScript file contains a wealth of information about the ip command, which can be used to manipulate routing tables, among other things. Use ghostview or kghostview to look at this file.


Chapter 15: Dynamic Host Configuration Protocol (DHCP)

Dynamic Host Configuration Protocol (DHCP) is a network protocol for automatically assigning TCP/IP information to client machines. Each DHCP client connects to the centrally located DHCP server, which returns that client’s network configuration including IP address, gateway, and DNS servers.

DHCP is useful for fast delivery of client network configuration. When configuring the client system, the administrator can choose DHCP and not have to enter an IP address, netmask, gateway, or DNS servers. The client retrieves this information from the DHCP server. DHCP is also useful if an administrator wants to change the IP addresses of a large number of systems. Instead of reconfiguring all the systems, the administrator can edit just one DHCP configuration file on the server for the new set of IP address.

If the DNS servers for an organization change, the changes are made on the DHCP server, not on the DHCP clients. Once the network is restarted on the clients (or the clients are rebooted), the changes take effect. Furthermore, if a laptop or any type of mobile computer is configured for DHCP, it can be moved from office to office without being reconfigured as long as each office has a DHCP server that allows it to connect to the network.

Configuring a DHCP Server

You can configure a DHCP server using the configuration file /etc/dhcpd.conf. DHCP also uses the file /var/lib/dhcp/dhcpd.leases to store the client lease database. Refer to the “Lease Database” section of this chapter for more information.

Configuration File

The first step in configuring a DHCP server is to create the configuration file that stores the network information for the clients. Global options can be declared for all clients, or options can be declared for each client system. The configuration file can contain any extra tabs or blank lines for easier formatting. The keywords are case-insensitive, and lines beginning with a hash mark (#) are considered comments.

Two DNS update schemes are currently implemented — the ad hoc DNS update mode and the interim DHCP-DNS interaction draft update mode. If and when these two are accepted as part of the IETF standards process, there will be a third mode — the standard DNS update method. The DHCP server must be configured to use one of the two current schemes. Version 3.0b2pl11 and previous versions used the ad hoc mode; however, it has been deprecated. If you want to keep the same behavior, add the following line to the top of the configuration file:

ddns-update-style ad-hoc;

To use the recommended mode, add the following line to the top of the configuration file:

ddns-update-style interim;

Read the dhcpd.conf man page for details about the different modes.

There are two types of statements in the configuration file:

  • Parameters — state how to perform a task, whether to perform a task, or what network configuration options to send to the client.

  • Declarations — describe the topology of the network, describe the clients, provide addresses for the clients, or apply a group of parameters to a group of declarations.

Some parameters must start with the option keyword and are referred to as options. Options configure DHCP options, whereas parameters configure values that are not optional or control how the DHCP server behaves. Parameters (including options) declared before a section enclosed in curly braces ({ }) are considered global parameters. Global parameters apply to all the sections that follow them.

Note

If you change the configuration file, the changes will not take effect until you restart the DHCP daemon with the command service dhcpd restart.

In Listing 15-1, the routers, subnet-mask, domain-name, domain-name-servers, and time-offset options are used for any host statements declared below them. As shown in Listing 15-1, you can declare a subnet. You must include a subnet declaration for every subnet in your network. If you do not, the DHCP server will fail to start. In this example, there are global options for every DHCP client in the subnet and a range declared. Clients are assigned an IP address within the range.

Listing 15-1: Subnet declaration
Start example
subnet 192.168.1.0 netmask 255.255.255.0 {
           option routers 192.168.1.254;
           option subnet-mask 255.255.255.0;

           option domain-name "example.com";
           option domain-name-servers 192.168.1.1;

           option time-offset -18000; # Eastern Standard Time

 range 192.168.1.10 192.168.1.100;
}
End example

All subnets that share the same physical network should be declared within a shared-network declaration as shown in Listing 15-2. Parameters within the shared network but outside the enclosed subnet declarations are considered global parameters. The name of the shared network should be a descriptive title for the network such as test-lab to describe all the subnets in a test lab environment.

Listing 15-2: shared-network declaration
Start example
shared-network name {
       option domain-name "test.redhat.com";
       option domain-name-servers ns1.redhat.com, ns2.redhat.com;
       option routers 192.168.1.254;
       more parameters for EXAMPLE shared-network
       subnet 192.168.1.0 netmask 255.255.255.0 {
             parameters for subnet
             range 192.168.1.1 192.168.1.31;
}
          subnet 192.168.1.32 netmask 255.255.255.0 {
                parameters for subnet
                range 192.168.1.33 192.168.1.63;
          }
}
End example

As demonstrated in Listing 15-3, the group declaration can be used to apply global parameters to a group of declarations. You can group shared networks, subnets, hosts, or other groups.

Listing 15-3: group declaration
Start example
group {
     option routers                          192.168.1.254;
     option subnet-mask                      255.255.255.0;

     option domain-name                      "example.com";
     option domain-name-servers               192.168.1.1;

     option time-offset   -18000;     # Eastern Standard Time

     host apex {
               option host-name "apex.example.com";
               hardware ethernet 00:A0:78:8E:9E:AA;
               fixed-address 192.168.1.4;
     }

     host raleigh {
               option host-name "raleigh.example.com";
               hardware ethernet 00:A1:DD:74:C3:F2;
               fixed-address 192.168.1.6;
     }
}
End example

To configure a DHCP server that leases a dynamic IP address to a system within a subnet, modify Listing 15-4 with your values. It declares a default lease time, maximum lease time, and network configuration values for the clients. This example assigns IP addresses in the range 192.168.1.10 and 192.168.1.100 to client systems.

Listing 15-4: Range parameter
Start example
default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option domain-name-servers 192.168.1.1, 192.168.1.2;
option domain-name "example.com";

subnet 192.168.1.0 netmask 255.255.255.0 {
     range 192.168.1.10 192.168.1.100;
}
End example

To assign an IP address to a client based on the MAC address of the network interface card, use the hardware ethernet parameter within a host declaration. As demonstrated in Listing 15-5, the host apex declaration specifies that the network interface card with the MAC address 00:A0:78:8E:9E:AA always receives the IP address 192.168.1.4. Notice that you can also use the optional parameter host-name to assign a hostname to the client.

Listing 15-5: Static IP address using DHCP
Start example
host apex {
       option host-name "apex.example.com";
       hardware ethernet 00:A0:78:8E:9E:AA;
       fixed-address 192.168.1.4;
}
End example
Tip

You can use the sample configuration file in Red Hat Linux 8.0 as a starting point and add your own custom configuration options to it. Copy it to its proper location with the command cp /usr/share/doc/dhcp-version-number/dhcpd.conf.sample /etc/dhcpd.conf (where version-number is the DHCP version you are using).

For a complete list of option statements and what they do, refer to the dhcp-options man page.

Lease Database

On the DHCP server, the file /var/lib/dhcp/dhcpd.leases stores the DHCP client lease database. This file should not be modified manually. DHCP lease information for each recently assigned IP address is automatically stored in the lease database. The information includes the length of the lease, to whom the IP address has been assigned, the start and end dates for the lease, and the MAC address of the network interface card that was used to retrieve the lease.

All times in the lease database are in Greenwich Mean Time (GMT), not local time. The lease database is re-created from time to time so that it is not too large. All known leases are saved in a temporary lease database. The dhcpd.leases file is renamed dhcpd.leases~, and the temporary lease database is written to dhcpd.leases.

The DHCP daemon could be killed or the system could crash after the lease database has been renamed to the backup file but before the new file has been written. If this happens, there is no dhcpd.leases file, which is required to start the service. Do not create a new lease file if this occurs. If you do, all the old leases will be lost, and this will cause many problems. The correct solution is to rename the dhcpd.leases~ backup file to dhcpd.leases and then start the daemon.

Tip

Before you start the DHCP server for the first time, it will fail unless there is an existing dhcpd.leases file. Use the command touch /var/lib/dhcp/dhcpd.leases to create the file if it does not exist.

Starting and Stopping the Server

To start the DHCP service, use the command /sbin/service dhcpd start. To stop the DHCP server, use the command /sbin/service dhcpd stop. If you want the daemon to start automatically at boot time, see Chapter 21 for information on how to manage services.

If you have more than one network interface attached to the system, but you want the DHCP server to start on only one of the interface, you can configure the DHCP server to start only on that device. In /etc/sysconfig/dhcpd, add the name of the interface to the list of DHCPDARGS:

# Command line options here

DHCPDARGS=eth0

This is useful if you have a firewall machine with two network cards. One network card can be configured as a DHCP client to retrieve an IP address to the Internet. The other network card can be used as a DHCP server for the internal network behind the firewall. Specifying only the network card connected to the internal network makes the system more secure because users cannot connect to the daemon via the Internet.

Other command-line options that can be specified in /etc/sysconfig/dhcpd are:

  • -p portnum — Specify the udp port number on which dhcpd should listen. The default is port 67. The DHCP server transmits responses to the DHCP clients at a port number one greater than the udp port specified. For example, if you accept the default of port 67, the server listens on port 67 for requests and on port 68 for responses to the client. If you specify a port here and use the DHCP relay agent, you must specify the same port on which the DHCP relay agent should listen. See the “DHCP Relay Agent” section of this chapter for details.

  • -f — Run the daemon as a foreground process. This is used mostly for debugging.

  • -d — Log the DHCP server daemon to the standard error descriptor. This is used mostly for debugging. If this is not specified, the log is written to /var/log/messages.

  • -cf filename — Specify the location of the configuration file. The default location is /etc/dhcpd.conf.

  • -lf filename — Specify the location of the lease database file. If a lease database file already exists, it is very important that the same file be used every time the DHCP server is started. It is strongly recommended that this option be used only for debugging purposes on non-production machines. The default location is /var/lib/dhcp/dhcpd.leases.

  • -q — Do not print the entire copyright message when starting the daemon.

DHCP Relay Agent

The DHCP Relay Agent (dhcrelay) allows you to relay DHCP and BOOTP requests from a subnet with no DHCP server on it to one or more DHCP servers on other subnets. When a DHCP client requests information, the DHCP Relay Agent forwards the request to the list of DHCP servers specified when the DHCP Relay Agent is started. When a DHCP server returns a reply, the reply is broadcast or unicast on the network that sent the original request. The DHCP Relay Agent listens for DHCP requests on all interfaces unless the interfaces are specified in /etc/sysconfig/dhcrelay with the INTERFACES directive. To start the DHCP Relay Agent, use the command service dhcrelay start.


Configuring a DHCP Client

The first step in configuring a DHCP client is to make sure the kernel recognizes the network interface card. Most cards are recognized during the installation process, and the system is configured to use the correct kernel module for the card. If you install a card after installation, Kudzu should recognize it and prompt you to configure the corresponding kernel module for it. Be sure to check the Red Hat Linux Hardware Compatibility List at http://hardware.redhat.com/hcl/.

To configure a DHCP client manually, you need to modify the /etc/sysconfig/network file to enable networking and the configuration file for each network device in the /etc/sysconfig/network-scripts directory. In this directory, each device should have a configuration file named ifcfg-eth0 where eth0 is the network device name. The /etc/sysconfig/network file should contain the following line:

NETWORKING=yes

You might have more information in this file, but the NETWORKING variable must be set to yes if you want networking to start at boot time. The /etc/sysconfig/network-scripts/ifcfg-eth0 file should contain the following lines:

DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes

You need a configuration file for each device that you want to configure to use DHCP. If you prefer a graphical interface for configuring a DHCP client, refer to Chapter 13 for details on using Network Configurator to configure a network interface to use DHCP.


Additional Resources

For configuration options not covered here, please refer to the following resources.

Installed Documentation

  • dhcpd man page — describes how the DHCP daemon works

  • dhcpd.conf man page — explains how to configure the DHCP configuration file; includes some examples

  • dhcpd.leases man page — explains how to configure the DHCP leases file; includes some examples

  • dhcp-options man page — explains the syntax for declaring DHCP options in dhcpd.conf; includes some examples

  • dhcrelay man page — explains the DHCP Relay Agent and its configuration options

Useful Website

  • http://www.linuxdoc.org/HOWTO/mini/DHCP/index.html — DHCP mini-HOWTO from the Linux Documentation Project


Chapter 16: BIND Configuration

The configuration of the Domain Name Service is a large topic — indeed, entire books have been devoted to the subject. This chapter is not an exhaustive guide to DNS or BIND; it is assumed that you have a basic knowledge of both. Rather, the chapter explains the use of the Red Hat Linux BIND Configuration Tool to create BIND server zone files. The BIND Configuration tool creates the /etc/named.conf configuration file and the zone configuration files in the /var/named directory each time you apply your changes.

Note

Do not edit the /etc/named.conf configuration file. The BIND Configuration Tool generates this file after you apply your changes. If you want to configure settings that are not configurable using the BIND Configuration Tool, add them to /etc/named.custom.

The BIND Configuration Tool requires the X Window System and root access. To start the Bind Configuration Tool, go to the Main Menu Button (on the Panel) > Server Settings > Domain Name Service or type the command redhat-config-bind at a shell prompt (for example, in an XTerm or GNOME terminal).

The BIND Configuration Tool configures the default zone directory to be /var/named. All zone files specified are relative to this directory. The BIND Configuration Tool also includes basic syntax checking when values are entered. For example, if a valid entry is an IP address, you are allowed to type only numbers and the dot (.) character into the text area.

The BIND Configuration Tool allows you to add a forward master zone, a reverse master zone, and a slave zone. After adding the zones, you can edit or delete them from the main window as shown in Figure 16-1. After adding, editing, or deleting a zone, you must choose File > Apply in order to write the /etc/named.conf configuration file and all the individual zone files in the /var/named directory. Applying your changes will also cause the named service to reload the configuration files. You can also choose File > Quit and click Save and quit.

Click To expand
Figure 16-1: Adding a forward master zone

Adding a Forward Master Zone

To add a forward master zone (also known as a primary master), click the Add button, select Forward Master Zone, and enter the domain name for the master zone in the Domain name text area. A new window as shown in Figure 16-2 will appear with the following options:

  • Name — Domain name that was just entered in the previous window.

  • File Name — File name of the DNS database file, relative to /var/named. It is preset to the domain name with .zone appended to it.

  • Contact — Email address of the main contact for the master zone.

  • Primary Nameserver (SOA) — State of authority (SOA) record. This specifies the nameserver that is the best resource of information for this domain.

  • Serial Number — The serial number of the DNS database file. This number must be incremented each time the file is changed, so that the slave nameservers for the zone will retrieve the latest data. The BIND Configuration Tool increments this number each time the configuration changes. It can also be incremented manually by clicking the Set button next to the Serial Number value.

  • Time Settings — The Refresh, Retry, Expire, and Minimum TTL (Time to Live) values that are stored in the DNS database file.

  • Records — Add, edit, and delete record resources of type Host, Alias, and Name server.

The configuration shown in Figure 16-2 creates the following entry in /etc/named.conf:

zone     "forward.example.com" {
 type master;
 file    "forward.example.com.zone";
};
Click To expand
Figure 16-2: Adding a reverse master zone

It also creates the file /var/named/forward.example.com.zone with the following information:

$TTL 86400
@        IN      SOA     ns.example.com. root.localhost > 2 ; serial

                                   28800 ; refresh
                                   7200 ; retry
                                   604800 ; expire
                                   86400 ; ttl
                                   )

ns            IN        NS         1.2.3.4

After configuring the forward master zone, click OK to return to the main window as shown in Figure 16-1. From the pull-down menu, choose File > Apply to write the /etc/named.conf configuration file, write all the individual zone files in the /var/named directory, and have the daemon reload the configuration files.


Adding a Reverse Master Zone

To add a reverse master zone, click the Add button and select Reverse Master Zone. Enter the first three octets of the IP address range that you want to configure. For example, if you are configuring the IP address range 192.168.10.0/255.255.255.0, enter 192.168.10 in the IP Address (first 3 Octets) text area. A new window will appear, as shown in Figure 16-3, with the following options:

  • IP Address — The first three octets that you just entered in the previous window.

  • Reverse IP Address — Non-editable. Pre-populated based on the IP Address entered.

  • Contact — Email address of the main contact for the master zone.

  • File Name — File name of DNS database file in the /var/named directory.

  • Primary Nameserver (SOA) — State of authority (SOA) record. This specifies the nameserver that is the best resource of information for this domain.

  • Serial Number — The serial number of the DNS database file. This number must be incremented each time the file is changed, so that the slave nameservers for the zone will retrieve the latest data. The BIND Configuration Tool increments this number each time the configuration changes. It can also be incremented manually by clicking the Set button next to the Serial Number value.

  • Time Settings — The Refresh, Retry, Expire, and Minimum TTL (Time to Live) values that are stored in the DNS database file.

  • Nameservers — Add, edit, and delete name servers for the reverse master zone. At least one nameserver is required.

  • Reverse Address Table — List of IP addresses within the reverse master zone and their hostnames. For example, for the reverse master zone 192.168.10, you can add 192.168.10.1 in the Reverse Address Table with the hostname one.example.com. — the hostname must end with a period (.) to specify that it is a full hostname.

The configuration shown in Figure 16-3 creates the following entry in /etc/named.conf:

zone       "10.168.192.in-addr.arpa" {
             type master;
             file    "10.168.192.in-addr.arpa.zone";
};

Click To expand
Figure 16-3: Adding a slave zone
It also creates the file /var/named/10.168.192.in-addr.arpa.zone with the following information:

$TTL 86400
@            IN       SOA     ns.example.com. root.localhost > 2 ; serial
                              28800 ; refresh
                              7200 ; retry
                              604800 ; expire
                              86400 ; ttk
                              )

@            IN       NS      ns2.example.com.
1            IN       PTR     one.example.com.
2            IN       PTR     two.example.com.

After configuring the reverse master zone, click OK to return to the main window, as shown in Figure 16-1. From the pull-down menu, choose File > Apply to write the /etc/named.conf configuration file, write all the individual zone files in the /var/named directory, and have the daemon reload the configuration files.


Adding a Slave Zone

To add a slave zone (also known as a secondary master), click the Add button and select Slave Zone. Enter the domain name for the slave zone in the Domain name text area. A new window will appear, as shown in Figure 16-4, with the following options:

Figure 16-4: Adding a slave zone

  • Name — The domain name that was entered in the previous window.

  • Masters List — The nameserver from which the slave zone retrieves its data. This value must be a valid IP address. You can enter only numbers and dots (.) in the text area.

  • File Name — File name of the DNS database file in /var/named.

The configuration shown in Figure 16-4 creates the following entry in /etc/named.conf:

zone "slave.example.com" {
          type slave;
          file "slave.example.com.zone";
          masters {
                      1.2.3.4;
                      };
};

The configuration file /var/named/slave.example.com.zone is created by the named service when it downloads the zone data from the master server(s). After configuring the slave zone, click OK to return to the main window as shown in Figure 16-1. From the pull-down menu, choose File > Apply to write the /etc/named.conf configuration file and have the daemon reload the configuration files.


Chapter 17: Lightweight Directory Access Protocol (LDAP)

The Lightweight Directory Access Protocol (LDAP) is a method for organizing information in a hierarchical manner using directories. It can be thought of as a very simple database. Once organized, the data can then be accessed over a network. LDAP is based on the X.500 standard for directory sharing but is not as resource-intensive as X.500. In fact, LDAP is sometimes referred to as “X.500-lite.” LDAP directories can store a variety of information and can even be used to provide user authentication over a network in a manner similar to that of the Network Information System (NIS), allowing a user to access his or her account from any machine on an LDAP-enabled network.

In most cases, however, LDAP is used simply as a virtual phone directory, allowing users to easily access contact information about other users. But LDAP goes beyond a traditional phone directory, because it is capable of propagating its directories to other LDAP servers throughout the world, providing global access to information. Currently, however, LDAP is more commonly used within individual organizations, like universities, government departments, and private companies.

LDAP is a client-server system. The server can use a variety of databases to store a directory, each optimized for quick and copious read operations. When an LDAP client application connects to an LDAP server, it can either query a directory or upload information to it. In the event of a query, the server either answers the query or, if it cannot answer locally, refer the query upstream to a higher-level LDAP server that does have the answer. If the client application is attempting to upload information to an LDAP directory, the server verifies that the user has permission to make the change and then adds or updates the information.

This chapter discusses the configuration and use of OpenLDAP 2.0, an open-source implementation of the LDAPv2 and LDAPv3 protocols.

Why Use LDAP?

The main benefit of LDAP is that information for an entire organization can be consolidated into a central repository. For example, rather than managing user lists for each group within an organization, you can use LDAP as a central directory accessible from anywhere on the network. And since LDAP supports Secure Sockets Layer (SSL) and Transport Layer Security (TLS), sensitive data can be protected from prying eyes.

LDAP also supports a number of back-end databases in which to store directories. This allows administrators the flexibility to deploy the database best suited for the type of information the server is to supply. Also, because LDAP has a well-defined Application Programming Interface (API), the number of LDAP-enabled applications is numerous and increasing in quantity and quality. On the negative side, LDAP can require some work to configure properly.

OpenLDAP 2.0 Feature Enhancements

OpenLDAP 2.0 includes a number of important features:

  • LDAPv3 Support — OpenLDAP 2.0 supports Simple Authentication and Security Layer (SASL), Transport Layer Security (TLS), and Secure Sockets Layer (SSL), among other improvements. Many of the changes in the protocol since LDAPv2 are designed to make LDAP more secure.

  • IPv6 Support — OpenLDAP supports the next-generation Internet Protocol version 6.

  • LDAP Over IPC — OpenLDAP can communicate within a system using interprocess communication (IPC). This enhances security by obviating the need to communicate over a network.

  • Updated C API — Improves the way programmers can connect to and use the application.

  • LDIFv1 Support — Full compliance with the LDAP Data Interchange Format (LDIF) version 1.

  • Enhanced Stand-Alone LDAP Server — Includes an updated access control system, thread pooling, better tools, and much more.


OpenLDAP Daemons and Utilities

The suite of OpenLDAP libraries and tools is spread out over the following packages:

  • openldap — Contains the libraries necessary to run the openldap server and client applications.

  • openldap-clients — Contains command-line tools for viewing and modifying directories on an LDAP server.

  • openldap-server — Contains the servers and other utilities necessary to configure and run an LDAP server.

There are two servers contained in the openldap-servers package: the Standalone LDAP Daemon (/usr/sbin/slapd) and the Standalone LDAP Update Replication Daemon (/usr/sbin/slurpd). The slapd daemon is the actual LDAP server, whereas the slurpd daemon is used to synchronize changes from one LDAP server to other LDAP servers on the network. The slurpd daemon is necessary only when dealing with multiple LDAP servers. To perform administrative tasks, the openldap-server package installs the following utilities into the /usr/sbin/ directory:

  • slapadd — Adds entries from an LDIF file to an LDAP directory. For example, /usr/sbin/slapadd -l ldif-input will read in the LDIF file, ldif-input, containing the new entries.

  • slapcat — Pulls entries out of an LDAP directory in the default format — Berkeley DB — and saves them in an LDIF file. For example, the command /usr/sbin/slapcat -l ldif-output will output an LDIF file called ldif-output containing the entries from the LDAP directory.

  • slapindex — Re-indexes the slapd directory based on the current content.

  • slappasswd — Generates an encrypted user password value for use with ldapmodify or the rootpw value in the slapd configuration file, /etc/openldap/slapd.conf. Execute /usr/sbin/slappasswd to create the password.

    Warning

    Be sure to stop slapd by issuing /usr/sbin/service slapd stop before using slapadd, slapcat, or slapindex. Otherwise, the consistency of the LDAP directory will be at risk.

See the man pages for each of these utilities for more information about how to use them.

The openldap-clients package installs tools used to add, modify, and delete entries in an LDAP directory into /usr/bin/. These tools include the following:

  • ldapmodify — Modifies entries in an LDAP directory, accepting input via a file or standard input.

  • ldapadd — Adds entries to your directory by accepting input via a file or standard input; ldapadd is actually a hard link to ldapmodify -a.

  • ldapsearch — Searches for entries in the LDAP directory using a shell prompt.

  • ldapdelete — Deletes entries from an LDAP directory by accepting input via user input at the terminal or via a file.

With the exception of ldapsearch, each of these utilities is more easily used by referencing a file containing the changes to be made rather than by typing a command for each entry you wish to change in an LDAP directory. The format of such a file is outlined in each application’s man page.

NSS, PAM, and LDAP

In addition to the OpenLDAP packages, Red Hat Linux includes a package called nss_ldap that enhances LDAP’s ability to integrate into both Linux and other UNIX environments. The nss_ldap package provides the following modules:

  • /lib/libnss_ldap- glibc-version.so

  • /lib/security/pam_ldap.so

The libnss_ldap- glibc-version.so module allows applications to look up users, groups, hosts, and other information using an LDAP directory via glibc’s Nameservice Switch (NSS) interface. NSS allows applications to authenticate using LDAP in conjunction with Network Information Service (NIS) name service and flat authentication files.

The pam_ldap module allows PAM-aware applications to authenticate users using information stored in an LDAP directory. PAM-aware applications include console login, POP and IMAP mail servers, and Samba. By deploying an LDAP server on your network, all of these login situations can authenticate against one user ID and password combination, greatly simplifying administration.

PHP4, the Apache HTTP Server, and LDAP

Red Hat Linux includes a package containing LDAP modules for the PHP server-side scripting language. The php-ldap package adds LDAP support to the PHP4 HTML-embedded scripting language via the /usr/lib/php4/ldap.so module. This module allows PHP4 scripts to access information stored in an LDAP directory.

Note

Red Hat Linux 8.0 no longer ships with the auth_ldap package, which provided LDAP support for versions 1.3 and earlier of the Apache HTTP server. See the Apache Software Foundation website at http://www.apache.org/ for details on the status of this module.

LDAP Client Applications

Other graphical LDAP clients that support creating and modifying directories are available, but they do not ship with Red Hat Linux 8.0. One such application is LDAP Browser/Editor — a Java-based tool available at http://www.iit.edu/~gawojar/ldap. Most other LDAP clients access directories as read-only, using them to reference, but not alter, organization-wide information. Some examples of such applications are Mozilla-based Web browsers, Sendmail Balsa, Pine, Evolution, and Gnome Meeting.


LDAP Terminology

An entry is one unit in an LDAP directory. Each entry is identified by its unique Distinguished Name (DN). Each entry has attributes, which are pieces of information directly associated with the entry. For example, an organization could be an LDAP entry. Attributes associated with the organization might be its fax number, its street address, and so on. People can also be entries in the LDAP directory. Common attributes for people include their telephone numbers and email addresses.

Some attributes are required, while others are optional. An objectclass definition sets which attributes are required and which are not for each entry. Objectclass definitions are found in various schema files, located in the /etc/openldap/schema/ directory. The LDAP Data Interchange Format (LDIF) is an ASCII text format for LDAP entries. Files that import or export data to and from LDAP servers must be in LDIF format. An LDIF entry looks similar to the following example:

[ id ]
dn:                             distinguished name
attrtype :                               attrvalue
attrtype :                               attrvalue
attrtype :                               attrvalue

An entry can contain as many attrtype : attrvalue pairs as needed. A blank line indicates the end of an entry.

Warning

All attrtype and attrvalue pairs must be defined in a corresponding schema file in order for LDAP to use this information.

Any value shown in italics is a variable and can be set whenever a new LDAP entry is created, except for id. The id is a number determined by the application you use to edit the entry.

Note

You should never need to edit an LDIF entry manually. Instead, use an LDAP client application, such as the ones listed in the “Open LDAP Daemons and Utilities” section of this chapter.


OpenLDAP Configuration Files

OpenLDAP configuration files are installed into the /etc/openldap/ directory. The following list briefly highlights the most important directories and files:

  • /etc/openldap/schema/ directory — This subdirectory contains the schema used by the slapd daemon. See the “/etc/open/dap/schema Directory” section of this chapter for more information about this directory.

  • /etc/openldap/ldap.conf — This is the configuration file for all client applications that use the OpenLDAP libraries. These include Sendmail, Pine, Balsa, Evolution, and Gnome Meeting.

  • /etc/openldap/slapd.conf — This is the configuration file for the slapd daemon.

    Note

    The nss_ldap package, if installed, will create a file named /etc/ldap.conf. This file is used by the PAM and NSS modules supplied by the nss_ldap package. See the section “Configuring Your System to Authenticate Using OpenLDAP” later in this chapter for more information about this configuration file.

slapd.conf

In order to use the slapd LDAP server, you need to modify its configuration file, /etc/openldap/slapd.conf, to make it specific to your domain and server. The suffix line names the domain for which the LDAP server will provide information. The suffix line should be changed from:

suffix                "dc=your-domain,dc=com"

so that it reflects your domain name. For example:

suffix              "dc=example,dc=com"

The rootdn entry is the Distinguished Name (DN) for a user who is unrestricted by access controls or administrative limit parameters set for operations on the LDAP directory. The rootdn user can be thought of as the root user for the LDAP directory. In the configuration file, change the rootdn line from its default value to something like the example below:

rootdn                "cn=root,dc=example,dc=com"

Change the rootpw line to something like the example below:

rootpw                {SSHA}vv2y+i6V6esazrIv70xSSnNAJE18bb2u

In the rootpw example, you are using an encrypted root password, which is a much better idea than leaving a plaintext root password in the slapd.conf file. To make this encrypted string, type the following command:

slappasswd

You will be prompted to type and then retype a password. The program prints the resulting encrypted password to the terminal.

Warning

LDAP passwords, including the rootpw directive specified in /etc/openldap/slapd.conf, are sent over the network in plaintext unless you enable TLS encryption. For added security, the rootpw directive should be used only if the initial configuration and population of the LDAP directory occur over a network. After the task is completed, it is best to comment out the rootpw directive by preceding it with a hash mark (#).
Tip

If you are using the slapadd command-line tool locally to populate the LDAP directory, using the rootpw directive is not necessary.

The /etc/openldap/schema/ Directory

The /etc/openldap/schema/ directory holds LDAP definitions, previously located in the slapd.at.conf and slapd.oc.conf files. All attribute syntax definitions and objectclass definitions are now located in the different schema files. The various schema files are referenced in /etc/openldap/slapd.conf using include lines, as shown in this example:

include       /etc/openldap/schema/core.schema
include       /etc/openldap/schema/cosine.schema
include       /etc/openldap/schema/inetorgperson.schema
include       /etc/openldap/schema/nis.schema
include       /etc/openldap/schema/rfc822-MailMember.schema
include       /etc/openldap/schema/autofs.schema
include       /etc/openldap/schema/kerberosobject.schema
Warning

You should not modify any of the schema items defined in the schema files installed by OpenLDAP.

You can extend the schema used by OpenLDAP to support additional attribute types and object classes using the default schema files as a guide. To do this, create a local.schema file in the /etc/openldap/schema directory. Reference this new schema within slapd.conf by adding the following line below your default include schema lines:

include                  /etc/openldap/schema/local.schema

Next, go about defining your new attribute types and object classes within the local.schema file. Many organizations use existing attribute types and object classes from the schema files installed by default and modify them for use in the local.schema file. This method can help you to learn the schema syntax while meeting the immediate needs of your organization.

Extending schema to match certain specialized requirements is quite involved and beyond the scope of this chapter. Visit http://www.openldap.org/doc/admin/schema.html for information on writing new schema files.


OpenLDAP Setup Overview

This section provides a quick overview for installing and configuring an OpenLDAP directory. For more details, refer to the following URLs:

  • http://www.openldap.org/doc/admin/quickstart.html — The Quick-Start Guide on the OpenLDAP website.

  • http://www.redhat.com/mirrors/LDP/HOWTO/LDAP-HOWTO.html — The LDAP Linux HOWTO from the Linux Documentation Project, mirrored on Red Hat’s website.

The basic steps for creating an LDAP server are as follows:

  1. Install the openldap, openldap-servers, and openldap-clients RPMs.

  2. Edit the /etc/openldap/slapd.conf file to reference your LDAP domain and server.

  3. Start slapd with the command:

    /sbin/service/ldap start

    After you have configured LDAP correctly, you can use chkconfig, ntsysv, or Services Configuration Tool to configure LDAP to start at boot time. For more information about configuring services, see Chapter 21.

  4. Add entries to your LDAP directory with ldapadd.

  5. Use ldapsearch to see if slapd is accessing the information correctly.

  6. At this point, your LDAP directory should be functioning properly and you can configure any LDAP-enabled applications to use the LDAP directory.


Configuring Your System to Authenticate Using OpenLDAP

This section provides a brief overview of how to configure a Red Hat Linux system to authenticate using OpenLDAP. Unless you are an OpenLDAP expert, you will probably need more documentation than is provided here. Please see the references provided in the “Additional Resources” section for more information.

Install the Necessary LDAP Packages

First, you should make sure that the appropriate packages are installed on both the LDAP server and the LDAP client machines. The LDAP server needs the openldap-server package. The LDAP client machines need the following packages installed: openldap, openldap-clients, and nss_ldap.

Edit the Configuration Files

Use the directions in the following sections to edit each configuration file so that appropriate information is supplied to LDAP processes.

Edit slapd.conf

Edit the /etc/openldap/slapd.conf file to make sure it matches the specifics of your organization.

Edit /etc/ldap.conf and /etc/openldap/ldap.conf

On all client machines, both /etc/ldap.conf and /etc/openldap/ldap.conf need to contain the proper server and search base information for your organization. The simplest way to do this is to run the authconfig application and select Use LDAP on the User Information Configuration screen. You can also edit these files manually.

Edit /etc/nsswitch.conf

On all client machines, the /etc/nsswitch.conf file must be edited to use LDAP. The simplest way to do this is to run the authconfig application and select Use LDAP on the User Information Configuration screen. If editing /etc/nsswitch.conf manually, add ldap to the appropriate fields. For example:

passwd: files ldap
shadow: files ldap
group: files ldap

PAM and LDAP

To have standard PAM-enabled applications use LDAP for authentication, run authconfig and select Use LDAP Authentication on the Authentication Configuration screen. For more on configuring PAM, consult Chapter 25 and the PAM man pages.

Migrating Old Authentication Information to LDAP Format

The /usr/share/openldap/migration/ directory contains a set of shell and Perl scripts for migrating authentication information into LDAP format.

Note

You must have Perl installed on your system to use these scripts.

First, modify the migrate_common.ph file so that it reflects your domain. The default DNS domain should be changed from its default value to something like:

$DEFAULT_MAIL_DOMAIN = "your_company";

The default base should also be changed, to something like:

$DEFAULT_BASE = "dc=your_company,dc=com";

The job of migrating a user database into a format LDAP can read falls to a group of migration scripts installed with the nss_ldap package. Using Table 17-1, decide which script to run in order to migrate your user database.

Table 17-1: LDAP migration scripts
Existing name service | Is LDAP running? | Script to Use
/etc flat files | Yes | migrate_all_online.sh
/etc flat files | No | migrate_all_offline.sh
NetInfo | Yes | migrate_all_netinfo_online.sh
NetInfo | No | migrate_all_netinfo_offline.sh
NIS (YP) | Yes | migrate_all_nis_online.sh
NIS (YP) | No | migrate_all_nis_offline.sh

Run the appropriate script based on your existing name service. The README and the migration-tools.txt files in the /usr/share/openldap/migration directory provide more details on how to migrate the information.


Additional Resources

More information concerning LDAP is available. Please review these sources, especially the OpenLDAP website and the LDAP HOWTO, before configuring LDAP on your system.

Installed Documentation

  • LDAP man pages — The ldap man page is a good place to get started for an introduction to LDAP. Man pages also exist for the various LDAP daemons and utilities.

  • /usr/share/docs/openldap-versionnumber — Contains a general README document and miscellaneous information.

Useful Websites

  • http://www.openldap.org — Home of the OpenLDAP Project. This website contains a wealth of information about configuring OpenLDAP.

  • http://www.redhat.com/mirrors/LDP/HOWTO/LDAP-HOWTO.html — An older but still relevant LDAP HOWTO.

  • http://www.padl.com — Developers of nss_ldap and pam_ldap, among other useful LDAP tools.

  • http://www.innosoft.com/ldapworld — Contains information concerning LDAP RFCs and LDAP version 3 specifications.

  • http://www.kingsmountain.com/ldapRoadmap.shtml — Jeff Hodges’s LDAP Road Map contains links to several useful FAQs and emerging news concerning the LDAP protocol.

  • http://www.webtechniques.com/archives/2000/05/wilcox — A useful look at managing groups in LDAP.

  • http://www.ldapman.org/articles — Articles that offer a good introduction to LDAP, including methods to design a directory tree and customize directory structures.

Related Books

  • Implementing LDAP by Mark Wilcox (Wrox Press, Inc.)

  • Understanding and Deploying LDAP Directory Services by Tim Howes et al. (Macmillan Technical Publishing)


Chapter 18: Email

Email is one of the most widely used services on the Internet. Red Hat Linux offers many ways to serve and access email, whether you are a desktop user or a system administrator. This chapter looks at popular email protocols that are in use today and some of the programs designed to deal with email.

Protocols

Email, like other network services, uses a variety of protocols. These protocols allow different machines, often running different operating systems and using different email programs, to communicate with one another via email. The following protocols are the most commonly used to transfer email from system to system.

IMAP

The Internet Message Access Protocol (IMAP) is a method used by email client applications to access remotely stored messages. With IMAP, email messages remain on the remote mail server, where users can read or delete them and create, rename, or delete mailboxes to store the email. In addition, IMAP is fully compatible with important Internet messaging standards, such as the Multipurpose Internet Mail Extensions (MIME), to allow for receiving attachments. Many email clients that use IMAP can also be configured to cache a copy of the messages locally, so that users can browse previously read messages when they are not directly connected to the IMAP server.

IMAP is primarily used by those who access their email using multiple machines. Also, users who connect to the Internet or a private network via a low-bandwidth connection often use IMAP because only the email header information is pulled off at first. This allows them to defer the downloading of messages containing large attachments until a time when their limited bandwidth is not in use. In the same way, email that users do not want can be deleted without their having to view the message body, saving the need to even download it through their network connections.

The Request for Comment (RFC) documents that cover IMAP contain the assorted details and specifics about how the protocol is designed to work. RFC-1730 first defined the way IMAP is used in version 4, and RFC-2060 discusses the IMAP implementation used with many IMAP servers, called version IMAP4rev1.

The imap package in Red Hat Linux allows users to connect to your system and receive their email using IMAP. Secure IMAP connections are supported through Secure Socket Layer (SSL) technology built into the /usr/sbin/imapd daemon, allowing it to use the /usr/share/ssl/certs/imapd.pem certificate file. The stunnel program is not required to provide SSL-encryption for IMAP connections, though it can be used. See the “Secure Email Servers” section of this chapter for more information concerning these two encryption options.

Other free, as well as commercial, IMAP clients and servers are available, many of which extend the IMAP protocol and provide additional functionality. A comprehensive list can be found at http://www.imap.org/products/longlist.htm.

POP

The Post Office Protocol (POP) allows email clients to download email from remote servers and save those messages on their local machine. Most POP email clients are automatically configured to delete the message on the email server after it has been successfully transferred to the client’s system, though this can usually be changed.

To connect to a POP server, the email client opens a TCP connection to port 110 on the server. At the time the connection is made, the POP server sends the POP client a greeting, after which the two machines send each other commands and responses specified in the protocol. As part of this communication, the POP client is asked to authenticate itself in what is called the Authentication State, where the user’s username and password are sent to the POP server. If authentication is successful, then the POP client moves on to the Transaction State, where commands like LIST, RETR, and DELE can be used to list, download, and delete the messages from the server. Messages set to be deleted are not actually removed from the server until the POP client sends the QUIT command to end the session. At this point, the POP server enters the update state, where it deletes the flagged messages and cleans up any resources remaining from the session.

POP is a much simpler protocol than IMAP, since fewer commands are sent between the client and the server. POP works best for users who have only one system to read email with because they download their messages to that machine. POP also works well if you do not have a constant connection to the Internet or the network containing your mail server.

Several RFCs cover the POP protocol, but RFC-1939 defines the basic outline of POP3, the current version. Occasionally, you may run into lesser-used POP protocol variants:

  • APOP — POP3 with MDS authentication, where an encoded hash of your password is sent from the email client to the server rather than in plain text.

  • KPOP — POP3 with Kerberos authentication. See Chapter 10 for more information about Kerberos authentication.

  • RPOP — POP3 with RPOP authentication, which uses an ID issued per user, similar to a password, to authenticate POP requests. However, this ID is not encrypted, so RPOP is no more secure than standard POP.

Many POP servers, clients, and assorted other applications are available with Red Hat Linux. If you prefer a graphical email client, either Mozilla Mail or Ximian Evolution is a good choice. In addition, other utilities, such as Fetchmail, can retrieve email via POP. If you are using your Red Hat Linux system as a mail server, the imap package installs POP2 (ipop2) and POP3 (ipop3) daemons in the /usr/sbin/ directory.

SMTP

While the IMAP and POP protocols involve allowing users to be able to receive their email, the Simple Mail Transfer Protocol (SMTP) is used to send email. Outgoing email uses SMTP to move from the client’s machine to the server, on its way toward its final destination. Email servers attempting to move a message between one another also use SMTP to communicate.

SMTP uses port 25 on the server for communication. A basic SMTP exchange begins with the connecting system’s issuing a MAIL From: e-mail-address command to initiate exchange. The receiving system responds with a 250 message to acknowledge receipt of the first command. Then, the connecting system hands the email addresses to receive the message to the receiving system, followed by a DATA message. This tells the receiving system that the next part of the communication will be the actual body of the email message. When the connecting system is finished with the email message, it places a single dot (.) on a line. At that point, the message is considered sent.

SMTP also handles cases where email needs to be forwarded between systems, when the receiving system knows where to send the message. The protocol can verify that certain users are served by a particular mail server using the VRFY command or expand a mailing list using the EXPN command. Email can also be relayed between two SMTP servers, if both systems permit such activity.

Unlike IMAP and POP, the SMTP protocol does not require authentication. This means that SMTP servers can allow anyone on the Internet to use your system to send or relay mail to large lists of recipients. It is this characteristic of SMTP that makes spam possible. Modern SMTP applications attempt to minimize this behavior by restricting relaying and allowing only known hosts to send email.

RFC-821 outlines the basic behavior of SMTP, but several SMTP extensions, made possible by RFC-1869, have added additional functionality to SMTP over the years by making new commands available. By initiating a conversation with an SMTP server with an EHLO command rather than HELO, the connecting server can identify itself as one that supports SMTP extensions. The receiving server answers with a 250 line containing the various SMTP extensions it supports. Then, the connecting server can use the supported extensions as it wishes to accomplish the goals of the communication.

One extension adds SMTP Authentication through the AUTH command as outlined in RFC-2554. Another widely used SMTP extension, detailed in RFC-2034, discusses the use of dot-separated, standardized error codes for use between SMTP applications. Reading the various RFCs that involve SMTP provides a background to the way email moves across the Internet. In addition, you can connect to an SMTP server via telnet by specifying port 25, such as telnet localhost 25. Executing a few commands and sending an email message manually is a good way to understand how SMTP communications work.

Red Hat Linux 8.0 uses Sendmail (/usr/sbin/sendmail)as its SMTP program by default. However, an easier-to-use application called Postfix (/usr/sbin/postfix) is also available for use. See the “Mail Transfer Agent” section of this chapter for more on this topic.


Email Program Classifications

In general, all email applications fall into at least one of three classifications. Each of these classifications plays a specific role in the process of moving and managing email messages. While most users are aware of only the specific email program they use to receive and send messages, each of these types is important for making sure email arrives at the correct destination.

Mail User Agent

A Mail User Agent (MUA) is a program that, at the very least, allows a user to read and compose email messages. An MUA is often referred to as an email client. Of course, many MUAs help users do more than that, including retrieving messages via the POP or IMAP protocols, setting up mailboxes to store messages, or helping present new messages to a Mail Transfer Agent that will deliver them to their final destination. MUA programs may be graphical, such as Mozilla Mail, or have a very simple, text-based interface, such as mutt.

Mail Transfer Agent

A Mail Transfer Agent (MTA) transfers email messages between machines using SMTP. A message may involve several MTAs as it moves to its intended destination. Most users are totally unaware of the presence of MTAs, even though every email message is sent through at least one MTA.

While the delivery of messages between machines may seem rather straightforward, the entire process of deciding if a particular MTA can or should accept a message for delivery is quite complicated. In addition, because of problems from spam, use of a particular MTA is usually restricted by the MTA’s own configuration or network access to the system running it.

Many of the larger and more complex MUAs can also be used to send email. However, this action should not be confused with the actions of a true MTA. In order for users not running their own MTA to move outbound messages off their machines and onto a remote machine for delivery, they must use a capacity in the MUA that transfers the message to an MTA they are authorized to use. However, the MUA does not directly deliver the message to the intended recipient’s email server — that role is reserved for the MTA.

Red Hat Linux uses Sendmail as its default MTA, though others may be used in its place.

Mail Delivery Agent

A Mail Delivery Agent (MDA) is used by the MTA to deliver email to a particular user’s mailbox. In many cases, an MDA is actually a Local Delivery Agent (LDA), such as /bin/mail or procmail. However, Sendmail can also play the role of an MDA, such as when it accepts a message for a local user and appends it to the user’s email spool file. Any program that actually handles a message for delivery to the point where it can be read by an MUA can be considered an MDA. Note that MDAs do not transport messages between systems or interface with the end user.

Many users do not directly use MDAs, because only MTAs and MUAs are necessary to send and receive email. However, some MDAs may be used to sort messages before they are read by a user, which is a big help for people who receive a lot of email.


Sendmail

Red Hat Linux uses Sendmail as its default MTA, whether outgoing mail messages are intended for users on the same system or for remote destinations. Other MTAs do exist, but many system administrators elect to use Sendmail as their MTA because of its power, scalability, and compliance with important Internet standards, such as SMTP. Sendmail’s core duty, like that of other MTAs, is to safely move email between hosts, usually using the SMTP protocol. However, Sendmail is highly configurable, allowing one to control almost every aspect of how email is handled, including the protocol used.

History

Sendmail’s roots can be traced to the birth of email, occurring in the decade before the birth of ARPANET, the precursor to the Internet. In those days, every user’s mailbox was a file that only the user had rights to read, and mail applications simply added text to that file. Every user had to wade through the mail file to find any old mail, and reading new mail was equally difficult. The first actual transfer of a mail message file from one host to another did not take place until 1972, when email began to be moved by FTP over the NCP network protocol. This easier method of communication quickly became popular, even to the point where it made up most of ARPANET’s traffic in less than a year.

However, a lack of standardization between competing protocols made email much harder to send from some systems. This continued until ARPANET adopted TCP/IP as its standard in 1982. Soon after, a new protocol, SMTP, materialized for transporting email messages. These developments, combined with HOSTS files being replaced with DNS, allowed full-featured MTAs to materialize. Sendmail, which grew out of an earlier email delivery system called Delivermail, quickly became the standard as email began to expand and become widely used.

Purpose and Limitations

It is important to be aware of what Sendmail is and what it can do for you as opposed to what it is not. In these days of monolithic applications that fulfill multiple roles, you might initially think that Sendmail is the only application you need to run an email server within your organization. Technically, this is true, as Sendmail can spool mail to your users’ directories and accept new email via the command line. But, most users actually require much more than simple email delivery. They usually want to interact with their email using an MUA that uses POP or IMAP to download their messages to their local machine. Or, they may prefer a Web interface to gain access to their mailbox. These other applications can work in conjunction with Sendmail and SMTP, but they actually exist for different reasons and can operate separately from one another.

It is beyond the scope of this book to go into all that Sendmail should or could be configured to do. With literally hundreds of different options and rule sets, entire volumes are dedicated to helping explain everything that can be done and how to fix things that go wrong. You should consult the many excellent resources on Sendmail in order to shape it to fit your exact specifications. However, you should understand what files are installed with Sendmail by default on your system and know how to make basic configuration changes. You should also be aware of how to stop unwanted email (spam) and how to extend Sendmail with the Lightweight Directory Access Protocol (LDAP).

The Default Sendmail Installation

While you can download the source code for Sendmail and build your own copy, many users prefer to use the version of Sendmail installed by default with their Red Hat Linux system. You can also use the Red Hat Linux CD-ROMs to reinstall the sendmail RPM at a later point. Be aware that you must alter the default configuration file for Sendmail to use it as a mail server for machines other than the machine upon which it is installed (the localhost).

After installation, the Sendmail executable is placed in the /usr/sbin/ directory. Sendmail’s lengthy and detailed configuration file, sendmail.cf, is installed in the /etc/mail/ directory. Avoid editing the sendmail.cf file directly. Instead, to make configuration changes to Sendmail, edit the /etc/mail/sendmail.mc file, back up the original /etc/mail/sendmail.cf, and then use the included m4 macro processor to create a new /etc/mail/sendmail.cf. More information on configuring Sendmail can be found in the “Common Sendmail Configuration Changes” section of this chapter.

Various Sendmail configuration files are installed in the /etc/mail/ directory, including:

  • access — Specifies which systems can use Sendmail for relaying email.

  • domaintable — Allows you to provide domain name mapping.

  • local-host-names — The place where you include all aliases for your machine.

  • mailertable — Specifies instructions that override routing for particular domains.

  • virtusertable — Permits you to do a domain-specific form of aliasing, allowing multiple virtual domains to be hosted on one machine.

Several of the configuration files in /etc/mail/, such as access, domaintable, mailertable, and virtusertable, must actually store their information in database files before Sendmail can use any configuration changes. To include any changes you make to these configurations in their database files, you must run the makemap hash /etc/mail/name/etc/mail/ name command, where name is the name of the configuration file to convert.

For example, if you want all email addressed to any domain.com account to be delivered to bob@otherdomain.com, you need to add a line similar to the one below to the virtusertable file:

@domain.com               bob@otherdomain.com

Then, to add this new information to the virtusertable.db file, execute makemap hash /etc/mail/virtusertable /etc/mail/virtusertable as root. This will create a new virtusertable.db containing the new configuration.

Common Sendmail Configuration Changes

Although a default sendmail.cf file is installed in /etc/mail/ during the Red Hat Linux installation process, you will need to alter it in order to use some of the program’s more advanced features. When altering the Sendmail configuration file, it is best to generate a entirely new /etc/mail/sendmail.cf file instead of editing an existing one.

Warning

Before changing the sendmail.cf file, it is a good idea to back up the default version.

To add the desired functionality to Sendmail, edit the /etc/mail/sendmail.mc file. When you are finished, use the m4 macro processor to generate a new sendmail.cf by executing the m4 /etc/mail/sendmail.mc /etc/mail/sendmail.cf command. After creating a new /etc/mail/sendmail.cf, you must restart Sendmail to make it take effect. The easiest way to do this is to type the /sbin/service sendmail restart command as root. By default, the m4 macro processor is installed with Sendmail and is part of the sendmail-cf package.

Note

The default sendmail.cf does not allow Sendmail to accept network connections from any host other than the local computer. If you want to configure Sendmail as a server for other clients, edit /etc/mail/sendmail.mc and change DAEMON_OPTIONS to also listen on network devices or comment out this option altogether. Then regenerate /etc/mail/sendmail.cf by running m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf.

This configuration should work for most SMTP-only sites. It will not work for UUCP (UNIX to UNIX Copy) sites; you will need to generate a new sendmail.cf if you must use UUCP mail transfers. Consult the /usr/share/sendmail-cf/README file before you edit any of the files in the directories under the /usr/share/sendmail-cf directory, as they can affect how future /etc/mail/sendmail.cf files are configured.

Masquerading

One common Sendmail configuration is to have a single machine act as a mail gateway for all the machines on the network. For instance, a company may want to have a machine called mail.bigcorp.com that handles all their email and assigns a consistent return address to all outgoing mail.

In this situation, the Sendmail server needs to masquerade the machine names on the company network so that their return address is user@bigcorp.com instead of user@devel.bigcorp.com. To do this, add the following lines to /etc/mail/sendmail.mc.

FEATURE(always_add_domain)dnl
FEATURE(`masquerade_entire_domain')
FEATURE(`masquerade_envelope')
FEATURE(`allmasquerade')
MASQUERADE_AS(`bigcorp.com.')
MASQUERADE_DOMAIN(`bigcorp.com.')
MASQUERADE_AS(bigcorp.com)

After you’ve generated a new sendmail.cf using m4, this configuration will make all mail from inside the network appear as if it had been sent from bigcorp.com.

Stopping Spam with Sendmail

Email spam can be defined as unnecessary and unwanted email received by a user who never requested the communication. It is a disruptive, costly, and widespread abuse of Internet communication standards. Sendmail has made it relatively easy to block new spamming techniques being employed to send junk email using your system. It even blocks many of the more usual spamming methods by default. You would need to consciously permit these methods by changing your /etc/mail/sendmail.mc file in a particular way to make your system susceptible.

For example, forwarding of SMTP messages, also referred to as SMTP relaying, has been disabled by default since Sendmail version 8.9. Before this change occurred, Sendmail would direct your mail host (x.org) to accept messages from one party (y.com) and send them to a different party (z.net). Now, however, you have to specifically tell Sendmail to permit a domain to relay mail through your domain. Simply edit the /etc/mail/relay-domains file and restart Sendmail by typing the /sbin/service sendmail restart command as root to activate the changes.

However, many times, your users may be bombarded with spam from other servers throughout the Internet that are beyond your control. In these instances, you can use Sendmail’s access control features available through the /etc/mail/access file. As root, add the domains that you would like to block or specifically allow access to, such as in this example:

badspammer.com         550 Go away and do not spam us anymore
tux.badspammer.com     OK
10.0                   RELAY

Because /etc/mail/access.db is a database, you need to use makemap to activate your changes by re-creating the database map. This is easily done by running the makemap hash /etc/mail/access /etc/mail/access command as root.

This example shows that any email sent from badspammer.com would be blocked with a 550 RFC-821 compliant error code and a message would be sent back to the spammer, except for email sent from the tux.badspammer.com sub-domain, which would be accepted. The last line shows that any email sent from the 10.0.*.* network can be relayed through your mail server.

As you might expect, this example only scratches the surface of what Sendmail can do in terms of allowing or blocking access. See /usr/share/doc/sendmail/README.cf for more detailed information and examples.

Using Sendmail with LDAP

Using the Lightweight Directory Access Protocol (LDAP) is a very quick and powerful way to find specific information about a particular user from a much larger group. For example, you could use an LDAP server to look up a particular email address from a common corporate directory by a user’s last name. In this kind of implementation, LDAP is largely separate from Sendmail, with LDAP storing the hierarchical user information and Sendmail only being given the result of LDAP queries in pre-addressed email messages.

However, Sendmail supports a much greater integration with LDAP, where it uses LDAP to replace separately maintained files, such as aliases and virtusertables, on different mail servers that work together to support a medium-sized to enterprise-level organization. In short, you can use LDAP to abstract the mail routing level from Sendmail and its separate configuration files to a powerful LDAP cluster that is being leveraged by many different applications.

The current version of Sendmail contains support for LDAP. To extend your Sendmail server using LDAP, first get an LDAP server, such as OpenLDAP, running and properly configured. Then, you need to edit your /etc/mail/sendmail.mc file to include the following:

LDAPROUTE_DOMAIN('yourdomain.com')dnl
FEATURE('ldap_routing')dnl
Note

This is only for a very basic configuration of Sendmail with LDAP. Your configuration should differ greatly from this depending on your implementation of LDAP, especially if you wish to configure several Sendmail machines to use a common LDAP server. Consult /usr/share/doc/sendmail/README.cf for detailed LDAP routing configuration instructions and examples.

Next, re-create your /etc/mail/sendmail.cf file by running m4 and restarting Sendmail. See the “Common Sendmail Configuration Changes” section of this chapter for instructions on doing this. For more information on LDAP, see Chapter 17.


Fetchmail

Fetchmail is a program that can retrieve email from remote servers for on-demand TCP/IP connections. Many users appreciate the ability to separate the process of downloading their messages located on a remote server from the process of reading and organizing their email in an MUA. Designed with the needs of dial-up users in mind, Fetchmail will connect and quickly download all of your email messages to your mail spool file using any number of protocols, including POP3 and IMAP. It can even forward your email messages to an SMTP server, if necessary.

Before attempting to use Fetchmail, be sure that it is installed on your system. If it is not, you can install it using the fetchmail RPM on the Red Hat Linux CD-ROMs. Fetchmail is configured for each user through the use of a .fetchmailrc file in the user’s home directory. A program bundled with Fetchmail, called fetchmailconf, is very helpful for configuring a basic .fetchmailrc file that you can customize at will. Using preferences in the .fetchmailrc file, Fetchmail will check for email on a remote server and retrieve it, attempting to deliver it to port 25 on the local machine, using the local MTA to place the email in the correct user’s spool file. If Procmail is available, it can then be used to filter the email and place it in a mailbox so that it can be read with an MUA.

Fetchmail Configuration Options

Although it is possible to pass all options on the command line necessary to check for email on a remote server when executing Fetchmail, using a .fetchmailrc file is much easier. All of your configuration options go in the .fetchmailrc file, but you can override them at the time Fetchmail is run by specifying that option on the command line.

A user’s .fetchmailrc file is divided into three particular types of configuration options:

  • Global options — Gives Fetchmail instructions that control the operation of the program or provide settings for every connection that checks for email.

  • Server options — Specifies necessary information about the server being polled, such as the hostname, as well as preferences you would like to see enforced with a particular email server, such as the port to check or number of seconds to wait before timing out. These options affect every user option used with that server.

  • User options — Contains information, such as username and password, necessary to authenticate and check for email using a particular email server.

Global options go at the top of the .fetchmailrc file, followed by one or more server options, each of which designates a different email server that Fetchmail should check. User options follow server options for each user account you would like to check on that email server. Like server options, multiple user options may be specified for use with a particular server, such as when you would like to check multiple email accounts on the same server.

Server options are called into service in the .fetchmailrc file by the use of a special option verb, poll or skip, that precedes any of the server information. The poll action tells Fetchmail to use this server option when it is run, which actually checks it for email using the various user options. Any server options after a skip action, however, are not checked unless you specify this server’s hostname when Fetchmail is invoked. The skip option allows you to set up test configurations in .fetchmailrc and check using that server only when specifically desired, without affecting any currently working configurations.

A sample .fetchmailrc file looks like this:

set postmaster "user1"

set bounce-mail

poll pop.domain.com proto pop3
    user 'user1' there with password 'secret' is user1 here

poll mail.domain2.com
    user 'user5' there with password 'secret2' is user1 here
    user 'user7' there with password 'secret3' is user1 here

In this example, the global options are set so the user is sent email as a last resort (postmaster option) and all email errors are sent to the postmaster instead of the sender (bounce-mail option). The set action tells Fetchmail that this line contains a global option. Then, two email servers are specified, one set to check using POP3, and the other for trying various protocols to find one that works. Two users are checked using the second server option, but all email found for any users is sent to user1’s mail spool. This allows multiple mailboxes to be checked on multiple servers, while appearing in a single MUA inbox. Each user’s specific information begins with the user action.

Note

You do not have to place your password in the .fetchmailrc file. You can omit the password with the password password section. Fetchmail will then ask for your password when it is started with the fetchmail command.

While you can set up your .fetchmailrc file manually, it is much easier to let the included fetch-mailconf program do it for you. However, when testing new configurations, it is usually easier to edit the .fetchmailrc file directly.

As expected with a program that services such a mature network service as email and uses so many protocols, Fetchmail contains many different global, server, and local options. Many of these options are rarely used or apply to very specific situations only. The fetchmail man page explains each of these options in detail. The most common ones are listed here.

Global Options

Each global option should be placed on a single line after a set action.

  • daemon seconds — Tells Fetchmail to automatically use daemon-mode, where it will stay in the background and poll for mail at the interval specified.

  • postmaster — Gives Fetchmail a local user to send mail to in case of delivery problems.

  • syslog — Tells Fetchmail to start logging errors and status messages in the system’s log file. By default, this is /var/log/maillog.

Server Options

Place server options on their own line in .fetchmailrc after a poll or skip action.

  • auth auth-type — Specifies the type of authentication to be used. By default, password authentication is used, but some protocols support other types of authentication, including kerberos_v5, kerberos_v4, and ssh. If the “any authentication” type is used, Fetchmail will first try methods that do not require a password and then methods that mask your password, and finally it will attempt to send your password in the clear to authenticate to the server.

  • interval number — Tells Fetchmail to poll only this server every number of times that it checks for email on all configured servers. This option might be used with email servers on which you rarely receive messages.

  • port port-number — Overrides the default port number for a specified protocol.

  • proto protocol — Tells Fetchmail to use a specific protocol, such as POP3 or IMAP, to check for messages on this server.

  • timeout seconds — Configures Fetchmail to give up after a certain interval of server inactivity. If this value is not set, a default of 300 seconds is assumed.

User Options

User options may be placed on their own lines beneath a server option or on the same line as the server option. In either case, the user options follow the user name option (defined below).

  • fetchall — Orders Fetchmail to download all messages in the queue, including messages that have already been viewed. By default, Fetchmail pulls down new messages only.

  • fetchlimit number — Allows only a certain number of messages to be retrieved before stopping.

  • flush — Tells Fetchmail to delete all previously viewed messages in the queue before retrieving new messages.

  • limit max-number-bytes — Allows you to specify that only messages below a particular size may be retrieved. This option is useful with slow network links, when a large message will take too long to download.

  • password password — Specifies the password to be used for this user.

  • preconnect command — Tells Fetchmail to execute the specified command before retrieving messages for this user.

  • postconnect command — Tells Fetchmail to execute the specified command after retrieving messages for this user.

  • ssl — Allows Fetchmail to collect the message via an encrypted SSL connection, if the server supports this.

  • user username — Sets the username used by Fetchmail to retrieve messages. This option should be listed before any other user options.

Fetchmail Command Options

Most of the Fetchmail options that may be used on the command line, when executing the fetchmail command, mirror the .fetchmailrc configuration options. This is done so that Fetchmail may be used with or without a configuration file. Most users will not use these options on the command line, as it is easier to leave them in the .fetchmailrc file to be used automatically whenever Fetchmail is run. However, there are times when you may want to run the fetchmail command with other options for a particular purpose. As any options specified at the command line override configuration file options, you can also issue command options to temporarily override a .fetchmailrc setting that is causing an error.

Informational or Debugging Options

Certain options used after the fetchmail command can provide you with important information.

  • --configdump — Displays every possible option based on information from .fetchmailrc and Fetchmail defaults. No email is retrieved for any users when this option is used.

  • -s — Executes Fetchmail in silent mode, preventing any messages, other than error messages, from appearing after the fetchmail command.

  • -v — Executes Fetchmail in verbose mode, displaying every communication between Fetchmail and the remote email servers.

  • -V — Causes Fetchmail to display detailed version information, list its global options, and show settings to be used with each user, including the email protocol and authentication method. No email is retrieved for any users when this option is used.

Special Options

These options are occasionally useful for overriding defaults often found in the .fetchmailrc file.

  • -a — Tells Fetchmail to download all messages from the remote email server, whether new or previously viewed. By default, Fetchmail will download only new messages.

  • -k — Causes Fetchmail to leave messages on the remote email server after downloading them. This option overrides the default behavior of deleting messages after downloading them.

  • -l max-number-bytes — Tells Fetchmail to not download any messages over a particular size and to leave them on the remote email server.

  • --quit — Quits the Fetchmail daemon process.

More commands and .fetchmailrc options can be found on the fetchmail man page.


Procmail

Procmail allows you to filter email as it is received from a remote email server, or placed in your spool file on a local or remote email server. It is powerful, gentle on system resources, and widely used. Procmail, commonly referred to as a Local Delivery Agent (LDA), plays a small role in delivering email to be read by an MUA. In order for you to use Procmail, it must first be installed. Type the rpm -q procmail command to see if the procmail package is installed. If for some reason Procmail is not on your system, install it from the Red Hat Linux installation CD-ROMs.

Procmail can be invoked in several different ways. As email is placed on your email spool file, Procmail can be configured to start up, filter the email to locations configured for use with your MUA, and quit. Or, your MUA could be configured to bring up Procmail any time a message is received so that messages are moved into their correct mailboxes. In many cases, the presence of a .procmailrc file in the user’s home directory will invoke Procmail, if Sendmail is being used.

The actions Procmail takes with an email message are dependent upon instructions from particular recipes, or rules, that messages are matched against by the program. If a message matches the recipe, then the email is placed in a certain file, deleted, or otherwise processed. When Procmail starts, it reads the email message and separates the body from the header information. Next, Procmail looks for the /etc/procmailrc file and rc files in the /etc/procmailrcs directory for default, system-wide Procmail environmental variables and recipes. Then, Procmail looks for a .procmailrc file in the user’s home directory to find rules specific to that user. Many users also create additional rc files of their own for Procmail that are referred to by their .procmailrc file but may be turned on or off quickly if a mail filtering problem develops.

By default, no system-wide rc files exist in the /etc directory, and no user .procmailrc files exist. To begin using Procmail, you will need to construct a .procmailrc file with particular environment variables and recipes explaining what you would like to do with certain messages. In most configurations, the decision as to whether Procmail starts and attempts to filter your email is based on the existence of a user’s .procmailrc file. To disable Procmail but save your work on the .procmailrc file, save it with a different name using the mv ~/.procmailrc ~/.procmail-rcSAVE command. When you are ready to begin testing Procmail again, change the name of the file back to .procmailrc. Procmail will begin working again immediately.

Procmail Configuration

Procmail configuration files, most notably the user’s .procmailrc, contain important environmental variables. These variables tell Procmail which messages to sort, what to do with the messages that do not match any recipes, and so on. These environmental variables usually appear at the beginning of .procmailrc in the following format:

env-variable =" value "

In this example, env-variable is the name of the variable, and the value section defines the variable. Many environment variables are not used by most Procmail users, and many of the more important environment variables are already assigned a default value. Most of the time, you will be dealing with the following variables:

  • DEFAULT — Sets the default mailbox where messages that do not match any recipes will be placed. The default DEFAULT value is the same as $ORGMAIL.

  • INCLUDERC — Specifies additional rc files containing more recipes for messages to be checked against. This allows you to break up your Procmail recipe lists into individual files that fulfill different roles, such as blocking spam and managing email lists, that can then be turned off or on by using comment characters in the user’s .procmailrc file. For example, three lines in a user’s .procmailrc file may look like this:

    MAILDIR=$HOME/Msgs
INCLUDERC=$MAILDIR/lists.rc
INCLUDERC=$MAILDIR/spam.rc

  • Users who want to turn off the Procmail filtering of their email lists but leave spam control in place can simply comment out the first INCLUDERC line with a # character.

  • LOCKSLEEP — Sets the amount of time, in seconds, between attempts by Procmail to use a particular lockfile. The default is eight seconds.

  • LOCKTIMEOUT — Sets the amount of time, in seconds, that must pass after a lockfile was last modified before Procmail will assume that the lockfile is simply old and can be deleted. The default is 1,024 seconds.

  • LOGFILE — The location and file to contain any Procmail informational or error messages.

  • MAILDIR — Sets the current working directory for Procmail. If set, all other Procmail paths are relative to this directory.

  • ORGMAIL — Specifies the original mailbox, or another place to put the messages if they cannot be placed in the default or recipe-required location. By default, a value of /var/spool/mail/$LOGNAME is used.

  • SUSPEND — Sets the amount of time, in seconds, that Procmail will pause if a necessary resource, such as swap space, is not available.

  • SWITCHRC — Allows a user to specify an external file containing additional Procmail recipes, much like the INCLUDERC option, except that recipe checking is actually stopped on the referring configuration file and only the recipes on the SWITCHRC-specified file are used.

  • VERBOSE — Causes Procmail to log more information than is recorded by default. This option is useful for debugging.

Other important environmental variables are pulled from your shell, such as LOGNAME, which is your login name; HOME, which is the location of your home directory; and SHELL, which is your default shell. A comprehensive explanation of all environments variables, as well as their default values, is available on the procmailrc man page.

Procmail Recipes

New users often find the construction of recipes the most difficult part of learning to use Procmail. To some extent, this is understandable, as recipes do their message matching using regular expressions, which is a particular format used to specify qualifications for a matching string. However, regular expressions are not very difficult to construct and even less difficult to understand when read. Additionally, the consistency of the way Procmail recipes are written, regardless of regular expressions, makes it easy to figure out what is going on.

A thorough explanation of regular expressions is beyond the scope of this book. The structure of Procmail recipes is more important, and useful sample Procmail recipes can be found at various places on the Internet, including http://www.iki.fi/era/procmail/links.html. The proper use and adaptation of the regular expressions found in these recipe examples depends upon an understanding of Procmail recipe structure. Introductory information specific to basic regular expression rules can be found on the grep man page.

A Procmail recipe takes the following form:

:0 flags : lockfile-name
*  special-condition-character condition-1
*  special-condition-character condition-2
*  special-condition-character condition-N
special-action-character action-to-perform

The first two characters in a Procmail recipe are a colon and a zero. Various flags can optionally be placed after the zero to control what Procmail does when processing this recipe. A colon after the flags section specifies that a lockfile will be created for this message. If a lockfile is to be created, you specify its name in the lockfile-name space.

A recipe can contain several conditions to match against the message. If it has no conditions, every message will match the recipe. Regular expressions are placed in some conditions in order to facilitate a match with a message. If multiple conditions are used, they must all match in order for an action to be performed. Conditions are checked based on the flags set in the recipe’s first line. Optional special characters placed after the * character can further control the condition. The action-to-perform specifies what is to happen to a message if it matches one of the conditions. There can be only one action per recipe. In many cases, the name of a mailbox is used here to direct matching messages into that file, effectively sorting the email. Special action characters may also be used before the action is specified.

Delivering versus Non-Delivering Recipes

The action used if the recipe matches a particular message determines whether the recipe is considered delivering or non-delivering. A delivering recipe contains an action that writes the message to a file, sends the message to another program, or forwards the message to another email address. A non-delivering recipe covers any other actions, such as when a nesting block is used. A nesting block is an action contained in braces ({ }) that designates additional actions to perform on messages that match the recipe’s conditions. Nesting blocks can be nested, providing greater control for identifying and performing actions on messages.

Delivering recipes that match messages causes Procmail to perform the action specified and stop comparing the message against any other recipes. Messages that match conditions in non-delivering recipes will continue to be compared against other recipes in the current and following rc files. In other words, non-delivering recipes cause the message to continue through the recipes after the specified action is taken on it.

Flags

Flags are very important in determining how or if a recipe’s conditions are compared against a message. The following flags are commonly used:

  • A — Specifies that this recipe will be used only if the last previous recipe without an A or a flag also matched this message. To ensure that the action on this last previous matching recipe was successfully completed before allowing a match on the current recipe, use the a flag instead.

  • B — Parses the body of the message and looks for matching conditions.

  • b — Uses the body in any resulting action, such as writing the message to a file or forwarding it. This is the default behavior.

  • c — Generates a carbon copy of the email. This is useful with delivering recipes, since the required action can be performed on the message and a copy of the message can continue being processed in the rc files.

  • D — Makes the egrep comparison case-sensitive. By default, the comparison process is not case-sensitive.

  • E — Similar to the A flag, except that the conditions in this recipe are compared against the message only if the immediately preceding recipe without an E flag did not match. This is comparable to an else action. Use the e flag instead if you want this recipe checked only if the preceding recipe matched but the action failed.

  • f — Uses the pipe as a filter.

  • H — Parses the header of the message and looks for matching conditions. This occurs by default.

  • h — Uses the header in a resulting action. This is the default behavior.

  • w — Tells Procmail to wait for the specified filter or program to finish and report whether or not it was successful before considering the message filtered. If you would like to ignore “Program failure” messages when deciding whether a filter or action succeeded, use the W option instead.

Additional flags can be found in the procmailrc man page.

Specifying a Local Lockfile

Lockfiles are very useful with Procmail to ensure that more than one process does not try to alter a certain message at the same time. You can specify a local lockfile by placing a colon (:) after any flags on a recipe’s first line. This will create a local lockfile based on the destination file name plus whatever has been set in the LOCKEXT global environment variable. Alternatively, you can specify the name of the local lockfile to be used with this recipe after the colon.

Special Conditions and Actions

Particular characters used before Procmail recipe conditions and actions change the way they are interpreted. The following characters may be used after the * character at the beginning of a recipe’s condition line:

  • ! — Inverts the condition, causing a match to occur only if the condition does not match the message.

  • > — Checks to see if the message is under the specified number of bytes.

  • < — Checks to see if the message is over a particular number of bytes.

The following characters are used to perform special actions:

  • ! — Tells Procmail to forward the message to the specified email addresses.

  • $ — Refers to a variable set earlier in the rc file. This is usually used to set a common mailbox that will be referred to by various recipes.

  • | — The pipe character tells Procmail to start a specific program to deal with this message.

  • { and } — Constructs a nesting block, used to contain additional recipes to apply to matching messages.

If no special character is used at the beginning of the action line, Procmail assumes that the action line is specifying a mailbox to which the message should be written.

Recipe Examples

Procmail is an extremely flexible program, allowing you to match messages with very specific conditions and then perform detailed actions on them. As a result of this flexibility, however, composing a Procmail recipe from scratch to achieve a certain goal can be difficult for new users. The best way to develop the skills to build Procmail recipe conditions is based on a strong understanding of regular expressions combined with a review of many examples built by others. The following very basic examples illustrate the structure of Procmail recipes and can provide the foundation for more intricate constructions. The most basic recipes does not even contain conditions, as is illustrated in the following example:

:0:
new-mail.spool

The first line starts the recipe by specifying that a local lockfile is to be created but does not specify a name, leaving Procmail to use the destination file name and the LOCKEXT global environment variable to name it. No condition is specified, so every message will match this recipe and, therefore, will be placed in the single spool file called new-mail.spool, located within the directory specified by the MAILDIR environment variable. An MUA can then view the messages in this file.

This basic recipe could go at the end of all rc files to direct messages to a default location. A more complicated example might grab messages from a particular email address and throw them away, as can be seen in this example:

:0
* ^From: spammer@domain.com
/dev/null

With this example, any messages sent by spammer@domain.com are immediately moved to /dev/null, deleting them.

Warning

Be very careful that a rule is working correctly before moving messages matching it to /dev/null, which is a permanent deletion. If your recipe conditions inadvertently catch unintended messages, you will not even know you are missing those messages unless the sender tells you. A better solution is to point the recipe’s action to a special mailbox that you can check from time to time in order to look for false positives, or messages that inadvertently matched the conditions. Once you are satisfied that no messages are accidentally being matched, you can delete the mailbox and direct the action to henceforward send the messages to /dev/null.

Procmail is primarily used as a filter for email, automatically placing it in the right place so that you do not have to sort it manually. The following recipe grabs email sent from a particular mailing list and puts in the correct folder for you.

:0:
* ^(From|CC|To).*tux-lug
tuxlug

Any messages sent from the tux-lug@domain.com mailing list will be placed in the tuxlug mailbox automatically for your MUA. Note that the condition in this example will match the message if it has the mailing list’s email address on the From:, cc:, or To: lines. Procmail can also be used to block spam, although this is not a good long-term solution for junk mail. The following example illustrates a temporary spam filtering solution, wherein multiple recipes are set to use a common mailbox to store the junk.

SPAM=junk

:0:
* To??^$
$SPAM

:0:
* ^(To|CC):.*,.*,.*,.*,.*,.*,.*,.*,.*,.*,.*,
$SPAM

:0:
* ^Message-Id:.* [^@]*
$SPAM

In this example, the junk mailbox is associated with the SPAM variable, so that you can define a different mailbox to hold your spam in one place. Then, three recipes look for messages to send to the junk mailbox.

The first recipe looks for messages that have no recipient in the To: line. The second recipe matches any messages with 12 or more recipients. The third recipe looks for messages with a bad message ID. These simple examples are provided to help get you started creating recipes. Consult the many Procmail online resources available in the “Additional Resources” section at the end of this chapter to see more detailed and powerful recipes.


Security

Like any other service that flows over a network unencrypted, important email information, such as usernames, passwords, and entire messages, may be intercepted and viewed, all without the knowledge of the email server or client. When using standard POP and IMAP protocols, all authentication information is sent “in the clear,” meaning that someone on a network between the client and the remote server can easily view it.

Secure Email Clients

Thankfully, most Linux MUAs designed to check email on remote servers support SSL to encrypt messages as they are sent back and forth over the network. In order to use SSL when retrieving email, it must be enabled on the email client and server. SSL is easy to enable on the client side, often being done with the click of a button in the MUA’s configuration area. Secure IMAP and POP have known port numbers (993 and 995, respectively) that the MUA will use to authenticate and download messages. Popular MUAs included with Red Hat Linux, such as Mozilla Mail, mutt, and pine, offer SSL-encrypted email sessions.

Secure Email Servers

Offering SSL encryption to IMAP and POP users on the email server is almost as easy. Red Hat Linux also includes the stunnel package, which is an SSL encryption wrapper that wraps around standard, nonsecure network traffic for certain services and prevents interceptors from being able to “sniff” the communication between client and server. The stunnel program uses external SSL libraries, such as the OpenSSL libraries included with Red Hat Linux, to provide strong cryptography and protect your connections. You can apply to a Certificate Authority (CA) for an SSL certificate, or you can create a self-signed certificate to provide the benefit of the SSL-encrypted communication.

To create a self-signed SSL certificate, change to the /usr/share/ssl/certs/ directory, type the make stunnel.pem command, and answer the questions presented to you. Then, use stunnel to start the mail daemon you wish to use. For example, the following command could be used to start the IMAP server included with Red Hat Linux:

/usr/sbin/stunnel -d 993 -l /usr/sbin/imapd imapd

You should now be able to open an IMAP email client and connect to your email server using SSL encryption. Of course, you will probably want to go a step further and configure your stunnel-wrapped IMAP server to automatically start up at the correct runlevels. For more information about how to use stunnel, read the stunnel man page or refer to the documents in the /usr/share/doc/stunnel-version-number directory.

Alternatively, you can use the imap package bundled with Red Hat Linux, which can provide SSL encryption on its own without stunnel. For secure IMAP connections, create the SSL certificate by changing to the /usr/share/ssl/certs/ directory and running the make imapd.pem command. Then, set the imapd service to start at the proper runlevels. You can also use the ipop3 package bundled with Red Hat Linux to provide SSL encryption on its own without stunnel.


Additional Resources

Many users initially find email programs difficult to configure, primarily because of the large number of options available. Following is a list of additional documentation to help you properly configure your mail applications.

Installed Documentation

  • Information about how to configure Sendmail is included with the sendmail and sendmail-cf packages.

  • /usr/share/doc/sendmail/README.cf — Contains information on m4, file locations for Sendmail, supported mailers, how to access enhanced features, and more.

  • /usr/share/doc/sendmail/README — Contains information on the Sendmail directory structure, IDENT protocol support, details on directory permissions, and the common problems these permissions can cause if misconfigured. In addition, the sendmail and aliases man pages contain helpful information covering various Sendmail options and the proper configuration of the Sendmail /etc/mail/aliases file, respectively.

  • /usr/share/doc/fetchmail-version-number — Contains a full list of Fetchmail features in the FEATURES file and an introductory FAQ document.

  • /usr/share/doc/procmail-version-number — Contains a README file that provides an overview of Procmail, a FEATURES file that explores every program feature, and a FAQ file with answers to many common configuration questions.

When learning how Procmail works and creating new recipes, the following Procmail man pages are invaluable:

  • procmail — Provides an overview of how Procmail works and the steps involved in filtering email.

  • procmailrc — Explains the rc file format used to construct recipes.

  • procmailex — Gives a number of useful, real-world examples of Procmail recipes.

  • procmailsc — Explains the weighted scoring technique used by Procmail to see if a particular recipe matches a certain message.

Useful Websites

  • http://www.redhat.com/mirrors/LDP/HOWTO/Mail-Administrator-HOWTO.html — Provides an overview of how email works and examines possible email solutions and configurations on the client and server sides.

  • http://www.redhat.com/mirrors/LDP/HOWTO/Mail-User-HOWTO — Looks at email from the user’s perspective, investigates various popular email client applications, and provides an introduction to topics such as aliases, forwarding, auto-replying, mailing lists, mail filters, and spam.

  • http://www.redhat.com/mirrors/LDP/HOWTO/mini/Secure-POP+SSH.html — Demonstrates a way to retrieve POP email using SSH with port forwarding, so that your email passwords and messages are transferred securely.

  • http://www.sendmail.net — Contains news, interviews, and articles concerning Sendmail, including an expanded view of the many options available.

  • http://www.sendmail.org — Offers a thorough technical breakdown of Sendmail features and configuration examples.

  • http://tuxedo.org/~esr/fetchmail — The home page for Fetchmail, featuring an online manual and a thorough FAQ.

  • http://www.procmail.org — The home page for Procmail, with links to assorted mailing lists dedicated to Procmail as well as various FAQ documents.

  • http://www.ling.helsinki.fi/users/reriksso/procmail/mini-faq.html — An excellent Procmail FAQ, with troubleshooting tips and details about file locking and the use of wildcard characters.

  • http://www.uwasa.fi/~ts/info/proctips.html — Provides dozens of tips that make using Procmail in various situations much easier, including how to test .procmailrc files and use Procmail scoring to decide if a particular action should be taken.

Related Books

  • Sendmail by Bryan Costales with Eric Allman et al (O’Reilly & Associates) — A good Sendmail reference written with the assistance of the original creator of Delivermail and Sendmail.

  • Removing the Spam: E-mail Processing and Filtering by Geoff Mulligan (Addison-Wesley) — Looks at various methods used by email administrators that use established tools, such as Sendmail and Procmail, to manage spam problems.

  • Internet E-mail Protocols: A Developer’s Guide by Kevin Johnson (Addison-Wesley) — Provides a very thorough review of major email protocols and the security they provide.

  • Managing IMAP by Dianna Mullet and Kevin Mullet (O’Reilly & Associates) — Details the steps required to configure an IMAP server.


Chapter 19: Apache HTTP Server Configuration

As most Linux administrators are probably aware, the Apache HTTP server is the most popular World Wide Web server in the world. As with previous versions, Red Hat Linux 8.0 ships with Apache preconfigured and ready to install. Red Hat Linux 8.0 also includes the HTTP Configuration Tool, a graphical utility for configuring Apache to suit the needs of a particular site, as well as various packages — including mod_ssl — designed to create a secure website.

This chapter discusses the use of the HTTP Configuration Tool to customize your Apache installation, as well as the configuration of a secure Web server using mod_ssl. This chapter is not intended to be an exhaustive treatise on the subject of Apache configuration but rather assumes that you have a basic understanding of Apache and are familiar with the needs of your particular site. For more information on Apache and Web security, see the “Additional Resources” section at the end of this chapter.

New in Red Hat Linux 8.0

The Apache HTTP server has been updated to version 2.0, and the package has been renamed httpd. The configuration options have changed. If you want to migrate an existing configuration manually, refer to the migration guide at /usr/share/doc/httpd-ver/migration.html.

If you configured the Apache HTTP server with the HTTP Configuration Tool in previous versions of Red Hat Linux and then performed an upgrade, you can use the application to migrate the configuration file to the new format for version 2.0. Start the HTTP Configuration Tool, make any changes to the configuration, and save it. The configuration file saved will be compatible with version 2.0. The HTTP Configuration Tool allows you to configure the /etc/httpd/conf/httpd.conf configuration file for the Apache HTTP server. It does not use the old srm.conf or access.conf configuration files; leave them empty. Through the graphical interface, you can configure directives such as virtual hosts, logging attributes, and maximum number of connections.

Only modules that are shipped with Red Hat Linux can be configured with the HTTP Configuration Tool. If additional modules are installed, they cannot be configured using this tool. The HTTP Configuration Tool requires the X Window System and root access. To start the application, type redhat-config-httpd at a shell prompt (for example, in an XTerm window or GNOME terminal window).

Warning

Do not edit the /etc/httpd/conf/httpd.conf configuration file manually if you wish to use this tool. The HTTP Configuration Tool generates this file after you save your changes and exit the program. If you want to add additional modules or configuration options that are not available in the HTTP Configuration Tool, you cannot use the HTTP Configuration Tool.

The general steps for configuring the Apache HTTP server using the HTTP Configuration Tool are as following:

  1. Configure the basic settings under the Main tab.

  2. Click on the Virtual Hosts tab and configure the default settings.

  3. Under the Virtual Hosts tab, configure the Default Virtual Host.

  4. If you want to serve more than one URL or virtual host, add the additional virtual hosts.

  5. Configure the server settings under the Server tab.

  6. Configure the connections settings under the Performance Tuning tab.

  7. Copy all necessary files to the DocumentRoot and cgi-bin directories and save your settings in the HTTP Configuration Tool.


Basic Settings

Use the Main tab to configure the basic server settings.

Click To expand
Figure 19-1: Basic settings

In the Server Name text area, enter a fully qualified domain name that you have the right to use. This option corresponds to the ServerName directive in httpd.conf. The ServerName directive sets the hostname of the Web server. It is used when creating redirection URLs. If you do not define a server name, the Web server attempts to resolve it from the IP address of the system. The server name does not have to be the domain name resolved from the IP address of the server. For example, you might want to set the server name to www.your_domain.com when your server’s real DNS name is actually foo.your_domain.com.

Enter the email address of the person who maintains the Web server in the Webmaster email address text area. This option corresponds to the ServerAdmin directive in httpd.conf. If you configure the server’s error pages to contain an email address, this email address will be used so that users can report problems by sending email to the server’s administrator. The default value is root@localhost.

Use the Available Addresses area to define the ports on which the server will accept incoming requests. This option corresponds to the Listen directive in httpd.conf. By default, Red Hat configures the Apache HTTP server to listen to port 80 for nonsecure Web communications. Click the Add button to define additional ports on which to accept requests. A window as shown in Figure 19-2 will appear. Either choose the Listen to all addresses option to listen to all IP addresses on the defined port or specify in the Address field a particular IP address over which the server will accept connections.

Specify only one IP address per port number. If you want to specify more than one IP address with the same port number, create an entry for each IP address. If at all possible, use an IP address instead of a domain name to prevent a DNS lookup failure. Refer to http://httpd.apache.org/docs-2.0/dns-caveats.html for more information about issues regarding DNS and Apache.

Entering an asterisk (*) in the Address field is the same as choosing Listen to all addresses. Clicking the Edit button shows the same window as the Add button except with the fields populated for the selected entry. To delete an entry, select it and click the Delete button.

Figure 19-2: Available addresses
Tip

If you set the server to listen to a port under 1024, you must be root to start it. For port 1024 and above, httpd can be started as a regular user.


Default Settings

After defining the Server Name, Webmaster email address, and Available Addresses, click the Virtual Hosts tab and click the Edit Default Settings button. The window shown in Figure 19-3 will appear. Configure the default settings for your Web server in this window. If you add a virtual host, the settings you configure for the virtual host take precedence for that virtual host. For a directive not defined within the virtual host settings, the default value is used.

Site Configuration

The default values for the Directory Page Search List and Error Pages will work for most servers. If you are unsure of these settings, do not modify them.

Click To expand
Figure 19-3: Site configuration

The entries listed in the Directory Page Search List define the DirectoryIndex directive. The DirectoryIndex is the default page served by the server when a user requests an index of a directory by specifying a forward slash (/) at the end of the directory name.

For example, users who request the page http://your_domain/this_directory/ are going to get either the DirectoryIndex page if it exists, or a server-generated directory list. The server will try to find one of the files listed in the DirectoryIndex directive and will return the first one it finds. If it does not find any of these files and if OptionsIndexes is set for that directory, the server will generate and return a list, in HTML format, of the subdirectories and files in the directory.

Use the Error Code section to configure Apache HTTP server to redirect the client to a local or external URL if the event of a problem or error. This option corresponds to the ErrorDocument directive. If a problem or error occurs when a client tries to connect to the Apache HTTP server, the default action is to display the short error message shown in the Error Code column. To override this default configuration, select the error code and click the Edit button.

Choose Default to display the default short error message. Choose URL to redirect the client to an external URL and enter a complete URL, including the http://, in the Location field. Choose File to redirect the client to an internal URL and enter a file location under the document root for the Web server. The location must begin with a forward slash (/) and be relative to the Document Root.

For example, to redirect a 404 Not Found error code to a Web page that you created in a file called 404.html, copy 404.html to DocumentRoot/errors/404.html. In this case, DocumentRoot is the Document Root directory that you have defined (the default is /var/www/html). Then, choose File as the Behavior for 404 - Not Found error code and enter /errors/404.html as the Location.

From the Default Error Page Footer menu, you can choose one of the following options:

  • Show footer with email address — Display the default footer at the bottom of all error pages along with the email address of the website maintainer specified by the ServerAdmin directive. Refer to the “General Options” section of this chapter for information about configuring the ServerAdmin directive.

  • Show footer — Display just the default footer at the bottom of error pages.

  • No footer — Do not display a footer at the bottom of error pages.

Logging

By default, the server writes the transfer log to the file /var/log/httpd/access_log and the error log to the file /var/log/httpd/error_log.

The transfer log contains a list of all attempts to access the Web server. It records the IP address of the client that is attempting to connect, the date and time of the attempt, and the file on the Web server that it is trying to retrieve. Enter the name of the path and file in which to store this information. If the path and file name do not start with a slash (/), the path is relative to the server root directory as configured. This option corresponds to the TransferLog directive.

You can configure a custom log format by checking Use custom logging facilities and entering a custom log string in the Custom Log String field. This configures the LogFormat directive. Refer to http://httpd.apache.org/docs-2.0/mod/mod_log_config.html#formats for details on the format of this directive.

Click To expand
Figure 19-4: Logging

The error log contains a list of any server errors that occur. Enter the name of the path and file in which to store this information. If the path and file name do not start with a slash (/), the path is relative to the server root directory as configured. This option corresponds to the ErrorLog directive.

Use the Log Level menu to set how verbose the error messages in the error logs will be. It can be set (from least verbose to most verbose) to emerg, alert, crit, error, warn, notice, info, or debug. This option corresponds to the LogLevel directive.

The value chosen with the Reverse DNS Lookup menu defines the HostnameLookups directive. Choosing No Reverse Lookup sets the value to off. Choosing Reverse Lookup sets the value to on. Choosing Double Reverse Lookup sets the value to double. If you choose Reverse Lookup, your server will automatically resolve the IP address for each connection that requests a document from your Web server. Resolving the IP address means that your server will make one or more connections to the DNS in order to locate the hostname that corresponds to a particular IP address. If you choose Double Reverse Lookup, your server will perform a double-reverse DNS. In other words, after a reverse lookup is performed, a forward lookup is performed on the result. At least one of the IP addresses in the forward lookup must match the address from the first reverse lookup.

Generally, you should leave this option set to No Reverse Lookup, because the DNS requests add a load to your server and may slow it down. If your server is busy, the effects of trying to perform these reverse lookups or double reverse lookups may be quite noticeable. Reverse lookups and double reverse lookups are also an issue for the Internet as a whole. All of the individual connections made to look up each hostname add up. Therefore, for your own Web server’s benefit, as well as for the Internet’s benefit, leave this option set to No Reverse Lookup.

Environment Variables

The Apache HTTP server can use the mod_env module to configure the environment variables that are passed to CGI scripts and SSI pages. Use the Environment Variables page to configure the directives for this module.

Click To expand
Figure 19-5: Environment variables

Use the Set for CGI Scripts section to set an environment variable that is passed to CGI scripts and SSI pages. For example, to set the environment variable MAXNUM to 50, click the Add button inside the Set for CGI Scripts section as shown below and type MAXNUM in the Environment Variable text field and 50 in the Value to set text field. Click OK. The Set for CGI Scripts section configures the SetEnv directive.

Use the Pass to CGI Scripts section to pass the value of an environment variable when the server was first started to CGI scripts. To see this environment variable, type env at a shell prompt. Click the Add button inside the Pass to CGI Scripts section and enter the name of the environment variable in the resulting dialog box. Click OK.

The Pass to CGI Scripts section configures the PassEnv directive. If you want to remove an environment variable so that the value is not passed to CGI scripts and SSI pages, use the Unset for CGI Scripts section. Click Add in the Unset for CGI Scripts section and enter the name of the environment variable to unset. This corresponds to the UnsetEnv directive.

Directories

Use the Directories page to configure options for specific directories. This corresponds to the Directory directive.

Click To expand
Figure 19-6: Directories

Click the Edit button in the top right-hand corner to configure the Default Directory Options for all directories that are not specified in the Directory list below it. The options that you choose are listed as the Options directive within the Directory directive. You can configure the following options:

  • ExecCGI — Allow execution of CGI scripts. CGI scripts are not executed if this option is not chosen.

  • FollowSymLinks — Allow symbolic links to be followed.

  • Includes — Allow server-side includes.

  • IncludesNOEXEC — Allow server-side includes, but disable the #exec and #include commands in CGI scripts.

  • Indexes — Display a formatted list of the directory’s contents, if no DirectoryIndex (such as index.html) exists in the requested directory.

  • Multiview — Support content-negotiated multiviews; this option is disabled by default.

  • SymLinksIfOwnerMatch — Follow symbolic links only if the target file or directory has the same owner as the link.

To specify options for specific directories, click the Add button beside the Directory list box. The window shown in Figure 19-7 appears. Enter the directory to configure in the Directory text field at the bottom of the window. Select the options in the right-hand list, and configure the Order directive with the left-hand-side options. The Order directive controls the order in which allow and deny directives are evaluated. In the Allow hosts from and Deny hosts from text field, you can specify one of the following:

  • Allow all hosts — Type all to allow access to all hosts.

  • Partial domain name — Allow all hosts whose names match or end with the specified string.

  • Full IP address — Allow access to a specific IP address.

  • A subnet — Such as 192.168.1.0/255.255.255.0.

  • A network CIDR specification — such as 10.3.0.0/16.

Click To expand
Figure 19-7: Directory settings

If you check the Let .htaccess files override directory options, the configuration directives in the .htaccess file take precedence.


Virtual Hosts Settings

You can use the HTTP Configuration Tool to configure virtual hosts. Virtual hosts allow you to run different servers for different IP addresses, different hostnames, or different ports on the same machine. For example, you can run the website for http://www.your_domain.com and http://www.your_second_domain.com on the same Web server using virtual hosts. This option corresponds to the VirtualHost directive for the default virtual host and IP-based virtual hosts. It corresponds to the NameVirtualHost directive for a name-based virtual host.

The directives set for a virtual host apply only to that particular virtual host. If a directive is set server-wide using the Edit Default Settings button and not defined within the virtual host settings, the default setting is used. For example, you can define a Webmaster email address in the Main tab and not define individual email addresses for each virtual host. The HTTP Configuration Tool includes a default virtual host (see Figure 19-8).

Click To expand
Figure 19-8: Virtual hosts

http://httpd.apache.org/docs-2.0/vhosts/ and the Apache HTTP server documentation on your machine provide more information about virtual hosts.

Adding and Editing a Virtual Host

To add a virtual host, click the Virtual Hosts tab and then click the Add button. You can also edit a virtual host by selecting it in the list and clicking the Edit button.

General Options

The General Options settings apply only to the virtual host that you are configuring. Set the name of the virtual host in the Virtual Host Name text area. This name is used by the HTTP Configuration Tool to distinguish between virtual hosts.

Set the Document Root Directory value to the directory that contains the root document (such as index.html) for the virtual host. This option corresponds to the DocumentRoot directive within the VirtualHost directive. Before Red Hat Linux 7, the Apache HTTP server provided with Red Hat Linux used /home/httpd/html as the DocumentRoot. In Red Hat Linux 8.0, however, the default DocumentRoot is /var/www/html.

The Webmaster email address corresponds to the ServerAdmin directive within the VirtualHost directive. This email address is used in the footer of error pages if you choose to show a footer with an email address on the error pages.

In the Host Information section, choose Default Virtual Host, IP-based Virtual Host, or Name-based Virtual Host.

You should configure only one default virtual host (remember that there is one setup by default). The default virtual host settings are used when the requested IP address is not explicitly listed in another virtual host. If no default virtual host is defined, the main server settings are used.

If you choose IP-based Virtual Host, a window appears in which you can configure the VirtualHost directive based on the IP address of the server. Specify this IP address in the IP address field. To specify more than one IP address, separate each IP address with spaces. To specify a port, use the syntax IP Address:Port. Use :* to configure all ports for the IP address. Specify the hostname for the virtual host in the Server Host Name field.

If you choose Name-based Virtual Host, a window appears in which you can configure the NameVirtualHost directive based on the host name of the server. Specify the IP address in the IP address field. To specify more than one IP address, separate each IP address with spaces. To specify a port, use the syntax IP Address:Port. Use :* to configure all ports for the IP address. Specify the host name for the virtual host in the Server Host Name field. In the Aliases section, click Add to add a hostname alias. Adding an alias here adds a ServerAlias directive within the NameVirtualHost directive.

SSL

If an Apache HTTP server is not configured with SSL support, communications between an Apache HTTP server and its clients are not encrypted. This is appropriate for websites without personal or confidential information. For example, a website that distributes open-source software and documentation has no need for secure communications. However, an e-commerce website that requires credit card information should use the Apache SSL support to encrypt its communications.

Enabling Apache SSL support enables the use of the mod_ssl security module. To enable it through the HTTP Configuration Tool, you must allow access through port 443 under the Main tab > Available Addresses. Refer to the “Basic Settings” section of this chapter for details. Then, select the virtual host name in the Virtual Hosts tab, click the Edit button, choose SSL from the left-hand menu, and check the Enable SSL Support option as shown in Figure 19-9. The SSL Configuration section is preconfigured with the dummy digital certificate. The digital certificate provides authentication for your secure Web server and identifies the secure server to client Web browsers.

Click To expand
Figure 19-9: SSL support
Note

You cannot use name-based virtual hosts with SSL, because the SSL handshake (when the browser accepts the secure Web server’s certificate) occurs before the HTTP request that identifies the appropriate name-based virtual host. If you want to use name-based virtual hosts, they will work only with your nonsecure Web server.
Note

You must purchase your own digital certificate. Do not use the dummy one provided in Red Hat Linux for your website. For details on purchasing a CA-approved digital certificate, refer to the section “Apache HTTPD Secure Service Configuration.”

Additional Virtual Host Options

The Site Configuration, Environment Variables, and Directories options for the virtual hosts are the same directives that you set when you clicked the Edit Default Settings button, except the options set here are for the individual virtual hosts that you are configuring. Refer to the “Default Settings” section of this chapter for details on these options.


Server Settings

The Server tab allows you to configure basic server settings. The default settings for these options are appropriate for most situations.

The Lock File value corresponds to the LockFile directive. This directive sets the path to the lockfile used when the server is compiled with either USE_FCNTL_SERIALIZED_ACCEPT or USE_FLOCK_SERIALIZED_ACCEPT. It must be stored on the local disk. It should be left to the default value unless the logs directory is located on an NFS share. If this is the case, the default value should be changed to a location on the local disk and to a directory that is readable only by root.

The PID File value corresponds to the PidFile directive. This directive sets the file in which the server records its process ID (pid). This file should be readable by root only. In most cases, it should be left to the default value.

The Core Dump Directory value corresponds to the CoreDumpDirectory directive. The Apache HTTP server tries to switch to this directory before dumping core. The default value is Server-Root. However, if the user that the server runs as cannot write to this directory, the core dump cannot be written. Change this value to a directory writable by the user the server runs as, if you want to write the core dumps to disk for debugging purposes.

Click To expand
Figure 19-10: Server configuration

The User value corresponds to the User directive. It sets the userid used by the server to answer requests. This user’s settings determine the server’s access. Any files inaccessible to this user will also be inaccessible to your website’s visitors. The default for User is apache. The user should have privileges only so that it can access files that are supposed to be visible to the outside world. The user is also the owner of any CGI processes spawned by the server. The user should not be allowed to execute any code that is not intended to be in response to HTTP requests.

Warning

Unless you know exactly what you are doing, do not set the User directive to root. Using root as the User will create large security holes for your Web server.

The parent httpd process first runs as root during normal operations, but it is then immediately handed off to the Apache user. The server must start as root because it needs to bind to a port below 1024. Ports below 1024 are reserved for system use, so they cannot be used by anyone but root. Once the server has attached itself to its port, however, it hands the process off to the Apache user before it accepts any connection requests.

The Group value corresponds to the Group directive. The Group directive is similar to the User directive. Group sets the group under which the server will answer requests. The default group is also apache.


Performance Tuning

Click on the Performance Tuning tab to configure the maximum number of child server processes you want and to configure the Apache HTTP server options for client connections. The default settings for these options are appropriate for most situations. Altering these settings may affect the overall performance of your Web server.

Click To expand
Figure 19-11: Performance tuning

Set Max Number of Connections to the maximum number of simultaneous client requests that the server will handle. For each connection, a child httpd process is created. After this maximum number of processes is reached, no one else will be able to connect to the Web server until a child server process is freed. You cannot set this value to higher than 256 without recompiling. This option corresponds to the MaxClients directive.

Connection Timeout defines, in seconds, the amount of time that your server will wait for receipts and transmissions during communications. Specifically, Connection Timeout defines how long your server will wait to receive a GET request, how long it will wait to receive TCP packets on a POST or PUT request, and how long it will wait between ACKs responding to TCP packets. By default, Connection Timeout is set to 300 seconds, which is appropriate for most situations. This option corresponds to the TimeOut directive.

Set the Max requests per connection to the maximum number of requests allowed per persistent connection. The default value is 100, which should be appropriate for most situations. This option corresponds to the MaxRequestsPerChild directive. If you check the Allow unlimited requests per connection option, the MaxKeepAliveRequests directive is set to 0, and unlimited requests are allowed. If you uncheck the Allow Persistent Connections option, the KeepAlive directive is set to false. If you check it, the KeepAlive directive is set to true, and the KeepAliveTimeout directive is set to the number that is selected as the Timeout for next Connection value. This directive sets the number of seconds your server will wait for a subsequent request, after a request has been served, before it closes the connection. Once a request has been received, the Connection Timeout value applies instead.

Note

Setting the Persistent Connections to a high value may cause a server to slow down, depending on how many users are trying to connect to it. The higher the number, the more server processes waiting for another connection from the last client that connected to it.


Saving Your Settings

If you do not want to save your Apache HTTP server configuration settings, click the Cancel button in the bottom right corner of the HTTP Configuration Tool window. You will be prompted to confirm this decision. If you click Yes to confirm this choice, your settings will not be saved.

If you do want to save your Apache HTTP server configuration settings, click the OK button in the bottom right corner of the HTTP Configuration Tool window. A dialog box will appear. If you answer Yes, your settings will be saved in /etc/httpd/conf/httpd.conf. Remember that your original configuration file will be overwritten.

If this is the first time that you have used the HTTP Configuration Tool, you will see a dialog box warning you that the configuration file has been manually modified. If the HTTP Configuration Tool detects that the httpd.conf configuration file has been manually modified, it will save the manually modified file as /etc/httpd/conf/httpd.conf.bak.

Note

After saving your settings, you must restart the httpd daemon with the command service httpd restart. You must be logged in as root to execute this command.


Apache HTTP Secure Server Configuration

This section provides basic information on the Apache HTTP server with the mod_ssl security module enabled to use the OpenSSL library and toolkit. The combination of these three components, provided with Red Hat Linux, will be referred to in this chapter as the secure Web server or just the secure server.

The mod_ssl module is a security module for the Apache HTTP server. The mod_ssl module uses the tools provided by the OpenSSL Project to add a very important feature to the Apache HTTP server — the ability to encrypt communications. In contrast, using regular HTTP, communications between a browser and a Web server are sent in plaintext, which could be intercepted and read by someone along the route between the browser and the server.

This section is not meant to be complete and exclusive documentation for any of these programs. When possible, we’ll point you to appropriate places where you can find more in-depth documentation on particular subjects. This section will show you how to install these programs. You will also learn the steps necessary to generate a private key and a certificate request, how to generate your own self-signed certificate, and how to install a certificate to use with your secure Web server.

The configuration for mod_ssl has moved from /etc/httpd/conf/httpd.conf to /etc/httpd/conf.d/ssl.conf. For this file to be loaded, and hence for mod_ssl to work, you must have the statement Include conf.d/*.conf in /etc/httpd/conf/httpd.conf.

An Overview of Security-Related Packages

To enable the secure server, you need to have the following packages installed at a minimum.

httpd

The httpd package contains the httpd daemon and related utilities, configuration files, icons, Apache HTTP server modules, man pages, and other files used by the Apache HTTP server.

mod_ssl

The mod_ssl package includes the mod_ssl module, which provides strong cryptography for the Apache HTTP server via the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols.

openssl

The openssl package contains the OpenSSL toolkit. The OpenSSL toolkit implements the SSL and TLS protocols and also includes a general-purpose cryptography library.

Additionally, the following software packages included with Red Hat Linux can provide certain security functionalities (but are not required by the secure server to function).

httpd-devel

The httpd-devel package contains the Apache HTTP server include files, header files, and the APXS utility. You will need all of these if you intend to load any extra modules, other than the modules provided with this product. If you do not intend to load other modules onto your Apache server, you do not need to install this package.

httpd-manual

The httpd-manual package contains the Apache Project’s Apache User’s Guide in HTML format. This manual is also available on the Web at http://httpd.apache.org/docs-2.0/.

OpenSSH packages

The OpenSSH packages provide the OpenSSH set of network connectivity tools for logging in to and executing commands on a remote machine. OpenSSH tools encrypt all traffic (including passwords), so you can avoid eavesdropping, connection hijacking, and other attacks on communications between your machine and the remote machine.

  • The openssh package includes core files needed by both the OpenSSH client programs and the OpenSSH server. The openssh package also contains scp, a secure replacement for rcp (for copying files between machines), and ftp (for transferring files between machines).

  • The openssh-askpass package supports the display of a dialog box that prompts for a password during use of the OpenSSH agent with RSA authentication.

  • The openssh-askpass-gnome package contains a GNOME GUI desktop environment dialog box that is displayed when OpenSSH programs prompt for a password. If you are running GNOME and using OpenSSH utilities, you should install this package.

  • The openssh-server package contains the sshd secure shell daemon and related files. The secure shell daemon is the server side of the OpenSSH suite and must be installed on your host if you want to allow SSH clients to connect to your host.

  • The openssh-clients package contains the client programs needed to make encrypted connections to SSH servers, including the following: ssh, a secure replacement for rsh; and slogin, a secure replacement for rlogin (for remote login) and telnet (for communicating with another host via the Telnet protocol).

    Tip

    For more information about OpenSSH, see the OpenSSH website, http://www.openssh.com.

openssl-devel

The openssl-devel package contains the static libraries and the include file needed to compile applications with support for various cryptographic algorithms and protocols. You need to install this package only if you are developing applications that include SSL support — you do not need this package to use SSL.

stunnel

The stunnel package provides the Stunnel SSL wrapper. Stunnel supports the SSL encryption of TCP connections, so it can provide encryption for non–SSL aware daemons and protocols (such as POP, IMAP, and LDAP) without requiring any changes to the daemon’s code.

Table 19-1 displays the location of the secure server packages and additional security-related packages within the package groups provided by Red Hat Linux. This table also tells you whether each package is optional or not for the installation of a secure Web server.

Table 19-1: Security packages
Package name | Located in group | Optional?
Httpd | System Environment/Daemons | no
mod_ssl | System Environment/Daemons | no
Openssl | System Environment/Libraries | no
httpd-devel | Development/Libraries | yes
httpd-manual | Documentation | yes
Openssh | Applications/Internet | yes
openssh-askpass | Applications/Internet | yes
openssh-askpass-gnome | Applications/Internet | yes
openssh-clients | Applications/Internet | yes
openssh-server | System Environment/Daemons | yes
openssl-devel | Development/Libraries | yes
stunnel | Applications/Internet | yes

An Overview of Certificates and Security

Your secure Web server provides security using a combination of the Secure Sockets Layer (SSL) protocol and (in most cases) a digital certificate from a Certificate Authority (CA). SSL handles the encrypted communications and the mutual authentication between browsers and your secure Web server. The CA-approved digital certificate provides authentication for your secure Web server (the CA puts its reputation behind its certification of your organization’s identity). When your browser is communicating using SSL encryption, you will see the https:// prefix at the beginning of the Uniform Resource Locator (URL) in the navigation bar.

Encryption depends upon the use of keys (think of them as secret encoder/decoder rings in data format). In conventional or symmetric cryptography, both ends of the transaction have the same key, which they use to decode each other’s transmissions. In public or asymmetric cryptography, two keys coexist: a public key and a private key. A person or an organization keeps their private key a secret, and publishes their public key. Data encoded with the public key can be decoded only with the private key; data encoded with the private key can be decoded only with the public key.

To set up your secure server, you will use public cryptography to create a public and private key pair. In most cases, you will send your certificate request (including your public key), proof of your company’s identity, and payment to the CA. The CA will verify the certificate request and your identity and then send back a certificate for your secure Web server.

A secure server uses a certificate to identify itself to Web browsers. You can generate your own certificate (called a “self-signed” certificate) or you can get a certificate from a Certificate Authority or CA. A certificate from a reputable CA guarantees that a website is associated with a particular company or organization. Alternatively, you can create your own self-signed certificate. Note, however, that self-signed certificates should not be used in most production environments. Self-signed certificates will not be automatically accepted by a user’s browser — the user will be asked by the browser if he or she wants to accept the certificate and create the secure connection. See the “Types of Certificates” section of this chapter for more information on the differences between self-signed and CA-signed certificates. Once you have a self-signed certificate or a signed certificate from the CA of your choice, you will need to install it on your secure Web server.


Using Pre-Existing Keys and Certificates

If you already have an existing key and certificate (for example, if you are installing the secure Web server to replace another company’s secure Web server product), you will probably be able to use your existing key and certificate with the secure Web server. In the following two situations, you will not be able to use your existing key and certificate:

  • If you are changing your IP address or domain name. You cannot use your old key and certificate if you are changing your IP address or domain name. Certificates are issued for a particular IP address and domain name pair. You will need to get a new certificate if you are changing your IP address or domain name.

  • If you have a certificate from VeriSign and you are changing your server software. VeriSign is a widely used CA. If you already have a VeriSign certificate for another purpose, you may have considered using your existing VeriSign certificate with your new secure Web server. However, you will not be allowed to, because VeriSign issues certificates for one particular server software and IP address/domain name combination. If you change either of those parameters (for example, if you previously used another secure Web server product and now you want to use the secure Web server), the VeriSign certificate you obtained to use with the previous configuration will not work with the new configuration. You will need to obtain a new certificate.

If you have an existing key and certificate that you can use, you will not have to generate a new key and obtain a new certificate. However, you may need to move and rename the files that contain your key and certificate. Move your existing key file to:

/etc/httpd/conf/ssl.key/server.key

Move your existing certificate file to:

/etc/httpd/conf/ssl.crt/server.crt

After you have moved your key and certificate, skip to the section “Testing Your Certificate.”

If you are upgrading from the Red Hat Secure Web Server versions 1.0 and 2.0, your old key (httpsd.key) and certificate (httpsd.crt) will be located in /etc/httpd/conf/. You will need to move and rename your key and certificate so that the secure Web server can use them. Use the following two commands to move and rename your key and certificate files:

mv /etc/httpd/conf/httpsd.key /etc/httpd/conf/ssl.key/server.key
mv /etc/httpd/conf/httpsd.crt /etc/httpd/conf/ssl.crt/server.crt

Then start your secure Web server with the command

/sbin/service httpd start

For a secure server, you will be prompted to enter your password. After you type it and press Enter, the server will start. You should not need to get a new certificate, if you are upgrading from a previous version of the secure Web server.


Types of Certificates

If you installed your secure Web server using the Red Hat Linux installation program, a random key and a test certificate were generated and put into the appropriate directories. Before you begin using your secure server, however, you will need to generate your own key and obtain a certificate that correctly identifies your server.

You need a key and a certificate to operate your secure Web server — which means that you can either generate a self-signed certificate or purchase a CA-signed certificate from a CA. What are the differences between the two? A CA-signed certificate provides two important capabilities for your server:

  • Browsers will (usually) automatically recognize the certificate and allow a secure connection to be made, without prompting the user.

  • When a CA issues a signed certificate, it is guaranteeing the identity of the organization that is providing the Web pages to the browser.

If your secure server is being accessed by the public at large, your secure Web server needs a certificate signed by a CA, so that people who visit your website know that the website is owned by the organization that claims to own it. Before signing a certificate, a CA verifies that the organization requesting the certificate was actually what it claimed to be. Most Web browsers that support SSL have a list of CAs whose certificates they will automatically accept. If a browser encounters a certificate whose authorizing CA is not in the list, the browser will ask the user to choose whether to accept or decline the connection.

You can generate a self-signed certificate for your secure Web server, but be aware that a self-signed certificate will not provide the same functionality as a CA-signed certificate. A self-signed certificate will not be automatically recognized by users’ browsers, and a self-signed certificate does not provide any guarantee concerning the identity of the organization that is providing the website. A CA-signed certificate provides both of these important capabilities for a secure server. If your secure server will be used in a production environment, you will probably need a CA-signed certificate.

The process of getting a certificate from a CA is fairly easy. A quick overview is as follows:

  1. Create an encrypted private and public key pair.

  2. Create a certificate request based on the public key. The certificate request contains information about your server and the company hosting it.

  3. Send the certificate request, along with documents specified by the CA that prove your identity, to a CA. We cannot tell you which certificate authority to choose. Your decision may be based on your experiences, or on the experiences of your friends or colleagues, or purely on monetary factors. To see a list of CAs, click on the Security button on your Web browser toolbar or on the padlock icon at the bottom left of the screen, then click on Signers to see a list of certificate signers from which your browser will accept certificates. You can also search the Web for CAs. Once you have decided upon a CA, you will need to follow the instructions it provides on how to obtain a certificate.

  4. When the CA is satisfied that your organization is indeed what it claims to be, it sends you a digital certificate.

  5. Install this certificate on your Web server and begin handling secure transactions.

Whether you are getting a certificate from a CA or generating your own self-signed certificate, the first step is to generate a key. See the section “Generating a Key” for instructions on how to generate a key.


Generating a Key

You must be root to generate a key. First, cd to the /etc/httpd/conf directory. Remove the fake key and certificate that were generated during the installation with the following commands:

rm ssl.key/server.key
rm ssl.crt/server.crt

Next, you need to create your own random key. Change to the /usr/share/ssl/certs directory and type the following command:

make genkey

Your system will display a message similar to the following:

umask 77 ; \
/usr/bin/openssl genrsa -des3 1024 > /etc/httpd/conf/ssl.key/server.key
Generating RSA private key, 1024 bit long modulus
.......++++++
................................................++++++e is 65537 (0x10001)
Enter PEM pass phrase:

You now need to enter a password. For best security, your password should contain at least eight characters, include numbers and/or punctuation, and not be a word found in a common dictionary. Also, remember that your password is case-sensitive.

Note

You will need to remember and enter this password every time you start your secure Web server, so do not forget it.

You will be asked to retype the password, to verify that it is correct. Once you have done so, /etc/httpd/conf/ssl.key/server.key, containing your key, will be created.

Note that if you do not want to enter a password every time you start your secure Web server, you will need to use the following two commands instead of make genkey to create the key. Use this command

/usr/bin/openssl genrsa 1024 > /etc/httpd/conf/ssl.key/server.key

to create your key. Then use the command

chmod go-rwx /etc/httpd/conf/ssl.key/server.key

to make sure that the permissions are set correctly on your key. After you use the above commands to create your key, you will not need to use a password to start your secure Web server.

Warning

Disabling the password feature for your secure Web server is a security risk. It is not recommended that you disable the password feature for your secure Web server.

The problems associated with not using a password are directly related to the security maintained on the host machine. For example, an unscrupulous individual who compromises the regular UNIX security on the host machine could obtain your private key (the contents of your server.key file). The key could be used to serve Web pages that will appear to be from your Web server.

If UNIX security practices are rigorously maintained on the host computer (all operating system patches and updates are installed as soon as they are available, no unnecessary or risky services are operating, and so on), the secure Web server’s password may seem unnecessary. However, since your secure Web server should not need to be rebooted very often, the extra security provided by entering a password is a worthwhile effort in most cases.

The server.key file should be owned by the root user on your system and should not be accessible to any other user. Make a backup copy of this file and keep the backup copy in a safe, secure place. You need the backup copy because if you ever lose the server.key file after using it to create your certificate request, your certificate will no longer work and the CA will not be able to help you. Your only option will be to request (and pay for) a new certificate.

If you are going to purchase a certificate from a CA, continue to the next section. If you are generating your own self-signed certificate, continue to the section “Creating a Self-Signed Certificate.”


Generating a Certificate Request to Send to a CA

Once you have created a key, the next step is to generate a certificate request that you will need to send to the CA of your choice. Make sure you are in the /usr/share/ssl/certs directory and type the following command:

make certreq

Your system will display the following output and will ask you for your password (unless you disabled the password option):

umask 77 ; \
/usr/bin/openssl req -new -key /etc/httpd/conf/ssl.key/server.key
-out /etc/httpd/conf/ssl.csr/server.csr
Using configuration from /usr/share/ssl/openssl.cnf
Enter PEM pass phrase:

Type the password that you chose when you were generating your key. Your system will display some instructions and then ask for a series of responses from you. Your inputs will be incorporated into the certificate request. The display, with example responses, will look like this:

You are about to be asked to enter information that will be incorporated into your certificate
request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few
fields but you can leave some blank.
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:North Carolina
Locality Name (eg, city) [Newbury]:Raleigh
Organization Name (eg, company) [My Company Ltd]:Test Company
Organizational Unit Name (eg, section) []:Testing
Common Name (your name or server's hostname) []:test.example.com
Email Address []:admin@example.com
Please enter the following 'extra' attributes to be sent with your certificate request
A challenge password []:
An optional company name []:

The default answers appear in brackets immediately after each request for input. For example, the first information required is the name of the country where the certificate will be used, shown like the following:

Country Name (2 letter code) [GB]:

The default input, in brackets, is GB. To accept the default, press Enter or fill in your country’s two-letter code. You will have to enter the rest of the inputs (State or Province Name, Locality Name, Organization Name, Organizational Unit Name, Common Name, and Email address). All of these should be self-explanatory, but you need to follow these guidelines:

  • Do not abbreviate the locality or state. Write them out (for example, St. Louis should be written out as Saint Louis).

  • If you are sending this CSR to a CA, be very careful to provide correct information for all of the fields, but especially for the Organization Name and the Common Name. CAs check the information provided in the CSR to determine whether your organization is responsible for what you provided as the Common Name. CAs will reject CSRs that include information perceived as invalid.

  • For Common Name, make sure you enter the real name of your secure Web server (a valid DNS name) and not any aliases the server may have.

  • The Email Address should be the email address for the Webmaster or system administrator.

  • Avoid any special characters like @, #, &, !, and the like. Some CAs will reject a certificate request that contains a special character. So, if your company name includes an ampersand (&), spell it out as and instead of &.

  • Do not use either of the extra attributes (A challenge password and An optional company name). To continue without entering these fields, just press Enter to accept the blank default for both inputs.

When you have finished entering your information, the file /etc/httpd/conf/ssl.csr/server.csr is created. This file is your certificate request, ready to send to your CA. After you have decided on a CA, follow the instructions provided on its website. The instructions will tell you how to send your certificate request, any other documentation required, and your payment. After you have fulfilled the CA’s requirements, it will send a certificate to you (usually by email). Save (or copy and paste) the certificate they send you as /etc/httpd/conf/ssl.crt/server.crt.


Creating a Self-Signed Certificate

You can create your own self-signed certificate. Note that a self-signed certificate will not provide the security guarantees provided by a CA-signed certificate. See the section “Types of Certificates” for more details about certificates.

If you would like to make your own self-signed certificate, you will first need to create a random key using the instructions provided in the “Generating a Key” section. Once you have a key, make sure you are in the /usr/share/ssl/certs directory and type the following command:

make testcert

You will see the following output and you will be prompted for your password (unless you generated a key without a password):

umask 77 ; \
/usr/bin/openssl req -new -key /etc/httpd/conf/ssl.key/server.key
-x509 -days 365 -out /etc/httpd/conf/ssl.crt/server.crt
Using configuration from /usr/share/ssl/openssl.cnf
Enter PEM pass phrase:

After you enter your password (if you created a key without a password, no prompt will be given), you will be asked for more information. The computer’s output and a set of inputs will look like the following (you will need to provide the correct information for your organization and host):

You are about to be asked to enter information that will be incorporated into your certificate
request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few
fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US
State or Province Name (full name) [Berkshire]:North Carolina
Locality Name (eg, city) [Newbury]:Raleigh
Organization Name (eg, company) [My Company Ltd]:My Company, Inc.
Organizational Unit Name (eg, section) []:Documentation
Common Name (your name or server's hostname) []:myhost.example.com
Email Address []:myemail@example.com

After you provide the correct information, a self-signed certificate will be created in /etc/httpd/conf/ssl.crt/server.crt. You will need to restart your secure server with the following command after generating the certificate:

/sbin/service httpd restart


Testing Your Certificate

When the secure server is installed by the Red Hat Linux installation program, a random key and a generic certificate are installed, for testing purposes. You can connect to your secure server using this certificate. For any purposes other than testing, however, you need to get a certificate from a CA or generate a self-signed certificate. See the “Types of Certificates” section of this chapter if you need more information on the different types of certificates available.

If you have purchased a certificate from a CA or generated a self-signed certificate, you should have a file named /etc/httpd/conf/ssl.key/server.key, containing your key, and a file named /etc/httpd/conf/ssl.crt/server.crt, containing your certificate. If your key and certificate are somewhere else, move them to these directories. If you changed any of the default locations or file names for the secure Web server in your Apache HTTP server configuration files, you should put these two files in the appropriate directory, based on your modifications.

Once these CA files have been moved, restart your server with the command

/sbin/service httpd restart

If your key file is encrypted, you will be asked for the password. Enter your password to start your server. Point your Web browser to your server’s home page. The URL to access your secure Web server will look like this:

https://your_domain
Note

The https: prefix is used for secure HTTP transactions.

If you are using a CA-signed certificate from a well-known CA, your browser will probably automatically accept the certificate (without prompting you for input) and create the secure connection. Your browser will not automatically recognize a test or a self-signed certificate, because the certificate is not signed by a CA. If you are not using a certificate from a CA, follow the instructions provided by your browser to accept the certificate. You can just accept the defaults by clicking Next until the dialogs are finished. Once your browser accepts the certificate, your secure Web server will show you a default home page.


Accessing Your Secure Server

To access your secure server, use a URL like this:

https://your_domain

Note that URLs intended to connect to your secure Web server should begin with the https: protocol designator instead of the more common http: protocol designator. Your nonsecure server can be accessed using an URL like this:

http://your_domain

The standard port for secure Web communications is port 443. The standard port for nonsecure Web communications is port 80. The secure Web server default configuration listens on both of the two standard ports. Therefore, you will not need to specify the port number in a URL (the port number is assumed). However, if you configure your server to listen on a nonstandard port (i.e., anything besides 80 or 443), you will need to specify the port number in every URL that is intended to connect to the server on the nonstandard port.

For example, you may have configured your server so that you have a virtual host running nonsecured on port 12331. Any URLs intended to connect to that virtual host must specify the port number in the URL. The following URL example will attempt to connect to a nonsecure Web server listening on port 12331:

http://your_domain:12331
Note

Some of the example URLs used in this book may need to be changed, depending upon whether you are accessing your secure Web server or your nonsecure Web server. Please view all URLs in this book as general examples and not as explicit instructions that will work under all circumstances.


Additional Resources

A number of valuable resources for further information about Apache are available. The package includes excellent documentation, and there is a great deal of Apache help available on the Web.

Installed Documentation

  • Apache HTTP Server documentation — If you have the httpd-manual package installed and the Apache HTTP server daemon (httpd) running, you can view the Apache HTTP server documentation. Open a Web browser and go to the URL http://localhost on the machine that is running the Apache HTTP server. Then, click the Documentation link.

  • /usr/share/docs/httpd-version — The Apache Migration HOWTO document contains a list of changes from version 1.3 to version 2.0 as well as information about how to migrate the configuration file manually.

  • mod_ssl documentation — Open a Web browser and go to the URL http://localhost/manual/mod/mod_ssl/ on the machine that is running the Apache HTTP server.

Useful Websites

  • http://www.apache.org — The Apache Software Foundation.

  • http://httpd.apache.org/docs-2.0/ — Apache HTTP Server Version 2.0 User’s Guide.

  • http://localhost/manual/index.html — After starting the Apache HTTP server on your local system, you can view the Apache HTTP server version 2.0 User’s Guide using this URL.

  • http://www.redhat.com/support/docs/apache.html — Red Hat Support maintains a list of useful Apache HTTP server links.

  • http://www.redhat.com/support/docs/faqs/RH-apache-FAQ/book1.html — The Red Hat Linux Apache Centralized Knowledgebase, compiled by Red Hat.

  • Mailing list — You can subscribe to the redhat-secure-server mailing list at http://www.redhat.com/mailing-lists. You can also subscribe to the redhat-secure-server mailing list by emailing redhat-secure-server-request@redhat.com and putting the word subscribe in the subject line.

  • http://www.modssl.org — The mod_ssl website is the definitive source for information about mod_ssl. The website includes a wealth of documentation, including a User Manual at http://www.modssl.org/docs.

Related Book

  • Apache: The Definitive Guide, 2nd edition, by Ben Laurie and Peter Laurie (O’Reilly & Associates)


Chapter 20: Network File System (NFS) and Samba

Network File System (NFS) is a way to share files between machines on a network as if the files were located on the client’s local hard drive. Red Hat Linux can be both an NFS server and an NFS client, which means that it can export file systems to other systems and mount file systems exported from other machines.

Why Use NFS?

NFS is useful for sharing directories of files between multiple users on the same network. For example, a group of users working on the same project can have access to the files for that project using a shared directory of the NFS file system (commonly known as an NFS share) mounted in the directory /myproject. To access the shared files, the user goes into the /myproject directory on his or her machine. There are no passwords to enter or special commands to remember. Users work as if the directory were on their local machines.


Mounting NFS File Systems

Use the mount command to mount a shared NFS directory from another machine:

mount shadowman.example.com:/misc/export /misc/local
Warning

The mount point directory on local machine (/misc/local in the above example) must exist.

In this command, shadowman.example.com is the hostname of the NFS fileserver, /misc/export is the directory that shadowman is exporting, and /misc/local is the location to mount the file system on the local machine. After the mount command runs (and if the client has proper permissions from the shadowman.example.com NFS server), the client user can execute the command ls /misc/local to display a listing of the files in /misc/export on shadowman.example.com.

Mounting NFS File Systems using /etc/fstab

An alternate way to mount an NFS share from another machine is to add a line to the /etc/fstab file. The line must state the hostname of the NFS server, the directory on the server being exported, and the directory on the local machine where the NFS share is to be mounted. You must be root to modify the /etc/fstab file.

The general syntax for the line in /etc/fstab is as follows:

server:/usr/local/pub  /pub    nfs     rsize=8192,wsize=8192,timeo=14,intr

The mount point /pub must exist on the client machine. After adding this line to /etc/fstab on the client system, type mount /pub at a shell prompt, and the mount point /pub will be mounted from the server.

Mounting NFS File Systems using autofs

A third option for mounting an NFS share is the use of autofs. autofs uses the automount daemon to manage your mount points by mounting them dynamically only when they are accessed. autofs consults the master map configuration file /etc/auto.master to determine which mount points are defined. It then starts an automount process with the appropriate parameters for each mount point. Each line in the master map defines a mount point and a separate map file that defines the file systems to be mounted under this mount point. For example, the /etc/auto.misc file might define mount points in the /misc directory; this relationship would be defined in the /etc/auto.master file.

Each entry in auto.master has three fields. The first field is the mount point. The second field is the location of the map file, and the third field is optional. The third field can contain information such as a timeout value. For example, to mount the directory /project52 on the remote machine penguin.host.net at the mount point /misc/myproject on your machine, add the following line to auto.master:

/misc           /etc/auto.misc --timeout 60

Add the following line to /etc/auto.misc:

myproject -rw,soft,intr,rsize=8192,wsize=8192 penguin.host.net:/project52

The first field in /etc/auto.misc is the name of the /misc subdirectory. This directory is created dynamically by automount. It should not actually exist on the client machine. The second field contains mount options such as rw for read and write access. The third field is the location of the NFS export, including the hostname and directory.

Note

The directory /misc must exist on the local file system and should contain no subdirectories.

autofs is a service. To start the service, type the following command at a shell prompt:

/sbin/service autofs restart

To view the active mount points, type the following command at a shell prompt:

/sbin/service autofs status

If you modify the /etc/auto.master configuration file while autofs is running, you must tell the automount daemon(s) to reload by typing the following command at a shell prompt:

/sbin/service autofs reload

To learn how to configure autofs to start at boot time, refer to Chapter 2.


Exporting NFS File Systems

Sharing files from an NFS server is known as exporting the directories. The NFS Server Configuration Tool can be used to configure a system as an NFS server. To use the NFS Server Configuration Tool, you must be running the X Window System. To start the application, select Main Menu Button (on the Panel) > Server Settings > NFS Server, or type redhat-config-nfs.

To add an NFS share, click the Add button. A dialog box will appear. The Basic tab requires the following information:

  • Directory — Specify the directory to share, such as /tmp.

  • Host(s) — Specify the host(s) to which to share the directory. See the “Hostname Formats” section of this chapter.

  • Basic permissions — Specify whether the directory should have read-only or read/write permissions.

The General Options tab allows the following options to be configured:

  • Allow connections from port 1024 and higher — Services started on port numbers less than 1024 must be started as root. Select this option to allow the NFS service to be started by a user other than root. This option corresponds to insecure.

  • Allow insecure file locking — Do not require a lock request. This option corresponds to insecure_locks.

  • Disable subtree checking — If a subdirectory of a file system is exported, but the entire file ystem is not exported, the server checks to see if the requested file is in the subdirectory exported. This check is called subtree checking. Select this option to disable subtree checking. If the entire file system is exported, selecting to disable subtree checking can increase the transfer rate. This option corresponds to no_subtree_check.

  • Sync write operations on request — Enabled by default, this option does not allow the server to reply to requests before the changes made by the request are written to the disk. This option corresponds to sync. If this is not selected, the async option is used.

  • Force sync of write operations immediately — Do not delay writing to disk. This option corresponds to no_wdelay.

The User Access tab allows the following options to be configured:

  • Treat remote root user as local root — By default, the user and group IDs of the root user are both 0. Root squashing maps the user ID 0 and the group ID 0 to the user and group IDs of anonymous so that root on the client does not have root privileges on the NFS server. If this option is selected, root is not mapped to anonymous, and root on a client has root privileges to exported directories. Selecting this option can greatly decrease the security of the system. Do not select it unless it is absolutely necessary. This option corresponds to no_root_squash.

  • Treat all client users as anonymous users — If this option is selected, all user and group IDs are mapped to the anonymous user. This option corresponds to all_squash.

  • Specify local user ID for anonymous users — If Treat all client users as anonymous users is selected, this option lets you specify a user ID for the anonymous user. This option corresponds to anonuid.

  • Specify local group ID for anonymous users — If Treat all client users as anonymous users is selected, this option lets you specify a group ID for the anonymous user. This option corresponds to anongid.

To edit an existing NFS share, select the share from the list, and click the Properties button. To delete an existing NFS share, select the share from the list, and click the Delete button. After you have finished adding, modifying, or deleting shares, the NFS service must be restarted. To apply the changes to the configuration file and restart the service, click the Apply button. If the NFS service is not already running, you will be prompted to start the service. Select Yes to start the daemon. The daemon must be running in order to export the configured directories. The old configuration file will be saved as /etc/exports.bak, and the new configuration will be written to /etc/exports.

NFS Server Configuration Tool reads and writes directly to the /etc/exports configuration file. Thus, the file can be modified manually after using the tool, and the tool can be used after modifying the file manually (provided the file was modified with correct syntax).

Command-Line Configuration

If you prefer editing configuration files using a text editor or if you do not have the X Window System installed, you can modify the configuration file directly. The /etc/exports file controls what directories the NFS server exports. Its format is as follows:

directory hostname(options)

The (options) component is not required. For example:

/misc/export          speedy.redhat.com

would allow users from speedy.redhat.com to mount /misc/export with the default read-only permissions, but:

/misc/export          speedy.redhat.com(rw)

would allow users from speedy.redhat.com to mount /misc/export with read-write privileges. Refer to the “Hostname Formats” section of this chapter for an explanation of possible hostname formats.

Be careful with spaces in the /etc/exports file. If there are no spaces between the hostname and the options in parentheses, the options apply only to the hostname. If there is a space between the hostname and the options, the options apply to the rest of the world. For example, examine the following lines:

/misc/export speedy.redhat.com(rw)
/misc/export speedy.redhat.com (rw)

The first line grants users from speedy.redhat.com read-write access and denies all other users. The second line grants users from speedy.redhat.com read-only access (the default) and allows the rest of the world read-write access.

Each time you change /etc/exports, you must inform the NFS daemon of the change, or reload the configuration file with the following command:

/sbin/service nfs reload

Hostname Formats

The host(s) can be in the following forms:

  • Single machine — A fully qualified domain name (that can be resolved by the server), hostname (that can be resolved by the server), or an IP address

  • Series of machines specified with wild cards — Use the * or ? character to specify a string match. For example, 192.168.100.* specifies any IP address that begins with 192.168.100. When specifying wildcards in fully qualified domain names, dots (.) are not included in the wildcard. For example, *.example.com includes one.example.com but does not include one.two.example.com.

  • IP networks — Use a.b.c.d/z, where a.b.c.d is the network and z is the number of bits in the netmask (for example 192.168.0.0/24). Another acceptable format is a.b.c.d/netmask, where a.b.c.d is the network and netmask is the netmask (for example, 192.168.100.8/255.255.255.0).

  • Netgroups — In the format @group-name, where group-name is the NIS netgroup name.

Starting and Stopping the Server

On the server that is exporting NFS file systems, the NFS service must be running. View the status of the NFS daemon with the following command:

/sbin/service nfs status

Start the NFS daemon with the following command:

/sbin/service nfs start

Stop the NFS daemon with the following command:

/sbin/service nfs stop

To start the NFS service at boot time, use the command:

/sbin/chkconfig --level 345 nfs on

You can also use chkconfig, ntsysv, or the Services Configuration Tool to configure which services start at boot time.


Samba

Samba uses the SMB protocol to share files and printers across a network connection. Operating systems that support this protocol include Microsoft Windows (through its Network Neighborhood), OS/2, and Linux.

Why Use Samba?

Samba is useful if you have a network of both Windows and Linux machines. Samba will allow files and printers to be shared by all the systems in your network. If you want to share files between Red Hat Linux machines only, refer to the previous section. If you want to share printers between Red Hat Linux machines only, refer to Chapter 8.

Configuring Samba

Samba uses /etc/samba/smb.conf as its configuration file. If you change this configuration file, the changes will not take effect until you restart the Samba daemon with the command service smb restart. The default configuration file (smb.conf) in Red Hat Linux 8.0 allows users to view their Linux home directories as a Samba share on the Windows machine after they log in using the same username and password. It also shares any printers configured for the Red Hat Linux system as Samba shared printers. In other words, you can attach a printer to your Red Hat Linux system and print to it from the Windows machines on your network.

To specify the Windows workgroup and description string, edit the following lines in your smb.conf file:

workgroup = WORKGROUPNAME
server string = BRIEF COMMENT ABOUT SERVER

Replace WORKGROUPNAME with the name of the Windows workgroup to which this machine should belong. The BRIEF COMMENT ABOUT SERVER is optional and will be the Windows comment about the Samba system.

To create a Samba share directory on your Linux system, add the following section to your smb.conf file (after modifying it to reflect your needs and your system):

[sharename]
comment = Insert a comment here
path = /home/share/
valid users = tfox carole
public = no
writable = yes
printable = no
create mask = 0765

The above example allows the users tfox and carole to read and write to the directory /home/share, on the Samba server, from a Samba client.

Samba Passwords

In Red Hat Linux 8.0, the use of encrypted passwords is enabled by default because it is more secure. If encrypted passwords are not used, plaintext passwords are used, which can be intercepted by someone using a network packet sniffer. It is recommended that encrypted passwords be used. The Microsoft SMB Protocol originally used plaintext passwords. However, Windows 2000 and Windows NT 4.0 with Service Pack 3 or higher require encrypted Samba passwords. To use Samba between a Red Hat Linux system and a system with Windows 2000 or Windows NT 4.0 Service Pack 3 or higher, you can either edit your Windows registry to use plaintext passwords or configure Samba on your Linux system to use encrypted passwords. If you choose to modify your registry, you must do so for all your Windows NT or 2000 machines — this is risky and may cause further conflicts.

To configure Samba on your Red Hat Linux system to use encrypted passwords, follow these steps:

  1. Create a separate password file for Samba. To create one based on your existing /etc/passwd file, at a shell prompt, type the following command:

    cat /etc/passwd | mksmbpasswd.sh > /etc/samba/smbpasswd

  2. If the system uses NIS, type the following command:

    ypcat passwd | mksmbpasswd.sh > /etc/samba/smbpasswd

  3. The mksmbpasswd.sh script is installed in your /usr/bin directory with the Samba package.

  4. Change the permissions of the Samba password file so that only root has read and write permissions:

    chmod 600 /etc/samba/smbpasswd

  5. The script does not copy user passwords to the new file. To set each Samba user’s password, use the command (replace username with each user’s username):

    smbpasswd username

  6. A Samba user account will not be active until a Samba password is set for it.

  7. Encrypted passwords must be enabled in the Samba configuration file. In the file smb.conf, verify that the following lines are not commented out:

    encrypt password = yes
smb passwd file = /etc/samba/smbpasswd

  8. Make sure the smb service is started by typing the command service smb restart at a shell prompt.

  9. If you want the smb service to start automatically, use ntsysv, chkconfig, or Services Configuration Tool to enable it at runtime. Refer to Chapter 13 for details.

    Tip

    Read /usr/share/doc/samba-version/docs/htmldocs/ENCRYPTION.html to learn more about encrypted passwords (replace version with the version number of Samba that you have installed).

The pam_smbpass PAM module can be used to sync users’ Samba passwords with their system passwords when the passwd command is used. If a user invokes the passwd command, the password he or she uses to log in to the Red Hat Linux system and the password he or she must provide to connect to a Samba share are changed. To enable this feature, add the following line to /etc/pam.d/system-auth below the pam_cracklib.so invocation:

password required /lib/security/pam_smbpass.so nullok use_authtok try_first_pass

Connecting to a Samba Share

To connect to a Linux Samba share from a Microsoft Windows machine, use Network Neighborhood or Windows Explorer. To connect to a Samba share from a Linux system, type the following at a shell prompt:

smbclient //hostname/sharename -U username

You will need to replace hostname with the hostname or IP address of the Samba server you want to connect to, sharename with the name of the shared directory you want to browse, and username with the Samba username for the system. Enter the correct password or press Enter if no password is required for the user.

If you see the smb:\ prompt, you have successfully logged in. Once you are logged in, type help for a list of commands. If you wish to browse the contents of your home directory, replace sharename with your username. If the -U switch is not used, the username of the current user is passed to the Samba server. To exit smbclient, type exit at the smb:\ prompt.

You can also use Nautilus to view available Samba shares on your network. On the GNOME desktop, go to the Main Menu Button (on the Panel) > Home Folder to open a Nautilus window. Type smb: in the Location: bar. You will see an icon for each available SMB workgroups on your network. To access one, double-click the icon for it.

If the SMB share you are connecting to requires a user name and password combination, you must specify them in the Location: bar using the following syntax (replace user, password, servername, and sharename with the appropriate values):

smb://user:password@servername/sharename/


Additional Resources

For more detailed information, and for configuration options not covered here, refer to the following resources.

Installed Documentation

  • smb.conf man page — explains how to configure the Samba configuration file

  • smbd man page — describes how the Samba daemon works

  • /usr/share/doc/samba-version-number/docs/ — HTML and text help files included with the Samba package

  • The man pages for nfsd, mountd, exports, auto.master, and autofs (in manual sections 5 and 8) — These man pages show the correct syntax for the NFS and autofs configuration files.

Useful Websites

  • http://www.samba.org — The Samba Web page contains useful documentation, information about mailing lists, and a list of GUIs.

  • http://www.tldp.org/HOWTO/NFS-HOWTO/index.html — The Linux NFS-HOWTO from the Linux Documentation Project.

Related Books

  • Managing NFS and NIS Services by Hal Stern (O’Reilly & Associates, Inc.)


Part IV: Security

Chapter List

Chapter 21: Controlling Access to Services
Chapter 22: Basic Firewall Configuration
Chapter 23: Kerberos
Chapter 24: OpenSSH
Chapter 25: Pluggable Authentication Modules (PAM)
Chapter 26: Tripwire


Chapter 21: Controlling Access to Services

Overview

Maintaining security on your Red Hat Linux system is extremely important. One way to manage security on your system is to carefully manage access to system services. Your system may need to provide open access to particular services (for example, httpd if you are running a Web server). However, if you do not need to provide a service, you should turn it off — this will minimize your exposure to possible bug exploits.

There are several different methods for managing access to system services. You must decide which method you would like to use based on the service, your system’s configuration, and your level of Linux expertise. The easiest way to deny access to a service is to simply turn it off. Both the services managed by xinetd (which we will talk about more later in this chapter) and the services in the /etc/rc.d hierarchy can be configured to start or stop using three different applications:

  • Services Configuration Tool — a graphical application that displays a description of each service, displays whether each service is started at boot time (for runlevels 3, 4, and 5), and allows you to start, stop, and restart each service.

  • ntsysv — a text-based application that allows you to configure which services are started at boot time for each runlevel. Changes do not take effect immediately. Services cannot be started, stopped, or restarted using this program.

  • chkconfig — a command-line utility that allows you to turn services on and off for the different runlevels. Changes do not take effect immediately for non-xinetd services. Non-xinetd services cannot be started, stopped, or restarted using this utility.

You may find that these tools are easier to use than the alternatives — editing the numerous symbolic links located in the directories below /etc/rc.d manually or editing the xinetd configuration files in /etc/xinetd.d.

Another way to manage access to system services is by using iptables to configure an IP firewall. If you are a new Linux user, please realize that iptables may not be the best solution for you. Setting up iptables can be complicated and is best tackled by experienced UNIX/Linux system administrators. On the other hand, the benefit of using iptables is flexibility. For example, if you need a customized solution that provides certain hosts access to certain services, iptables can provide it for you.

Alternatively, if you are looking for a utility that will set general access rules for your home machine, and/or if you are new to Linux, you should try the GNOME Lokkit utility. GNOME Lokkit is a GUI utility that will ask you questions about how you want to use your machine. Based on your answers, it will then configure a simple firewall for you. Refer to Chapter 22 for more information. You can also use the Services Configuration Tool (redhat-config-servicelevel). It allows you to select the security level for your system, similar to the Service Level screen in the Red Hat Linux installation program.


Runlevels

Before you can configure access to services, you must understand Linux runlevels. A runlevel is a state, or mode, that is defined by the services listed in the directory /etc/rc.d/rc x.d, where x is the number of the runlevel. Red Hat Linux uses the following runlevels:

  • 0 — Halt

  • 1 — Single-user mode

  • 2 — Not used (user-definable)

  • 3 — Full multi-user mode

  • 4 — Not used (user-definable)

  • 5 — Full multi-user mode (with an X-based login screen)

  • 6 — Reboot

If you configured the X Window System during the Red Hat Linux installation program, you had the option of choosing a graphical or text login screen. If you chose a text login screen, you are operating in runlevel 3. If you chose a graphical login screen, you are operating in runlevel 5. The default runlevel can be changed by modifying the /etc/inittab file, which contains a line near the top of the file similar to the following:

id:3:initdefault:

Change the number in this line to the desired runlevel. The change will not take effect until you reboot the system. To change the runlevel immediately, use the command telinit followed by the runlevel number. You must be root to use this command.


What Is TCP wrappers?

TCP wrappers is installed by default with a server-class installation of Red Hat Linux 8.0 and provides access control to a variety of services. Most modern network services, such as SSH, Telnet, and FTP, make use of TCP wrappers, a program designed to stand guard between an incoming request and the requested service. The idea behind TCP wrappers is that client requests to server applications are “wrapped” by an authenticating service, allowing a greater degree of access control and logging for anyone attempting to use the service.

The functionality behind TCP wrappers is provided by libwrap.a, a library that network services, such as xinetd, sshd, and portmap, are compiled against. Additional network services, even networking programs you may write, can be compiled against libwrap.a to provide this functionality. Red Hat Linux bundles the necessary TCP wrapper programs and library in the tcp_wrappers-version RPM file.

TCP wrapper Advantages

When a user attempts to gain client access to a network service that is using TCP wrappers, a small wrapper program reports the name of the service requested and the client’s host information. The wrapper program does not directly send any information back to the client, and after the access control directives are satisfied, the wrapper is unloaded and frees up its resources. The client and the server can then resume actions without further wrapper intervention. TCP wrappers provide two basic advantages over other network service control techniques:

  • The connecting client is unaware that TCP wrappers are in use. Legitimate users will not notice anything different, and attackers never receive any additional information about why their attempted connections have failed.

  • TCP wrappers operate separately from the applications the wrapper program protects. This allows many server applications to share a common set of configuration files for simpler management.


Host-Based Access Control Lists

Host-based access for services that use TCP wrappers is controlled by two files: /etc/hosts.allow and /etc/hosts.deny. These files use a simple format to control access to services on a server. If no rules are specified in either hosts.allow or hosts.deny, then the default rule is to allow anyone to access to the services.

Order is important since rules in hosts.allow take precedence over rules specified in hosts.deny. Even if a rule specifically denying all access to a particular service is defined in hosts.deny, hosts specifically given access to the service in hosts.allow are allowed to access the service. In addition, all rules in each file take effect from the top down. Any changes to these files take effect immediately, so restarting services is not required.

Formatting Rules

All access control rules are placed on lines within hosts.allow and hosts.deny, and any blank lines or lines that start with the hash mark (#) are ignored. Each rule needs to be on its own line. The rules must be formatted in the following manner:

daemon_list : client_list [: spawn shell_command ]

Each of these options refers to a different part of the rule:

  • daemon_list — A collection of one or more process names or special wildcards, separated by whitespace.

  • client_list — One or more hostnames, host addresses, patterns, or wildcards, separated by whitespace, to use when a particular process name matches a requested service.

  • shell_command — An optional component that specifies something to be done in the event a rule is utilized.

Patterns are particularly helpful when specifying groups of clients that may or may not access a certain service. If a . character is placed at the beginning of a string, all hosts that share the end of that string are applied to that rule. So, .domain.com would catch both system1.domain.com and system2.domain.com. The . character at the end of a string has the same effect, except going the other direction. This is primarily used for IP addresses, as a rule pertaining to 192.168.0. would apply to the entire class C block of IP addresses. Netmask expressions can also be used as a pattern to control access to a particular group of IP addresses. You can even use asterisks (*) or question marks (?) to select entire groups of hostnames or IP addresses, so long as you do not use them in the same string as the other types of patterns.

If a list of hostnames with access a service is too long or is difficult to control within host.allow or hosts.deny, you can also specify the full path to a file (such as /etc/telnet.hosts.deny). This file contains hostnames, host addresses, or patterns, separated by whitespace, that you want to allow or deny access to that service. This method also works well for sharing access control lists between various services, as changes would need to be made in only one file per service. The following wildcards may be used in the access control rules instead of using specific hosts or groups of hosts:

  • ALL — Matches every client with a service. To allow a client access to all services, use ALL in the daemons section.

  • LOCAL — Matches any host that does not contain a . character.

  • KNOWN — Matches any host where the hostname and host address are known or where the user is known.

  • UNKNOWN — Matches any host where the hostname or host address are unknown or where the user is unknown.

  • PARANOID — Matches any host where the hostname does not match the host address.

    Warning

    The KNOWN, UNKNOWN, and PARANOID wildcards should be used very carefully, as a disruption in name resolution may prevent legitimate users from gaining access to a service.

The access control language also contains a powerful operator, EXCEPT, which allows separate lists to be combined within the same rule line. When EXCEPT is used between two lists, the first list applies unless an entry from the second list matches an entity covered by the first list. EXCEPT can be used with daemon or client lists. Consider the following hosts.allow example:

# all domain.com hosts are allowed to connect
# to all services except cracker.domain.com
ALL: .domain.com EXCEPT cracker.domain.com

# 123.123.123.* addresses can use all services except FTP
ALL EXCEPT in.ftpd: 123.123.123.
Note

Organizationally, it usually makes more sense to use EXCEPT operators sparingly, choosing instead to place the exceptions to the rule in the other access control file. This allows all administrators to quickly scan the appropriate files to see what hosts should be allowed or denied access to which services without having to sort through the various EXCEPT operators.

The best way to manage access control with hosts.allow and hosts.deny is to use the two files together to achieve the desired results. Users who wish to prevent any hosts other than specific ones from accessing services usually place ALL: ALL in hosts.deny. Then, they place lines in hosts.allow, such as:

in.telnetd: 10.0.1.24
in.ftpd: 10.0.1. EXCEPT 10.0.1.1

Alternatively, if you wish to allow anyone to use network services except for specific hosts, leave hosts.allow blank and add any necessary restrictions to hosts.deny, such as:

in.fingerd: 192.168.0.2
Warning

Be very careful about using hostnames and domain names in both access control files, especially hosts.deny. Various tricks could be used by an attacker to circumvent rules specifying a hostname or domain name. In addition, if your system selectively allows access based on hostname and domain name information, any disruption in DNS service would prevent even authorized users from using network services. Using IP addresses whenever possible can prevent many problems when constructing access control rules, especially those that deny access.

Beyond simply allowing or denying access to services for certain hosts, TCP wrappers also supports the use of shell commands. These shell commands are most commonly used with deny rules to set up booby traps, which usually trigger actions that log information about failed attempts to a special file or email an administrator. Following is an example of a booby trap in the hosts.deny file that will write a log line containing the date and client information every time a host from the IP range 10.0.1.0 to 10.0.1.255 attempts to connect via Telnet:

in.telnetd: 10.0.1.: spawn (/bin/echo `date` %c >> /var/log/telnet.log) &

Another feature of using shell commands is support for expansions. Expansions provide the command with information about the client, server, and process involved. Following is a list of supported expansions:

  • %a — The client’s IP address.

  • %A — The server’s IP address.

  • %c — Supplies a variety of client information, such as the username and hostname, or the username and IP address.

  • %d — The daemon process name.

  • %h — The client’s hostname (or IP address, if the hostname is unavailable).

  • %H — The server’s hostname (or IP address, if the hostname is unavailable).

  • %n — The client’s hostname. If unavailable, unknown is printed. If the client’s hostname and host address do not match, paranoid is printed.

  • %N — The server’s hostname. If unavailable, unknown is printed. If the server’s hostname and host address do not match, paranoid is printed.

  • %p — The daemon process ID.

  • %s — Various types of server information, such as the daemon process and the host or IP address of the server.

  • %u — The client’s username. If unavailable, unknown is printed.

For a full explanation of available shell commands, as well as some additional access control examples, see the man page for hosts_access.

Note

Special attention must be given to portmap when host access control lists. Only IP addresses or the ALL option should be used when specifying hosts to allow or deny, as hostnames are not supported. In addition, changes to the host access control lists that concern portmap may not take effect immediately. Widely used services, such as NIS and NFS, depend on portmap to operate, so be aware of these limitations before depending on hosts.allow and hosts.deny to control access.


Access Control Using xinetd

The benefits offered by TCP wrappers are enhanced when the libwrap.a library is used in conjunction with xinetd, a super-daemon that provides additional access, logging, binding, redirection, and resource utilization control. Red Hat Linux configures a variety of popular network services to be used with xinetd, including FTP, IMAP, POP, and Telnet. When any of these services are accessed via their port numbers in /etc/services, the xinetd daemon handles the request. Before bringing up the requested network service, xinetd ensures that the client host information meets the access control rules, that the number of instances of this service is under a particular threshold, and that any other rules specified for that service or all xinetd services are followed. Once the target service is brought up for the connecting client, xinetd goes back to sleep, waiting for additional requests for the services it manages.

xinetd Configuration Files

The xinetd service is controlled by the /etc/xinetd.conf file, as well as the various service-specific files in the /etc/xinetd.d/ directory.

/etc/xinetd.conf

The xinetd.conf file is the parent of all xinetd-controlled service configuration files, as the service-specific files are also parsed every time xinetd starts. By default, xinetd.conf contains some basic configuration settings that apply to every service. Following is an example of a typical xinetd.conf:

Defaults
{
               instances                   = 60
               log_type                    = SYSLOG authpriv
               log_on_success              = HOST PID
               log_on_failure              = HOST
               cps                         = 25 30
}

includedir /etc/xinetd.d

These lines control various aspects of xinetd:

  • instances — Sets the maximum number of requests a particular service can handle at once.

  • log_type — Tells xinetd to use the authpriv log, specified in /etc/syslog.conf and set to /var/log/secure by default, rather than use another specific file. Using FILE /var/log/xinetdlog here instead would move xinetd logging to a separate /var/log/xinetdlog file.

  • log_on_success — Lets xinetd know what to log if the connection is successful. By default, the remote host’s IP address and the process ID of server processing the request are recorded.

  • log_on_failure — Tells xinetd what to log if the connection fails or is not allowed.

  • cps — Tells xinetd to allow no more than 25 connections per second to a given service. If this limit is reached, the service is retired for 30 seconds.

    Note

    Both the log_on_success and log_on_failure settings in /etc/xinetd.conf are often modified by each service, meaning that successful and failed connections will usually log more information than is indicated in /etc/xinetd.conf.

Various logging options are available in /etc/xinetd.conf and the service-specific xinetd configuration files:

  • ATTEMPT — Logs the fact that a failed attempt was made. (log_on_failure)

  • DURATION — Logs the length of time the service is used by a remote system. (log_on_success)

  • EXIT — Logs the exit status or termination signal of the service. (log_on_success)

  • HOST — Logs the remote host’s IP address. (log_on_failure and log_on_success)

  • PID — Logs the process ID of the server receiving the request. (log_on_success)

  • RECORD — Records information about the remote system in case the service cannot be started. Only particular services, such as login and finger, may use this option. (log_on_failure)

  • USERID — Logs the remote user using the method defined in RFC 1413 for all multi-threaded stream services. (log_on_failure and log_on_success)

Other options for /etc/xinetd.conf are available, such as per_source, which limits the maximum number of connections from a particular IP address to a specific service. See the xinetd man page for more information.

Files in the /etc/xinetd.d/ Directory

The files in the /etc/xinetd.d/ directory are read every time xinetd starts, because of the includedir /etc/xinetd.d/ statement at the bottom of /etc/xinetd.conf. These files, with names such as finger, ipop3, and rlogin, correlate to the services controlled by xinetd. The files in /etc/xinetd.d/ use the same conventions as /etc/xinetd.conf. The primary reason they are stored in separate configuration files is to make it easier to add and remove a service from xinetd without affecting other services. To get an idea of how these files are structured, consider the wu-ftp file:

service ftp
{
            socket_type                 = stream
            wait                        = no
            user                        = root
            server                      = /usr/sbin/in.ftpd
            server_args                 = -l –a
            log_on_success             += DURATION USERID
            log_on_failure             += USERID
            nice                        = 10
            disable                     = yes
}

The first line defines the service’s name. The lines within the braces contain settings that define how this service is supposed to be started and used. The wu-ftp file states that the FTP service uses a stream socket type (rather than dgram), the binary executable file to use, the arguments to pass to the binary, the information to log in addition to the /etc/xinetd.conf settings, the priority with which to run the service, and more.

The use of xinetd with a service also can serve as a basic level of protection from a Denial of Service (DoS) attack. The max_load option takes a floating-point value to set a CPU usage threshold when no more connections for a particular service will be accepted, preventing certain services from overwhelming the system. The cps option accepts an integer value to set a rate limit on the number of connections available per second. Configuring this value to something low, such as 3, will help prevent attackers from being able to flood your system with too many simultaneous requests for a particular service.

Access Control within xinetd

Users of xinetd services can choose to use the TCP wrappers host access control files (/etc/hosts.allow and /etc/hosts.deny), provide access control via the xinetd configuration files, or a mixture of both. Information concerning the use of TCP wrappers host access control files can be found in the “What Is TCP Wrappers?” section earlier in this chapter. This section of the chapter will discuss using xinetd to control access to services.

Note

Unlike TCP wrappers host access control files, any changes to xinetd configuration files require a restart of the xinetd service to take effect.

The xinetd host access control available through its various configuration files is different from the method used by TCP wrappers. While TCP wrappers places all of the access configuration within two files, /etc/hosts.allow and /etc/hosts.deny, each service’s file in /etc/xinetd.d can contain access control rules based on the hosts that will be allowed to use that service. The following options are supported in the xinetd files to control host access:

  • only_from — Allows the hosts specified to use the service.

  • no_access — Blocks these hosts from using this service.

  • access_times — Specifies the time range when a particular service may be used. The time range must be stated in a HH:MM-HH:MM format using 24-hour notation.

The only_from and no_access options can use a list of IP addresses or hostnames or can specify an entire network. As with TCP wrappers, combining xinetd access control with the proper logging configuration for that service allows you not only to block the request but also to record every attempt to access it. For example, the following /etc/xinetd.d/telnet file can be used to block Telnet access to a system by a particular network group and restrict the overall time range within which even legitimate users can log in:

service telnet
{
              disable            = no
              flags              = REUSE
              socket_type        = stream
              wait               = no
              user               = root
              server             = /usr/sbin/in.telnetd
              log_on_failure     += USERID
              no_access          = 10.0.1.0/24
              log_on_success     += PID HOST EXIT
              access_times       = 09:45-16:15
}

In this example, any system from the 10.0.1.0/24 subnet, such as 10.0.1.2, that tries to telnet into the server will receive a message stating Connection closed by foreign host. In addition, the login attempt is logged in /var/log/secure:

May 15 17:35:47 boo xinetd[16188]: START: telnet pid=16191 from=10.0.1.2
May 15 17:38:49 boo xinetd[16252]: START: telnet pid=16256 from=10.0.1.2
May 15 17:38:49 boo xinetd[16256]: FAIL: telnet address from=10.0.1.2
May 15 17:38:49 boo xinetd[16252]: EXIT: telnet status=0 pid=16256

Binding and Port Redirection

The service configuration files for xinetd also support binding the service to an IP address and redirecting incoming requests for that service to another IP address, hostname, or port. Binding is controlled with the bind option in the service configuration files and links the service to one IP address on the system. When used, the bind option allows only requests for the proper IP address to access the service. Each service can be bound to different network interfaces based on your needs. This is particularly useful for systems with multiple network adapters or using multiple IP addresses. For instance, you can configure Telnet to listen only on the interface connected to a private network and not to the interface connected with the Internet.

The redirect option accepts an IP address or hostname followed by a port number. It tells the service to redirect any requests for this service to the specified host and port number. This feature can be used to point to another port number on the same system, redirect the request to different IP address on the same machine, shift the request to a totally different system and port number, or any combination of these options. In this way, a user connecting to certain service on a system may be rerouted to another system with no disruption. The xinetd daemon is able to accomplish this redirection by spawning a process that stays alive for the duration of the connection between the requesting client machine and the host actually providing the service, transferring data between the two systems.

The real strength of the bind and redirect options can be seen when they are used together. By binding a service to a particular IP address on a system and then redirecting requests for this service to a second machine that only the first machine can see, you can use an internal system to provide services for a totally different network. Alternatively, these options can be used to limit the exposure of a particular service on a multi-homed machine to a known IP address, as well as redirect any requests for that service to another machine specially configured for that purpose. For example, consider a system that is used as a firewall with this setting for its telnet service:

service telnet
{
           socket_type            = stream
           wait                   = no
           server                 = /usr/sbin/in.telnetd
           log_on_success        += DURATION USERID
           log_on_failure        += USERID
           bind                   = 123.123.123.123
           redirect               = 10.0.1.13 21 23
}

The bind and redirect options in this file will ensure that the telnet service on the machine is bound to the external IP address (123.123.123.123), the one facing the Internet. In addition, any requests for telnet service sent to 123.123.123.123 will be redirected via a second network adapter to an internal IP address (10.0.1.13) that only the firewall and internal systems can access. The firewall will then send the communication between the two systems, and the connecting system will think it is connected to 123.123.123.123 when it is actually connected to a different machine.

This feature is particularly useful for users with broadband connections and only one fixed IP address. When one is using Network Address Translation (NAT), the systems behind the gateway machine, which are using internal-only IP addresses, are not available from outside the gateway system. However, when certain services controlled by xinetd are configured with the bind and redirect options, the gateway machine can act as a type of proxy between outside systems and a particular internal machine configured to provide the service. In addition, the various xinetd access control and logging options are also available for additional protection, such as limiting the number of simultaneous connections for the redirected service.


The Services Configuration Tool

The Services Configuration Tool is a graphical application developed by Red Hat to configure which SysV services in /etc/rc.d/init.d are started at boot time (for runlevels 3, 4, and 5) and which xinetd services are enabled. It also allows you to start, stop, and restart SysV services as well as restart xinetd. To start Services Configuration Tool from the desktop, go to the Main Menu Button (on the Panel) > Server Settings > Services or type redhat-config-services at a shell prompt (for example, in an XTerm window or a GNOME terminal window).

Controlling access to network services can be a challenge. Firewalls are useful for controlling access in and out of a particular network, but they can be difficult to configure. TCP wrappers and xinetd control access to services by hostname and IP addresses. In addition, these tools also include logging and utilization management capabilities that are easy to configure.

Figure 21-1: The Services Configuration Tool

The Services Configuration Tool displays the current runlevel as well as which runlevel you are currently editing. To edit a different runlevel, select Edit Runlevel from the pull-down menu and select runlevel 3, 4, or 5. The Services Configuration Tool lists the services from /etc/rc.d/init.d as well as the services controlled by xinetd.

Click on a service to display a brief description of that service at the bottom of the window. To start, stop, or restart a service immediately, select the service and choose the action from the Actions pull-down menu. You can also select the service and click the Start, Stop, or Restart buttons on the toolbar. If you select an xinetd service such as telnet, the Start, Stop, and Restart buttons will not be active. If you change the Start at Boot value of an xinetd service, you must click the Save Changes button to restart xinetd and disable/enable the xinetd services you changed.

To enable a service at boot time for the currently selected runlevel, check the checkbox beside the name of the service under the Start at Boot column. After configuring the runlevel, you must apply the changes. Select File > Save Changes from the pull-down menu or click the Save Changes button.

Note

When you save changes to xinetd services, xinetd is restarted. When you save changes to other services, the runlevel is reconfigured, but the changes do not take effect immediately.

If you check or uncheck the Start at Boot value for a service in /etc/rc.d/init.d, the Save Changes button will become active. Click it to reconfigure the currently selected runlevel. The changes do not affect the system immediately. For example, assume you are configuring runlevel 3. If you change the Start at Boot value for the anacron service from checked to unchecked and then click the Save Changes button, the runlevel 3 configuration changes so that anacron is not started at boot time. However, runlevel 3 is not reinitialized, so anacron is still running. Select one of the following options at this point:

  • Stop the anacron service. Stop the service by selecting it from the list and clicking the Stop the selected service button. A message will be displayed stating that the service was stopped successfully.

  • Re-initialize the runlevel. Reinitialize the runlevel by going to a shell prompt (such as an XTerm or GNOME terminal) and typing the command telinit 3 (where 3 is the runlevel number used in this example; substitute the appropriate number if you are working with a different runlevel). This option is recommended if you change the Start at Boot value of more than one service and want to activate the changes immediately.

  • Do nothing else. You do not have to stop the anacron service. You can wait until the system is rebooted for the service to stop. The next time the system is booted, the runlevel will be initialized without the anacron service running.


ntsysv

The ntsysv utility provides a simple interface for activating or deactivating services. You can use ntsysv to turn an xinetd-managed service on or off. You can also use ntsysv to start or stop a service in the /etc/rc.d hierarchy; in that case, the ntsysv command (without options) is used to configure current runlevel. If you want to configure a different runlevel, use something like ntsysv --levels 016. (In this example, you would be setting the services for runlevels 0, 1, and 6.)

The ntsysv interface works like the text-mode installation program. Use the up and down arrows to navigate up and down the list. The space bar selects/unselects services and is also used to “press” the Ok and Cancel buttons. To move between the list of services and the Ok and Cancel buttons, use the Tab key. An * signifies that a service is set to on. Pressing the F1 key will pop up a short description of each service.

Warning

Changes made with ntsysv do not take effect immediately. You must stop or start the individual service with the command service daemon stop. In the previous example, replace daemon with the name of the service you want to stop — for example, httpd. Replace stop with start or restart to start or restart the service. If you want to start or stop a service that is managed by xinetd, use the command service xinetd restart.

chkconfig

The chkconfig command can also be used to activate and deactivate services. If you use the chkconfig --list command, you will see a list of system services and whether they are started (on) or stopped (off) in runlevels 0 through 6 (at the end of the list, you will see a section for the services managed by xinetd. If you use chkconfig --list to query a service managed by xinetd, you will see whether the xinetd service is enabled (on) or disabled (off). For example, the following command shows that finger is enabled as an xinetd service:

$ chkconfig --list finger
finger               on

As shown above, if xinetd is running, finger is enabled. If you use chkconfig --list to query a service in /etc/rc.d, you will see the service’s settings for each runlevel, as in the following example:

$ chkconfig --list anacron
anacron    0:off   1:off   2:on   3:on   4:on   5:on   6:off

More important, chkconfig can be used to set a service to be started (or not) in a specific runlevel. For example, to turn nscd off in runlevels 3, 4, and 5, use the command

chkconfig --level 345 nscd off

See the chkconfig man page for more information on how to use it.

Warning

Services managed by xinetd are immediately affected by chkconfig. For example, if xinetd is running, finger is disabled, and the command chkconfig finger on is executed, finger is immediately enabled without your having to restart xinetd manually. Changes for other services do not take effect immediately after using chkconfig. You must stop or start the individual service with the command service daemon stop. In the previous example, replace daemon with the name of the service you want to stop — for example, httpd. Replace stop with start or restart to start or restart the service.


Additional Resources

For more information on xinetd, refer to the following resources.

Installed Documentation

  • man ntsysv — The ntsysv man page.

  • man chkconfig — The chkconfig man page.

  • man xinetd — The xinetd man page.

  • man xinetd.conf — The man page for the xinetd.conf configuration file.

  • man 5 hosts_access — The man page for the format of host access control files (in section 5 of the man pages).

The bundled documentation on your system is a good place to start looking for additional TCP wrappers, xinetd, and access control configuration options.

  • /usr/share/doc/tcp_wrappers-version — Contains a README file that discusses how TCP wrappers work and the various hostname and host address spoofing risks that exist.

  • /usr/share/doc/xinetd-version — Includes a README file that discusses aspects of access control and a sample.conf file with various ideas for modifying /etc/xinetd.d service configurations.

  • For detailed information concerning the creation of TCP wrapper access control rules, read the hosts_access(5) and hosts_options(5) man pages.

The xinetd(8) and xinetd.conf(5) man pages contain additional information for creating xinetd configuration files and a description of how xinetd works.

Useful Websites

  • http://www.xinetd.org — The home of xinetd, containing sample configuration files, a full listing of features, and an informative FAQ.

  • http://www.macsecurity.org/resources/xinetd/tutorial.shtml — A thorough tutorial that discusses many different ways to tweak default xinetd configuration files to meet specific security goals.


Chapter 22: Basic Firewall Configuration

Just as a firewall in a building attempts to prevent a fire from spreading, a computer firewall attempts to prevent computer viruses from spreading to your computer and to prevent unauthorized users from accessing your computer. A firewall exists between your computer and the network. It determines which services on your computer remote users on the network can access. A properly configured firewall can greatly increase the security of your system. It is recommended that you configure a firewall for any Red Hat Linux system with an Internet connection.

The Security Level Configuration Tool

During the Firewall Configuration sequence of the Red Hat Linux installation, you were given the option to choose a high, medium, or no security level as well as allow specific devices, incoming services, and ports. After installation, you can change the security level of your system by using the Security Level Configuration Tool. If you prefer a wizard-based application, refer to the “GNOME Lokkit” section of this chapter. To start the application, select Main Menu Button (on the Panel) > System Settings > Security Level or type redhat-config-securitylevel at a shell prompt (for example, in an XTerm window or a GNOME terminal window).

High

If you choose High, your system will not accept connections (other than the default settings) that are not explicitly defined by you. By default, only the following connections are allowed:

  • DNS replies

  • DHCP, so any network interfaces that use DHCP can be properly configured

If you choose High, your firewall will not allow the following:

  • Active mode FTP (passive mode FTP, used by default in most clients, should still work)

  • IRC DCC file transfers

  • RealAudio

  • Remote X Window System clients

If you are connecting your system to the Internet but do not plan to run a server, this is the safest choice. If additional services are needed, you can choose Customize to allow specific services through the firewall.

Click To expand
Figure 22-1: The Security Level Configuration Tool

Select the desired security level from the pull-down menu.

Note

If you select a medium or high firewall, network authentication methods (NIS and LDAP) will not work.

Medium

If you choose Medium, your firewall will not allow remote machines to have access to certain resources on your system. By default, access to the following resources are not allowed:

  • Ports lower than 1023 — the standard reserved ports, used by most system services, such as FTP, SSH, telnet, HTTP, and NIS.

  • The NFS server port (2049) — NFS is disabled for both remote servers and local clients.

  • The local X Window System display for remote X clients.

  • The X Font server port (by default, xfs does not listen on the network; it is disabled in the font server).

If you want to allow resources such as RealAudio while still blocking access to normal system services, choose Medium. Select Customize to allow specific services through the firewall.

Note

If you select a medium or high firewall, network authentication methods (NIS and LDAP) will not work.

No Firewall

No firewall provides complete access to your system and does no security checking. Security checking is the disabling of access to certain services. This should be selected only if you are running on a trusted network (not the Internet) or plan to do more firewall configuration later. Choose Customize to add trusted devices or to allow additional incoming services.

Trusted Devices

Selecting any of the Trusted Devices allows access to your system for all traffic from that device; it is excluded from the firewall rules. For example, if you are running a local network but are connected to the Internet via a PPP dialup, you can check eth0, and any traffic coming from your local network will be allowed. Selecting eth0 as trusted means all traffic over the Ethernet is allowed, but the ppp0 interface is still firewalled. If you want to restrict traffic on an interface, leave this option unchecked.

Warning

It is not recommended that you make any device that is connected to public networks, such as the Internet, a Trusted Device.

Allow Incoming

Enabling these options allows the specified services to pass through the firewall. Note that during a workstation installation, the majority of these services are not installed on the system.

DHCP

If you allow incoming DHCP queries and replies, you allow any network interface that uses DHCP to determine its IP address. DHCP is normally enabled. If DHCP is not enabled, your computer can no longer get an IP address.

SSH

SSH (Secure SHell) is a suite of tools for logging in to and executing commands on a remote machine. If you plan to use SSH tools to access your machine through a firewall, enable this option. You need to have the openssh-server package installed in order to access your machine remotely, using SSH tools.

Telnet

Telnet is a protocol for logging in to remote machines. Telnet communications are unencrypted and provide no security from network snooping. Allowing incoming Telnet access is not recommended. If you do want to allow inbound Telnet access, you need to install the telnet-server package.

WWW (HTTP)

The HTTP protocol is used by Apache (and by other Web servers) to serve Web pages. If you plan on making your Web server publicly available, enable this option. This option is not required for viewing pages locally or for developing Web pages. You will need to install the apache package if you want to serve Web pages. Enabling WWW (HTTP) will not open a port for HTTPS. To enable HTTPS, specify it in the Other ports field.

Mail (SMTP)

If you want to allow incoming mail delivery through your firewall so that remote hosts can connect directly to your machine to deliver mail, enable this option. You do not need to enable this if you collect your mail from your ISP’s server using POP3 or IMAP, or if you use a tool such as Fetchmail. Note that an improperly configured SMTP server can allow remote machines to use your server to send spam.

FTP

The FTP protocol is used to transfer files between machines on a network. If you plan on making your FTP server publicly available, enable this option. You need to install the wu-ftpd package (and possibly the anonftp package) for this option to be useful.

Other ports

You can allow access to ports that are not listed here by listing them in the Other ports field. Use the following format: port:protocol. For example, if you want to allow IMAP access through your firewall, specify imap:tcp. You can also explicitly specify numeric ports; to allow UDP packets on port 1234 through the firewall, enter 1234:udp. To specify multiple ports, separate them with commas. You must have the iptables service enabled and running to activate the security level. Refer to the section “Activating the iptables Service” later in this chapter for details.


GNOME Lokkit

GNOME Lokkit allows you to configure firewall settings for an average user by constructing basic iptables networking rules. Instead of your having to write a rule, this program asks you a series of questions about how you use your system and then writes it for you in the file /etc/sysconfig/iptables.

You should not try to use GNOME Lokkit to generate complex firewall rules. It is intended for average users who want to protect themselves while using a modem, cable, or DSL Internet connection. To disable specific services and deny specific hosts and users, refer to Chapter 21.

To start GNOME Lokkit, type gnome-lokkit at a shell prompt as root. If you do not have the X Window System installed or if you prefer a text-based program, use the command lokkit to start the text-mode version of GNOME Lokkit.

Basic

After starting the program, choose the appropriate security level for your system:

  • High Security — This option disables almost all network connections except DNS replies and DHCP so that network interfaces can be activated. IRC, ICQ, and other instant messaging services as well as RealAudio will not work without a proxy.

  • Low Security — This option will not allow remote connections to the system, including NFS connections and remote X Window System sessions. Services that run below port 1023 will not accept connections, including FTP, SSH, Telnet, and HTTP.

  • Disable Firewall — This option does not create any security rules. It is recommended that this option be chosen only if the system is on a trusted network (not on the Internet), if the system is behind a larger firewall, or if you write your own custom firewall rules. If you choose this option and click Next, proceed to the “Activating the iptables Service” section. The security of your system will not be changed.

    Click To expand
    Figure 22-2: Basic

Local Hosts

If there are Ethernet devices on the system, the Local Hosts page allows you to configure whether the firewall rules apply to connection requests sent to each device. If the device connects the system to a local area network behind a firewall and does not connect directly to the Internet, select Yes. If the Ethernet card connects the system to a cable or DSL modem, it is recommended that you select No.

Click To expand
Figure 22-3: Local Hosts

DHCP

If you are using DHCP to activate any Ethernet interfaces on the system, you must answer Yes to the DHCP question. If you answer no, you will not be able to establish a connection using the Ethernet interface. Many cable and DSL Internet providers require you to use DHCP to establish an Internet connection.

Click To expand
Figure 22-4: DHCP

Configuring Services

GNOME Lokkit also allows you to turn common services on and off. If you answer Yes to configuring services, you are prompted about the following options:

  • Web Server — Choose this option if you want people to connect to a Web server such as Apache running on your system. You do not need to choose this option if you want to view pages on your own system or on other servers on the network.

  • Incoming Mail — Choose this option if your system needs to accept incoming mail. You do not need this option if you retrieve email using IMAP, POP3, or Fetchmail.

  • Secure Shell — Secure Shell, or SSH, is a suite of tools for logging in to and executing commands on a remote machine over an encrypted connection. If you need to access your machine remotely through ssh, select this option.

  • Telnet — Telnet allows you to log in to your machine remotely; however, it is not secure. It sends plain text (including passwords) over the network. It is recommended that you use SSH to log into your machine remotely. If you are required to have Telnet access to your system, select this option.

    Cross-Reference

    To disable other services that you do not need, use Serviceconf, ntsysv, or chkconfig. See Chapter 21 for all three options.

Activating the Firewall

Clicking Finish will write the firewall rules to /etc/sysconfig/iptables and start the firewall by starting the iptables service. It is highly recommended that you run GNOME Lokkit from the machine, not from a remote X session. If you disable remote access to your system, you will no longer be able to access it or disable the firewall rules. Click Cancel if you do not want to write the firewall rules.

Mail Relay

A mail relay is a system that allows other systems to send email through it. If your system is a mail relay, someone can possibly use it to spam others from your machine. If you chose to enable mail services, after you click Finish on the Activate the Firewall page, you will be prompted to check for mail relay. If you choose Yes to check for mail relay, GNOME Lokkit will attempt to connect to the Mail Abuse Prevention System website at http://www.mail-abuse.org/ and run a mail relay test program. The results of the test will be displayed when it is finished. If your system is open to mail relay, it is highly recommended that you configure Sendmail (or any other mail transfer agent you’re running) to prevent it. You must have the iptables service enabled and running to activate the firewall. Refer to the “Activating the iptables Service” section of this chapter for details.


Activating the iptables Service

The firewall rules will be active only if the iptables service is running. To manually start the service, use the command

/sbin/service iptables restart

To ensure that it is started when the system is booted, issue the command

/sbin/chkconfig --level 345 iptables on

You can also use Serviceconf to activate iptables. See Chapter 21. You cannot run the ipchains service along with the iptables service. To make sure the ipchains service is disabled, execute the command

/sbin/chkconfig --level 345 ipchains off


Firewalls and iptables

Linux comes with advanced tools for packet filtering — the process of controlling network packets as they enter, move through, and exit the network stack within the kernel. Pre-2.4 kernels relied on ipchains for packet filtering and used lists of rules applied to packets at each step of the filtering process. The introduction of the 2.4 kernel brought with it iptables (also called netfilter), which is similar to ipchains but greatly expands on the scope and control available for filtering network packets.

This chapter focuses on packet filtering basics, defines the differences between ipchains and iptables, explains various options available with iptables commands, and shows how filtering rules can be preserved between system reboots. If you require instructions for constructing iptables rules or setting up a firewall based on these rules, please see the “Additional Resources” section for more information.

Warning

The default firewall mechanism under the 2.4 kernel is iptables, but iptables cannot be used if ipchains is already running. If ipchains is present at boot time, the kernel will issue an error and fail to start iptables. The functionality of ipchains is not affected by these errors.


Packet Filtering

Traffic moves through a network in packets. A network packet is collection of data in a specific size and format. In order to transmit a file over a network, the sending computer must first break the file into packets using the rules of the network protocol. Each of these packets holds a small part of the file data. Upon receiving the transmission, the destination computer reassembles the packets into the file.

Every packet contains information that helps it navigate the network and move towards its destination. The packet can tell computers along the way, as well as the destination machine, where it came from, where it is going, and what type of packet it is, among other things. Most packets are designed to carry data, although some protocols use packets in special ways. For example, the Transmission Control Protocol (TCP) uses a SYN packet, which contains no data, to initiate communication between two systems.

The Linux kernel contains the built-in ability to filter packets, allowing some of them into the system while stopping others. The 2.4 kernel’s netfilter has three built-in tables or rules lists. They are as follows:

  • filter — This is the default table for handling network packets.

  • nat — This table is used to alter packets that create a new connection.

  • mangle — This table is used for specific types of packet alteration.

Each of these tables in turn has a group of built-in chains that correspond to the actions performed on the packet by the netfilter. The built-in chains for the filter table are as follows:

  • INPUT — This chain applies to packets received via a network interface.

  • OUTPUT — This chain applies to packets sent out via the same network interface that received the packets.

  • FORWARD — This chain applies to packets received on one network interface and sent out on another.

The built-in chains for the nat table are as follows:

  • PREROUTING — This chain alters packets received via a network interface when they arrive.

  • OUTPUT — This chain alters locally generated packets before they are routed via a network interface.

  • POSTROUTING — This chain alters packets before they are sent out via a network interface.

The built-in chains for the mangle table are as follows:

  • PREROUTING — This chain alters packets received via a network interface before they are routed.

  • OUTPUT — This chain alters locally generated packets before they are routed via a network interface.

Every network packet received by or sent out of a Linux system is subject to at least one table. A packet may be checked against multiple rules within each rules list before emerging at the end of the chain. The structure and purpose of these rules may vary, but they usually seek to identify a packet coming from or going to a particular IP address or set of addresses when using a particular protocol and network service.

Regardless of their destination, packets that match a particular rule on one of the tables are designated for a particular target or action to be applied to them. If the rule specifies an ACCEPT target for a matching packet, the packet skips the rest of the rule checks and is allowed to continue to its destination. If a rule specifies a DROP target, that packet is refused access to the system, and nothing is sent back to the host that sent the packet. If a rule specifies a REJECT target, the packet is dropped, but an error packet is sent to the packet’s originator.

Every chain has a default policy to ACCEPT, DROP, REJECT, or QUEUE the packet to be passed to user-space. If none of the rules in the chain apply to the packet, then the packet is dealt with in accordance with the default policy. The iptables command allows you to configure these rule lists, as well as set up new tables to be used for your particular situation.


Differences between iptables and ipchains

At first glance, ipchains and iptables appear to be quite similar. Both methods of packet filtering use chains of rules operating within the Linux kernel to decide not only which packets to let in or out but also what to do with packets that match certain rules. However, iptables offers a much more extensive way of filtering packets, giving the administrator a greater amount of control without building too much complexity into the entire system.

Specifically, users comfortable with ipchains should be aware of the following significant differences between ipchains and iptables before attempting to use iptables:

  • Under iptables, each filtered packet is processed using rules from only one chain rather than from multiple chains. For instance, a FORWARD packet coming into a system using ipchains would have to go through the INPUT, FORWARD, and OUTPUT chains in order to move along to its destination. However, iptables sends packets to the INPUT chain only if they are destined for the local system and sends them to the OUTPUT chain only if the local system generated the packets. For this reason, you must be sure to place the rule designed to catch a particular packet in the rule that will actually see the packet. The advantage is that you now have more control over the disposition of each packet. If you are attempting to block access to a particular website, it is now possible to block access attempts from clients running on hosts that use your host as a gateway. An OUTPUT rule that denies access will no longer prevent access for hosts that use your host as a gateway.

  • The DENY target has been changed to DROP. In ipchains, packets that matched a rule in a chain could be directed to the DENY target, which silently dropped the packet. This target must be changed to DROP in iptables to have the same effect.

  • Sequence matters when placing options in a rule. Previously, with ipchains, how you ordered the rule options did not matter very much. The iptables command is a bit pickier about where some options may go. For example, you must now specify the source or destination port after the protocol (ICMP, TCP, or UDP) to be used in a rule.

  • When specifying network interfaces to be used with a rule, you must use incoming interfaces (-i option) only with INPUT or FORWARD chains and outgoing interfaces (-o option) only with FORWARD or OUTPUT chains. This is necessary because OUTPUT chains are no longer used by incoming interfaces, and INPUT chains are not seen by packets moving through outgoing interfaces.

This is by no means a comprehensive list of the changes, given that iptables represents a fundamentally rewritten network filter. For more specific information, consult the Linux 2.4 Packet Filtering HOWTO and the “Additional Resources” section at the end of this chapter.


Options Used in iptables Commands

Rules that allow packets to be filtered by the kernel are put in place by running the iptables command. When using the iptables command, you must specify the following options:

  • Packet Type — This dictates what type of packets the command filters.

  • Packet Source or Destination — This dictates what packets the command filters based on the source or destination of the packet.

  • Target — This dictates what action is taken on packets matching the above criteria.

The options used with a given iptables rule must be grouped logically, based on the purpose and conditions of the overall rule, in order for the rule to be valid.

Tables

A powerful aspect of iptables is that multiple tables can be used to decide the fate of a particular packet, depending upon the type of packet being monitored and what is to be done with the packet. Thanks to the extendable nature of iptables, specialized tables can be created and stored in the /etc/modules/ kernel-version /kernel/net/ipv4/netfilter/ directory to meet specific goals. Think of iptables as being able to run multiple sets of ipchains rules in defined chains, with each set fulfilling a particular role.

The default table, named filter, contains the standard built-in INPUT, OUTPUT, and FORWARD chains. This is somewhat similar to the standard chains in use with ipchains. However, by default, iptables also includes two additional tables that perform specific packet filtering jobs. The nat table can be used to modify the source and destination addresses recorded in packets, and the mangle table allows you to alter packets in specialized ways. Each table contains default chains that perform necessary tasks based on the purpose of the table, but you can easily set up new chains in each of the tables.

Structure

Many iptables commands have the following structure:

iptables [-t table-name ] command chain-name parameter-1 \
  option-1 parameter-n option-n

In this example, the table-name option allows the user to select a table other than the default filter table to use with the command. The command option is the center of the command, dictating a specific action to perform, such as appending a rule to or deleting a rule from a particular chain, which is specified by the chain-name option. Following the chain-name are pairs of parameters and options that actually define the way the rule will work and what will happen when a packet matches the rule.

When looking at the structure of an iptables command, it is important to remember that, unlike most other commands, the length and complexity of an iptables command can change based on its purpose. A simple command to remove a rule from a chain can be very short, while a command designed to filter packets from a particular subnet using a variety of specific parameters and options can be rather lengthy. When creating iptables commands, it is helpful to recognize that some parameters and options may create the need for other parameters and options to further specify the previous option’s request. In order to construct a valid rule, this must continue until every parameter and option that requires another set of options is satisfied. Type iptables -h to see a comprehensive list of iptables command structures.

Commands

Commands tell iptables to perform a specific action. Only one command is allowed per iptables command string. With the exception of the help command, all commands are written in uppercase characters. The iptables commands are as follows:

  • -A — Appends the iptables rule to the end of the specified chain. This is the command used to simply add a rule when rule order in the chain does not matter.

  • -C — Checks a particular rule before adding it to the user-specified chain. This command can help you construct complicated iptables rules by prompting you for additional parameters and options.

  • -D — Deletes a rule in a particular chain by number (such as 5 for the fifth rule in a chain). You can also type the entire rule, and iptables will delete the rule in the chain that matches it.

  • -E — Renames a user-defined chain. This does not affect the structure of the table. Rather, it just saves you the trouble of deleting the chain, creating it under the new name, and reconfiguring all of your rules for that chain.

  • -F — Flushes the selected chain, which effectively deletes every rule in the the chain. If no chain is specified, this command flushes every rule from every chain.

  • -h — Provides a list of helpful command structures, as well as a quick summary of command parameters and options.

  • -I — Inserts a rule in a chain at a particular point. Assign a number to the rule to be inserted, and iptables will put it there. If no number is specified, iptables will place your command at the top of the rule list.

    Warning

    Be aware of which option (-A or -I) you are using when adding a rule. The order of the rules can be very important when determining if a particular packet applies to one rule or another. Make sure when adding a rule to the beginning or end of the chain that it does not affect other rules in that chain.

  • -L — Lists all of the rules in the chain specified after the command. To list all rules in all chains in the default filter table, do not specify a chain or table. Otherwise, the following syntax should be used to list the rules in a specific chain in a particular table:

    iptables -L chain-name -t table-name

  • Powerful options for the -L command that provide rule numbers and allow more verbose rule descriptions, among others, are described in the “Listing Options” section.

    • -N — Creates a new chain with a user-specified name.

    • -P — Sets the default policy for a particular chain, so that when packets traverse an entire chain without matching a rule, they will be sent on to a particular target, such as ACCEPT or DROP.

    • -R — Replaces a rule in a particular chain. You must use a rule’s number after the chain’s name to replace that rule. The first rule in a chain corresponds to rule number 1.

    • -X — Deletes a user-specified chain. Deleting a built-in chain for any table is not allowed.

    • -Z — Zeroes the byte and packet counters in all chains for a particular table.

Parameters

Once certain iptables commands are specified, including those used to add, append, delete, insert, or replace rules within a particular chain, parameters are required to begin the construction of the packet filtering rule.

  • -c — Resets the counters for a particular rule. This parameter accepts the PKTS and BYTES options to specify what counter to reset.

  • -d — Sets the destination hostname, IP address, or network of a packet that will match the rule. When matching a network, you can use two different methods for signifying the netmask, such as 192.168.0.0/255.255.255.0 or 192.168.0.0/24.

  • -f — Applies this rule only to fragmented packets. If the ! option is used after this parameter, only unfragmented packets will be matched.

  • -i — Sets the incoming network interface, such as eth0 or ppp0, to use with a particular rule. With iptables, this optional parameter may be used only with the INPUT and FORWARD chains when used with the filter table, and the PREROUTING chain with the nat and mangle tables. This parameter features several useful options that may be used before specifying the name of an interface:

    • ! — Tells this parameter not to match, meaning that any specified interfaces are specifically excluded from this rule.

    • + — A wildcard character used to match all interfaces that match a particular string. For example, the parameter -i eth+ would apply this rule to any Ethernet interfaces on your system but exclude any other interfaces, such as ppp0. If the -i parameter is used but no interface is specified, then every interface is affected by the rule.

  • -j — Tells iptables to jump to a particular target when a packet matches a particular rule. Valid targets to be used after the -j option include the standard options, ACCEPT, DROP, QUEUE, and RETURN, as well as extended options that are available through modules loaded by default with the Red Hat Linux iptables RPM package, such as LOG, MARK, and REJECT, among others. See the iptables man page for more information on these and other targets, including rules regarding their use. You may also direct a packet matching this rule to a user-defined chain outside of the current chain. This allows you to apply other rules against this packet, further filtering it with more specific criteria. If no target is specified, the packet moves past the rule with no action taken. However, the counter for this rule is still increased by one, as the packet matched the specified rule.

  • -o — Sets the outgoing network interface for a particular rule, and may only be used only with OUTPUT and FORWARD chains in the filter table and the POSTROUTING chain in the nat and mangle tables. This parameter’s options are the same as those of the incoming network interface parameter (-i).

  • -p — Sets the IP protocol for the rule, which can be either icmp, tcp, udp, or all, to match every supported protocol. In addition, lesser-used protocols listed in /etc/protocols may also be used. If this option is omitted when creating a rule, the all option is the default.

  • -s — Sets the source for a particular packet, using the same syntax as the destination (-d) parameter.

Match Options

Different network protocols provide specialized matching options that may be set in specific ways to match a particular packet using that protocol. Of course, the protocol must first be specified in the iptables command, such as using -p tcp protocol-name, to make the options for that protocol available.

TCP Protocol

These match options are available for the TCP protocol (-p tcp):

  • --dport — Sets the destination port for the packet. You can use either a network service name (such as www or smtp), port number, or range of port numbers to configure this option. To browse the names and aliases of network services and the port numbers they use, view the /etc/services file. You can also use --destination-port to specify this match option. To specify a specific range of port numbers, separate the two numbers with a colon (:), such as -p tcp --dport 3000:3200. The largest valid range is 0:65535. You may also use an exclamation point character (!) as a flag after the --dport option to tell iptables to match all packets that do not use that network service or port.

  • --sport — Sets the source port of the packet, using the same options as --dport. You can also use --source-port to specify this match option.

  • --syn — Applies to all TCP packets designed to initiate communication, commonly called SYN packets. Any packets that carry a data payload are not touched. Placing an exclamation point character (!) as a flag after the --syn option causes all non-SYN packets to be matched.

  • --tcp-flags — Allows TCP packets with specific bits, or flags, set to be matched with a rule. The --tcp-flags match option accepts two parameters after it, which are flags for the various bits arranged in a comma-separated list. The first parameter is the mask, which sets the flags to be examined on the packet. The second parameter refers to the flags that must be set in the packet to make a match. The possible flags are ACK, FIN, PSH, RST, SYN, and URG. In addition, ALL and NONE can also be used to match every flag or none of them. For example, an iptables rule that contains -p tcp --tcp-flags ACK,FIN,SYN SYN will match only TCP packets that have the SYN flag set and the ACK and FIN flags unset. As with many other options, using the exclamation point character (!) after --tcp-flags reverses the effect of the match option, so that the second parameter’s flags must not be set in order to match.

  • --tcp-option — Attempts to match with TCP-specific options that can be set within a particular packet. This match option can also be reversed with the exclamation point character (!).

UDP Protocol

These match options are available for the UDP protocol (-p udp):

  • --dport — Specifies the destination port of the UDP packet, using the service name, port number, or range of port numbers. The --destination-port match option may be used instead of --dport. See the --dport match option in the “TCP Protocol” section for various ways to use this option.

  • --sport — Specifies the source port of the UDP packet, using the service name, port number, or range of port numbers. The --source-port match option may be used instead of --sport. See the --dport match option in the “TCP Protocol” section for various ways to use this option.

ICMP Protocol

Packets using the Internet Control Message Protocol (ICMP) can be matched using the following option when -p icmp is specified:

  • --icmp-type — Sets the name or number of the ICMP type to match with the rule. A list of valid ICMP names can be seen by typing the iptables -p icmp -h command.

Modules with Additional Match Options

Additional match options are also available through modules loaded when the iptables command calls them. To use a match option module, you must load the module by name by including -m n module-name in the iptables command.

A large number of modules are available by default. It is even possible to create your own modules to provide additional match option functionality. Many modules exist, but only the most popular ones are discussed here.

The limit module allows you to place a limit on how many packets will be matched to a particular rule. This is especially beneficial when logging rule matches so that a flood of matching packets will not fill up your logs with repetitive messages or use too many system resources.

  • --limit — Sets the number of matches for a particular range of time, specified with a number and time modifier arranged in a number / time format. For example, using --limit 5/hour lets a rule match only five times in a single hour. If a number and time modifier are not used, the default value of 3/hour is assumed.

  • --limit-burst — Sets a limit on the number of packets able to match a rule at one time. This option should be used in conjunction with the --limit option, and it accepts a number to set the burst threshold. If no number is specified, only five packets are initially able to match the rule.

The state module, which uses the --state match option, can match a packet with these particular connection states:

  • ESTABLISHED — The matching packet is associated with other packets in an established connection.

  • INVALID — The matching packet cannot be tied to a known connection.

  • NEW — The matching packet is either creating a new connection or is part of a two-way connection not previously seen.

  • RELATED — The matching packet is starting a new connection related in some way to an existing connection.

These connection states can be used in combination with one another by separating them with commas, such as -m state --state INVALID,NEW. To specifically match a hardware MAC address of an Ethernet device, use the mac module, which accepts --mac-source plus a MAC address as an option. To exclude a MAC address from a rule, place an exclamation point (!) after the --mac-source match option. To view other match options available through modules, see the iptables man page.

Target Options

Once a packet has matched a particular rule, the rule can direct the packet to a number of different targets that decide its fate and, possibly, take additional actions, such as logging the action. Additionally, each chain has a default target, which is used if none of the rules on that chain match a packet or if none of the rules that match the packet specify a target. Only a few standard targets are available to decide what happens with the packet:

  • user-defined-chain — The name of a previously created and defined chain within this table with rules that will be checked against this packet, in addition to any other rules in any other chains that must be checked against this packet.

  • ACCEPT — Allows the packet to successfully move on to its destination or another chain.

  • DROP — Drops the packet without responding to the requester. The system that sent the packet is not notified of the failure. The packet is simply removed from the rule that is checking the chain and discarded.

  • QUEUE — The packet is queued for handling by a user-space application.

  • RETURN — Stops checking the packet against rules in the current chain. If the packet with a RETURN target matches a rule in a chain called from another chain, the packet is returned to the first chain to resume rule checking where it left off. If the RETURN rule is used on a built-in chain and the packet cannot move up to its previous chain, the default target for the current chain decides what action to take.

In addition to these standard targets, various other targets may be used with extensions called target modules. For more information about match option modules, see the section “Modules with Additional Match Options.” There are many extended target modules, most of which apply only to specific tables or situations. A couple of the most popular target modules included by default in Red Hat Linux are:

  • LOG — Logs all packets that match this rule. Since the packets are logged by the kernel, the /etc/syslog.conf file determines where these log entries are written. By default, they are placed in the /var/log/messages file. Various options can be used after the LOG target to specify the way in which logging occurs:

    • --log-level — Sets the priority level of a logging event. A list of priority levels can be found in the syslog.conf man page.

    • --log-ip-options — Any options set in the header of a IP packet are logged.

    • --log-prefix — Places a string before the log line when it is written. Accepts up to 29 characters after the --log-prefix option. This is useful for writing syslog filters for use in conjunction with packet logging.

    • --log-tcp-options — Any options set in the header of a TCP packet are logged.

    • --log-tcp-sequence — Writes the TCP sequence number for the packet in the log.

  • REJECT — Sends an error packet back to the system that sent the packet, and then drops the packet. This target is useful if you would like to notify the system sending the matching packet of the problem. The REJECT target accepts a --reject-with type option, which allows more detailed information to be sent with the error packet. The message port-unreachable is the default type error given if no other option is used. For a full list of type options that can be used, see the iptables man page.

Other target extensions, including several that are useful with masquerading using the nat table or with packet alteration using the mangle table, can be found in the iptables man page.

Listing Options

The default list command, iptables -L, provides a very basic overview of the default filter table’s current chains. Additional options provide more information and arrange that information in specific ways:

  • -v — Displays verbose output, such as the number of packets and bytes each chain has seen, the number of packets and bytes each rule has matched, and which interfaces apply to a particular rule.

  • -x — Expands numbers into their exact values. On a busy system, the number of packets and bytes seen by a particular chain or rule may be abbreviated using K (thousands), M (millions), and G (billions) at the end of the number. This option forces the full number to be displayed.

  • -n — Displays IP addresses and port numbers in numeric format, rather than in the default hostname and network service format.

  • --line-numbers — Lists rules in each chain next to their numeric order in the chain. This option is useful when attempting to delete a specific rule in a chain, or to locate where to insert a rule within a chain.


Storing iptables Information

Rules created with the iptables command are stored in RAM only. If you restart your system after setting up iptables rules, they will be lost. So in order for netfilter rules to persist through system reboot, you need to save them to the /etc/sysconfig/iptables file.

To do this, type the /sbin/service iptables save command as the root user. This causes the iptables init script to run the /sbin/iptables-save program and write the current iptables configuration to the /etc/sysconfig/iptables file. This file should be readable by root only, so that your packet filtering rules are not viewable by average users. The next time the system boots, the iptables init script will reapply the rules saved in /etc/sysconfig/iptables by using the /sbin/iptables-restore command.

While it is always a good idea to test a new iptables rule before committing it to the /etc/sysconfig/iptables file, it is possible to copy iptables rules into this file from another system’s version of this file. This allows you to quickly distribute sets of iptables rules to many different machines.

Note

If you distribute the /etc/sysconfig/iptables file to other machines, you must type /sbin/service iptables restart for the new rules take effect.


Additional Resources

See the sources below for additional information on packet filtering with iptables.

Installed Documentation

The iptables man page contains a comprehensive description of various commands, parameters, and other options.

Useful Websites

  • http://netfilter.samba.org — Contains assorted information about iptables, including a FAQ addressing specific problems you may experience and various helpful guides by Rusty Russell, the Linux IP firewall maintainer. The HOWTO documents here cover subjects such as basic networking concepts, 2.4 kernel packet filtering, and NAT configurations.

  • http://www.linuxnewbie.org/nhf/Security/IPtables_Basics.html — A basic and general look at the way packets move through the Linux kernel, plus an introduction to constructing simple iptables commands.

  • http://www.redhat.com/support/resources/networking/firewall.html — This Web page contains up-to-date links to a variety of packet filter resources.

Related Book:

  • Red Hat Linux Firewalls by Bill McCarty (Red Hat Press/Wiley, 2003)


Chapter 23: Kerberos

Kerberos is a network authentication protocol created by the Massachusetts Institute of Technology that uses secret-key cryptography — obviating the need to send passwords over the network. By authenticating using Kerberos, unauthorized users trying to intercept passwords on the network are effectively thwarted.

Advantages of Kerberos

Most conventional network systems use password-based authentication schemes. A user who authenticates to a network server must supply a user name and password for each service requiring authentication. This information is sent over the network, and the server verifies the user’s identity using this information. However, the transmission of authentication information for many services is in plaintext. An attacker with access to the network and a packet analyzer, also known as a packet sniffer, can intercept any passwords sent in this manner. The primary design goal of Kerberos is to eliminate the transmission across the network of authentication information. The proper use of Kerberos effectively eliminates the threat packet sniffers would otherwise pose on a network.


Disadvantages of Kerberos

Although Kerberos removes a common and severe security threat, it may be difficult to implement for various reasons:

  • Migrating user passwords from a standard UNIX password database, such as /etc/passwd or /etc/shadow, to a Kerberos password database can be tedious as there is no automated mechanism to perform this task. For more information, refer to the Kerberos FAQ at http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html.

  • Kerberos has only partial compatibility with the Pluggable Authentication Modules (PAM) system used by most servers running Red Hat Linux. For more information on this issue, see the “Kerberos and PAM” section of this chapter.

  • In order for an application to use Kerberos, its source must be modified to make the appropriate calls to the Kerberos libraries. For some applications, this can be quite problematic because of the size of the Kerberos libraries, or the frequency with which they must be called. For other applications, changes must be made to the way in which the server and client side communicate. Again, this may require extensive programming. Closed-source applications that do not have Kerberos support by default are often the most problematic.

  • Kerberos assumes that you are using trusted hosts on an untrusted network. Its primary goal is to prevent plaintext passwords from being sent across that network. However, if anyone other than the proper user has physical access to any of the hosts, especially the one that issues tickets used for authentication, the entire Kerberos authentication system is at risk of being compromised.

  • Kerberos is an all-or-nothing solution. If you decide to use Kerberos on your network, you must remember any passwords transferred to a service that does not use Kerberos for authentication or run the risk of being captured by packet sniffers. Thus, your network gains no benefit from the use of Kerberos. To secure your network with Kerberos, you must either kerberize all applications that send plaintext passwords or not use those applications on your network at all.


Kerberos Terminology

Like any other system, Kerberos has its own terminology to define various aspects of the service. Before learning how the service works, it is important to learn the following terms.

ciphertext

Encrypted data.

plain text

Unencrypted, human-readable data.

client

An entity on the network (a user, a host, or an application) that can get a ticket from Kerberos.

credential cache or ticket file

A file that contains the keys for encrypting communications between a user and various network services. Kerberos 5 supports a framework for using other cache types, such as shared memory, but files are more thoroughly supported.

crypt hash

A one-way hash used to authenticate users. While more secure than plaintext, it is fairly easy for an experienced cracker to decrypt.

key

Data used when encrypting or decrypting other data. Encrypted data cannot be decrypted without the proper key or extremely good guessing.

Key Distribution Center (KDC)

A service that issues Kerberos tickets, usually run on the same host as the Ticket Granting Server.

key table or keytab

A file that includes an unencrypted list of principals and their keys. Servers retrieve the keys they need from keytab files instead of using kinit. The default keytab file is /etc/krb5.keytab. The /usr/kerberos/sbin/kadmind command is the only service that uses any other file (it uses /var/kerberos/krb5kdc/kadm5.keytab).

principal

A user or service that can authenticate using Kerberos. A principal’s name is in the form root[/instance]@REALM. For a typical user, the root is the same as his or her login ID. The instance is optional. If the principal has an instance, it is separated from the root with a forward slash (/). An empty string ("") is considered a valid instance (which differs from the default NULL instance), but using it can be confusing. All principals in a realm have their own key, which is derived from their password or randomly set for services.

realm

A network that uses Kerberos, composed of one or more servers called KDCs and a potentially large number of clients.

service

A program accessed over the network.

ticket

A temporary set of electronic credentials that verify the identity of a client for a particular service.

Ticket Granting Service (TGS)

A server that issues tickets for a desired service which are in turn given to users for access to the service. The TGS usually runs on the same host as the KDC.

Ticket Granting Ticket (TGT)

A special ticket that allows the client to obtain additional tickets without applying for them from the KDC.


How Kerberos Works

Now that the Kerberos terminology has been defined, the following is an overview of how the Kerberos authentication system works. Rather than authentication occurring between each client machine and each server, Kerberos uses symmetric encryption and a trusted third party — known as the Key Distribution Center or KDC — to authenticate users on a network to a suite of services on a network. Once authenticated, Kerberos stores a ticket specific to that session on the user’s machine, and any kerberized service will look for this ticket rather than ask the user to authenticate using a password.

When users on a kerberized network log in to their workstation, their principal is sent to the Key Distribution Center as a request for a Ticket Granting Ticket (TGT). This request can be sent by the login program so that it is transparent to the user or can be sent by the kinit program after the user logs in. The KDC checks for the principal in its database. If the principal is found, the KDC creates a TGT, encrypts it using the user’s key and sends it back to the user.

The login program on the client machine or kinit decrypts the TGT using the user’s key (which it computes from the user’s password). The TGT is set to expire after a certain period of time and stored in the client machine’s credentials cache. The expiration time is set so a compromised TGT can be used for only a certain period of time (usually eight hours). This is safer than the traditional password model because the password is never passed over the network. Once the TGT is issued, users will not have to re-enter their passwords to the KDC until the TGT expires or they log out and log in again. When users need access to a network service, the client uses the TGT to request a ticket for the service from the Ticket Granting Service (TGS), which runs on the KDC. The TGS issues a ticket for the desired service, which is then used to authenticate the user.

Warning

The Kerberos system can be compromised any time any user on the network authenticates against a non-kerberized service by sending a password in plaintext. Therefore, use of non-kerberized services should be discouraged. Such services include telnet and ftp. Use of other secure protocols, such as SSH or SSL-secured services, however, is acceptable.

This, of course, is a broad overview of how Kerberos authentication on a network would typically work. For a more in-depth look at Kerberos authentication, refer to the sources listed in the “Additional Resources” section of this chapter.

Note

Kerberos depends on certain network services’ working correctly. First, Kerberos requires approximate clock synchronization between the machines on the network. Therefore, a clock synchronization program should be set up for the network, such as ntpd. Also, since certain aspects of Kerberos rely on the Domain Name Service (DNS), be sure that the DNS entries and hosts on the network are all properly configured. See the Kerberos V5 System Administrator’s Guide, provided in PostScript and HTML formats in /usr/share/doc/krb5-server-version-number (where version-number is the version installed on the system) for more information.


Kerberos and PAM

Currently, kerberized services do not make use of Pluggable Authentication Modules (PAM) — kerberized servers bypass PAM completely. However, applications that use PAM can make use of Kerberos for authentication if the pam_krb5 module (provided in the pam_krb5 package) is installed. The pam_krb5 package contains sample configuration files that allow services like login and gdm to authenticate users and obtain initial credentials using their passwords. If access to network servers is always done using kerberized services or services that use GSS-API, like IMAP, the network can be considered reasonably safe.

Careful administrators will not add Kerberos password checking to all network services because most of the protocols used by these services do not encrypt the password before sending it over the network. The next section describes how to set up a basic Kerberos server.


Configuring a Kerberos 5 Server

When you are setting up Kerberos, install the server first. If you need to set up slave servers, note that the details of setting up relationships between master and slave servers are covered in the Kerberos 5 Installation Guide located in the /usr/share/doc/krb5-server-version-number directory.

To configure a basic Kerberos server, follow these steps:

  1. Be sure that you have clock synchronization and DNS working on your server before configuring Kerberos 5. Pay particular attention to time synchronization between the Kerberos server and its various clients. If the server and client clocks are different by more than five minutes (this default amount is configurable in Kerberos 5), Kerberos clients will not be able to authenticate to the server. This clock synchronization is necessary to prevent an attacker from using an old Kerberos ticket to masquerade as a valid user.

  2. You should set up a Network Time Protocol (NTP) compatible client/server network, even if you are not using Kerberos. Red Hat Linux 8.0 includes the NTP package for easy installation. See http://www.eecis.udel.edu/~ntp for additional information on NTP.

  3. Install the krb5-libs, krb5-server, and krb5-workstation packages on the dedicated machine that will run your KDC. This machine needs to be very secure — if possible, it should not run any services other than the KDC. If you would like to use a graphical user interface utility to administrate Kerberos, you should also install the gnome-kerberos package. It contains krb5, a GUI tool for managing tickets.

  4. Edit the /etc/krb5.conf and /var/kerberos/krb5kdc/kdc.conf configuration files to reflect your realm name and domain-to-realm mappings. A simple realm can be constructed by replacing instances of EXAMPLE.COM and example.com with your domain name — being certain to keep uppercase and lowercase names in the correct format — and by changing the KDC from kerberos.example.com to the name of your Kerberos server. By convention, all realm names are uppercase and all DNS hostnames and domain names are lowercase. For full details on the formats of these files, see their respective man pages.

  5. Create the database using the kdb5_util utility from a shell prompt:

    /usr/kerberos/sbin/kdb5_util create -s

  6. The create command creates the database that will be used to store keys for your Kerberos realm. The -s switch forces creation of a stash file in which the master server key is stored. If no stash file is present from which to read the key, the Kerberos server (krb5kdc) will prompt the user for the master server password (which can be used to regenerate the key) every time it starts.

  7. Edit the /var/kerberos/krb5kdc/kadm5.acl file. This file is used by kadmind to determine which principals have access to the Kerberos database and their level of access. Most organizations will be able to get by with a single line:

    */admin@EXAMPLE.COM        *

  8. Most users will be represented in the database by a single principal (with a NULL, or empty, instance, such as joe@EXAMPLE.COM). With this configuration, users with a second principal with an instance of admin (for example, joe/admin@EXAMPLE.COM) will be able to wield full power over the realm’s Kerberos database.

  9. Once kadmind is started on the server, any user will be able to access its services by running kadmin on any of the clients or servers in the realm. However, only users listed in the kadm5.acl file will be able to modify the database in any way, except for changing their own passwords.

    Note

    The kadmin utility communicates with the kadmind server over the network, and they use Kerberos to handle authentication. Of course, you need to create the first principal before you can connect to the server over the network to administer it. Create the first principal with the kadmin.local command, which is specifically designed to be used on the same host as the KDC and does not use Kerberos for authentication.

  10. Type the following kadmin.local command at the KDC terminal to create the first principal:

    /usr/kerberos/sbin/kadmin.local -q "addprinc username/admin"

  11. Start Kerberos using the following commands:

    /sbin/service krb5kdc start
/sbin/service kadmin start
/sbin/service krb524 start

  12. Add principals for your users using the addprinc command with kadmin. kadmin and kadmin.local on the master KDC are command-line interfaces to the Kerberos administration system. As such, many commands are available after launching the kadmin program. Please see the kadmin man page for more information.

  13. Verify that your server will issue tickets. First, run kinit to obtain a ticket and store it in a credential cache file. Then use klist to view the list of credentials in your cache and use kdestroy to destroy the cache and the credentials it contains.

    Note

    By default, kinit attempts to authenticate using the login user name of the account you used when you first logged in to your system (not the Kerberos server). If that system user name does not correspond to a principal in the Kerberos database, you will receive an error message. If that happens, supply kinit with the name of your principal as an argument on the command line (kinit principal).

Once you have completed the steps listed above, the Kerberos server should be up and running. Next, we will set up a Kerberos client.


Configuring a Kerberos 5 Client

Setting up a Kerberos 5 client is less involved than setting up a server. At minimum, install the client packages and provide each client with a valid krb5.conf configuration file. Kerberized versions of rsh and rlogin will also require some configuration changes.

  1. Be sure that you have time synchronization in place between the Kerberos client and KDC. See the previous section for more information. In addition, verify that DNS is working properly on the Kerberos client before configuring the Kerberos client programs.

  2. Install the krb5-libs and krb5-workstation packages on all of the client machines. You must supply a version of /etc/krb5.conf for each client; usually this can be the same krb5.conf used by the KDC.

  3. Before a workstation in the realm can allow users to connect using kerberized rsh and rlogin, that workstation will need to have the xinetd package installed and have its own host principal in the Kerberos database. The kshd and klogind server programs will also need access to the keys for their service’s principal.

  4. Using kadmin, add a host principal for the workstation on the KDC. The instance in this case will be the hostname of the workstation. You can use the -randkey option to kadmin’s addprinc command on the KDC to create the principal and assign it a random key:

    addprinc -randkey host/blah.example.com

  5. Now that you have created the principal, you can extract the keys for the workstation by running kadmin on the workstation itself, using the ktadd command within kadmin:

    ktadd -k /etc/krb5.keytab host/blah.example.com

  6. In order to use the kerberized versions of rsh and rlogin, you must enable klogin, eklogin, and kshell.

  7. Other kerberized network services will need to be started. To use kerberized telnet, you must enable krb5-telnet. To provide FTP access, create and extract a key for a principal with a root of ftp, with the instance set to the hostname of the FTP server. Then enable gssftp.

  8. The IMAP server included in the imap package will use GSS-API authentication using Kerberos 5 if it finds the proper key in /etc/krb5.keytab. The root for the principal should be imap. The CVS gserver uses a principal with a root of cvs and is otherwise identical to a pserver.


Additional Resources

For more information on Kerberos, refer to the following resources.

Installed Documentation

  • /usr/share/doc/krb5-server-version-number — The Kerberos V5 Installation Guide and the Kerberos V5 System Administrator’s Guide in PostScript and HTML formats. You must have the krb5-server RPM package installed.

  • /usr/share/doc/krb5-workstation-version-number — The Kerberos V5 UNIX User’s Guide in PostScript and HTML formats. You must have the krb5-workstation RPM package installed.

Useful Websites

  • http://web.mit.edu/kerberos/www — Kerberos: The Network Authentication Protocol Web page from MIT.

  • http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html — The Kerberos Frequently Asked Questions (FAQ).

  • ftp://athena-dist.mit.edu/pub/kerberos/doc/usenix.PS — The PostScript version of Kerberos: An Authentication Service for Open Network Systems by Jennifer G. Steiner, Clifford Neuman, and Jeffrey I. Schiller. This document is the original paper describing Kerberos.

  • http://web.mit.edu/kerberos/www/dialogue.html — Designing an Authentication System: A Dialogue in Four Scenes originally by Bill Bryant in 1988, modified by Theodore Ts’o in 1997. This document is a conversation between two developers who are thinking through the creation of a Kerberos-style authentication system. The conversational style of the discussion make this a good starting place for people who are completely unfamiliar with Kerberos.

  • http://www.ornl.gov/~jar/HowToKerb.html — How to kerberize your site.

  • http://www.networkcomputing.com/netdesign/kerb1.html — Kerberos Network Design Manual, a thorough overview of the Kerberos system.


Chapter 24: OpenSSH

OpenSSH is a free, open-source implementation of the SSH (Secure SHell) protocols. It replaces Telnet, FTP, rlogin, rsh, and rcp with secure, encrypted network connectivity tools. OpenSSH supports versions 1.3, 1.5, and 2 of the SSH protocol. Since OpenSSH version 2.9, the default protocol is version 2, which uses RSA keys as the default.

Why Use OpenSSH?

If you use OpenSSH tools, you are enhancing the security of your machine. All communications using OpenSSH tools, including passwords, are encrypted. Telnet and ftp use plaintext passwords and send all information unencrypted. The information can be intercepted, the passwords can be retrieved, and then your system can be compromised by an unauthorized person logging in to your system using one of the intercepted passwords. The OpenSSH set of utilities should be used whenever possible to avoid these security problems.

Another reason to use OpenSSH is that it automatically forwards the DISPLAY variable to the client machine. In other words, if you are running the X Window System on your local machine and you log in to a remote machine using the ssh command, when you run a program on the remote machine that requires X, it will be displayed on your local machine. This feature is convenient if you prefer graphical system administration tools but do not always have physical access to your server.


Configuring an OpenSSH Server

To run an OpenSSH server, you must first make sure that you have the proper RPM packages installed. The openssh-server package is required and depends on the openssh package. The OpenSSH daemon uses the configuration file /etc/ssh/sshd_config. The default configuration file installed with Red Hat Linux should be sufficient for most purposes. If you want to configure the daemon in ways not provided by the default sshd_config, read the sshd man page for a list of the keywords that can be defined in the configuration file.

To start the OpenSSH service, use the command /sbin/service sshd start. To stop the OpenSSH server, use the command /sbin/service sshd stop. If you want the daemon to start automatically at boot time, refer to Chapter 21 for information on how to manage services.

If you reinstall a Red Hat Linux system, but clients connected to it before any of the OpenSSH tools were reinstalled, the client users will see the following message once the OpenSSH reinstall is complete:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@     WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!                    @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

The reinstalled system creates a new set of identification keys for the system, hence the warning about the RSA host key changing. If you want to keep the host keys generated for the system, back up the /etc/ssh/ssh_host*key* files and restore them after the reinstall. This process retains the system’s identity, and when clients try to connect to the system after the reinstall, they will not receive the warning message.


Configuring an OpenSSH Client

To connect to an OpenSSH server from a client machine, you must have the openssh-clients and openssh packages installed on the client machine.

Using the ssh Command

The ssh command is a secure replacement for the rlogin, rsh, and telnet commands. It allows you to log in to a remote machine as well as execute commands on a remote machine. Logging in to a remote machine with ssh is similar to using telnet. To log in to a remote machine named penguin.example.net, type the following command at a shell prompt:

ssh penguin.example.net

The first time you ssh to a remote machine, you will see a message similar to the following:

The authenticity of host 'penguin.example.net' can't be established. DSA
key fingerprint is 94:68:3a:3a:bc:f3:9a:9b:01:5d:b3:07:38:e2:11:0c.
Are you sure you want to continue connecting (yes/no)?

Type yes to continue. This will add the server to your list of known hosts as seen in the following message:

Warning: Permanently added 'penguin.example.net' (RSA) to the list of known hosts.

Next, you will see a prompt asking for your password for the remote machine. After entering your password, you will be at a shell prompt for the remote machine. If you do not specify a username, the username that you are logged in as on the local client machine is passed to the remote machine. If you want to specify a different username, use the following command:

ssh username@penguin.example.net

You can also use the syntax ssh -l username penguin.example.net.

The ssh command can be used to execute a command on the remote machine without your having to log in and obtain a shell prompt. The syntax is ssh hostname command. For example, if you want to execute the command ls /usr/share/doc on the remote machine penguin.example.net, type the following command at a shell prompt:

ssh penguin.example.net ls /usr/share/doc

After you enter the correct password, the contents of /usr/share/doc will be displayed, and you will return to your shell prompt.

Using the scp Command

The scp command can be used to transfer files between machines over a secure, encrypted connection. It is similar to rcp. The general syntax to transfer a local file to a remote system is as follows:

scp localfile username@tohostname:/newfilename

The localfile specifies the source, and username@tohostname:/newfilename specifies the destination.

To transfer the local file shadowman to your account on penguin.example.net, type the following at a shell prompt (replace username with your username):

scp shadowman username@penguin.example.net:/home/username

This will transfer the local file shadowman to /home/username/shadowman on penguin.example.net. The general syntax to transfer a remote file to the local system is as follows:

scp username@tohostname:/remotefile /newlocalfile

The remotefile specifies the source, and newlocalfile specifies the destination. Multiple files can be specified as the source files. For example, to transfer the contents of the directory /downloads to an existing directory called uploads on the remote machine penguin.example.net, type the following at a shell prompt:

scp /downloads/* username@penguin.example.net:/uploads/

Using the sftp Command

The sftp utility can be used to open a secure, interactive FTP session. It is similar to FTP except that it uses a secure, encrypted connection. The general syntax is sftp username@hostname.com. Once authenticated, you can use a set of commands similar to using FTP. Refer to the sftp man page for a list of these commands. To read the man page, execute the command man sftp at a shell prompt. The sftp utility is available only in OpenSSH version 2.5.0p1 and later.

Generating Key Pairs

If you do not want to enter your password every time you use ssh, scp, or sftp to connect to a remote machine, you can generate an authorization key pair. Keys must be generated for each user. To generate keys for a user, use the following steps as the user who wants to connect to remote machines. If you complete the steps as root, only root will be able to use the keys.

Starting with OpenSSH version 3.0, ~/.ssh/authorized_keys2, ~/.ssh/known_hosts2, and /etc/ssh_known_hosts2 are obsolete. SSH Protocol 1 and 2 share the ~/.ssh/authorized_keys, ~/.ssh/known_hosts, and /etc/ssh/ssh_known_hosts files. Red Hat Linux 8.0 uses SSH Protocol 2 and RSA keys by default.

Tip

If you reinstall Red Hat Linux but want to save your generated key pair, back up the .ssh directory in your home directory. After reinstalling, copy this directory back to your home directory. This process can be done for all users on your system, including root.

Generating an RSA Key Pair for Version 2

Use the following steps to generate an RSA key pair for version 2 of the SSH protocol. This is the default starting with OpenSSH 2.9.

  1. To generate an RSA key pair to work with version 2 of the protocol, type the following command at a shell prompt:

    ssh-keygen -t rsa

  2. Accept the default file location of ~/.ssh/id_rsa. Enter a passphrase different from your account password and confirm it by entering it again. The public key is written to ~/.ssh/id_rsa.pub. The private key is written to ~/.ssh/id_rsa. Never distribute your private key to anyone.

  3. Change the permissions of your .ssh directory using the command chmod 755 ~/.ssh.

  4. Copy the contents of ~/.ssh/id_rsa.pub to ~/.ssh/authorized_keys on the machine to which you want to connect. If the file ~/.ssh/authorized_keys does not exist, you can copy the file ~/.ssh/id_rsa.pub to the file ~/.ssh/authorized_keys on the other machine.

  5. If you are running GNOME, skip to the section “Configuring SSH Agent with GNOME.” If you are not running the X Window System, skip to the section “Configuring SSH Agent.”

Generating a DSA Key Pair for Version 2

Use the following steps to generate a DSA key pair for version 2 of the SSH protocol.

  1. To generate a DSA key pair to work with version 2 of the protocol, type the following command at a shell prompt:

    ssh-keygen -t dsa

  2. Accept the default file location of ~/.ssh/id_dsa. Enter a passphrase different from your account password and confirm it by entering it again.

    Tip

    A passphrase is a string of words and characters used to authenticate a user. Passphrases differ from passwords in that you can use spaces or tabs in the passphrase. Passphrases are generally longer than passwords because they are usually phrases instead of just a word.

  3. The public key is written to ~/.ssh/id_dsa.pub. The private key is written to ~/.ssh/id_dsa. It is important never to give anyone the private key.

  4. Change the permissions of your .ssh directory using the command chmod 755 ~/.ssh.

  5. Copy the contents of ~/.ssh/id_dsa.pub to ~/.ssh/authorized_keys on the machine to which you want to connect. If the file ~/.ssh/authorized_keys does not exist, you can copy the file ~/.ssh/id_dsa.pub to the file ~/.ssh/authorized_keys on the other machine.

  6. If you are running GNOME, skip to the section “Configuring SSH Agent with GNOME.” If you are not running the X Window System, skip to the section “Configuring SSH Agent.”

Generating an RSA Key Pair for Version 1.3 and 1.5

Use the following steps to generate an RSA key pair that is used by version 1 of the SSH protocol. If you are connecting between Red Hat Linux 8.0 systems only, you do not need an RSA version 1.3 or RSA version 1.5 key pair.

  1. To generate an RSA (for version 1.3 and 1.5 protocol) key pair, type the following command at a shell prompt:

    ssh-keygen -t rsa1

  2. Accept the default file location (~/.ssh/identity). Enter a passphrase different from your account password. Confirm the passphrase by entering it again. The public key is written to ~/.ssh/identity.pub. The private key is written to ~/.ssh/identity. Do not give anyone the private key.

  3. Change the permissions of your .ssh directory and your key with the commands chmod 755 ~/.ssh and chmod 644 ~/.ssh/identity.pub.

  4. Copy the contents of ~/.ssh/identity.pub to the file ~/.ssh/authorized_keys on the machine to which you wish to connect. If the file ~/.ssh/authorized_keys does not exist, you can copy the file ~/.ssh/identity.pub to the file ~/.ssh/authorized_keys on the remote machine.

  5. If you are running GNOME, skip to the section “Configuring SSH Agent with GNOME.” If you are not running GNOME, skip to the section “Configuring SSH Agent.”

Configuring SSH Agent with GNOME

The ssh-agent utility can be used to save your passphrase so that you do not have to enter it each time you initiate an ssh or scp connection. If you are using GNOME, the openssh-askpass-gnome utility can be used to prompt you for your passphrase when you log in to GNOME and save it until you log out of GNOME. You will not have to enter your password or passphrase for any ssh or scp connection made during that GNOME session. If you are not using GNOME, refer to the section “Configuring SSH Agent.”

To save your passphrase during your GNOME session, perform the following steps:

  1. You will need to have the package openssh-askpass-gnome installed; you can use the command rpm -q openssh-askpass-gnome to determine if it is installed or not. If it is not installed, install it from your Red Hat Linux CD-ROM set, from a Red Hat FTP mirror site, or using Red Hat Network.

  2. If you do not have an ~/.Xclients file, run switchdesk to create it. In your ~/.Xclients file, find the following line:

    exec $HOME/.Xclients-default

  3. Change the line so that it instead reads:

    exec /usr/bin/ssh-agent $HOME/.Xclients-default

  4. Select Main Menu Button (on the Panel) > Extras > Preferences > Sessions, and click on the Startup Programs tab. Click Add and type /usr/bin/ssh-add in the Startup Command text area. Set it a priority to a number higher than any existing commands to ensure that it is executed last. A good priority number for ssh-add is 70 or higher. The higher the priority number, the lower the priority. If you have other programs listed, this one should have the lowest priority. Click Close to exit the program.

  5. Log out and then log back into GNOME; in other words, restart X. After GNOME is started, a dialog box will appear prompting you for your passphrase(s). Enter the passphrase requested. If you have both DSA and RSA key pairs configured, you will be prompted for both. From this point on, you should not be prompted for a password by ssh, scp, or sftp.

Configuring SSH Agent

ssh-agent can be used to store your passphrase so that you do not have to enter it each time you make an ssh or scp connection. If you are not running the X Window System, follow these steps from a shell prompt. If you are running GNOME but you do not want to configure it to prompt you for your passphrase when you log in, this procedure will work in a terminal window, such as an XTerm. If you are running X but not GNOME, this procedure will work in a terminal window. However, your passphrase will be remembered only for that terminal window; it is not a global setting.

  1. At a shell prompt, type the following command:

    exec /usr/bin/ssh-agent $SHELL

  2. Then type the command:

    ssh-add

    and enter your passphrase(s). If you have more than one key pair configured, you will be prompted for each one.

  3. When you log out, your passphrase(s) will be forgotten. You must execute these two commands each time you log in to a virtual console or open a terminal window.


Additional Resources

The OpenSSH and OpenSSL projects are in constant development, so the most up-to-date information for them will be found on their websites. The man pages for OpenSSH and OpenSSL tools are also good sources of detailed information.

Installed Documentation

  • The ssh, scp, sftp, sshd, and ssh-keygen man pages — These man pages include information on how to use these commands as well as all the parameters that can be used with them.

Useful Websites

  • http://www.openssh.com — The OpenSSH FAQ page, bug reports, mailing lists, project goals, and a more technical explanation of the security features.

  • http://www.openssl.org — The OpenSSL FAQ page, mailing lists, and a description of the project goal.

  • http://www.freessh.org — SSH client software for other platforms.


Chapter 25: Pluggable Authentication Modules (PAM)

Programs that give privileges to users must properly authenticate each user. For instance, when you log in to a system, you provide your username and password, and the login process uses this information to verify your identity. Pluggable Authentication Modules (PAM) allows the system administrator to set authentication policies for PAM-aware applications without having to recompile authentication programs. PAM does this by utilizing a pluggable, modular architecture. Which modules PAM calls for a particular application is determined by that application’s PAM configuration file in the /etc/pam.d/ directory.

In most situations, you will never need to alter the default PAM configuration files for a PAM-aware application. Whenever you use RPM to install programs that require authentication, they automatically make the changes necessary to do normal password authentication using PAM. However, if you need to customize the PAM configuration file, you must understand the structure of this file (see the section “PAM Configuration Files” for more information).

Advantages of PAM

When used correctly, PAM provides the following advantages for a system administrator:

  • It provides a common authentication scheme that can be used with a wide variety of applications.

  • It allows great flexibility and control over authentication for both the system administrator and application developer.

  • It allows application developers to develop their program without implementing a particular authentication scheme. Instead, they can focus purely on the details of their program.


PAM Configuration Files

The directory /etc/pam.d/ contains the PAM configuration files for PAM-aware applications. In earlier versions of PAM, the file /etc/pam.conf was used, but this file is now deprecated. The pam.conf file is read only if the /etc/pam.d/ directory does not exist. Each PAM-aware application or service — as applications designed to be used by many users are commonly known — has its own file within the /etc/pam.d/ directory. These files have a specific layout containing calls to modules usually located in the /lib/security/ directory. Additionally, each line within a PAM configuration file specifies a module type, a control flag, a path to the module, and, sometimes, module arguments.

PAM Service Names

Each PAM configuration file in the /etc/pam.d/ directory is named after the service for which it controls access. It is up to the PAM-aware program to define its service name and install its PAM configuration file in the pam.d directory. For example, the login program defines its service name as /etc/pam.d/login. In general, the service name is the name of the program used to access the service, not the program used to provide the service. This is why the service wu-ftpd defines its service name as /etc/pam.d/ftp.

The next four sections describe the basic format of PAM configuration files and how they use PAM modules to perform authentication for PAM-aware applications.


PAM Modules

Four types of PAM modules are used to control access to services. These types correspond to different aspects of the authorization process:

  • auth — These modules are used to authenticate the user by, for example, asking for and checking a password. It can also set credentials, such as group membership or Kerberos tickets.

  • account — These modules are used to make sure access is allowed. For example, it can check if the account is expired, or it can check if the user is allowed to log in at a particular time of day.

  • password — These modules are used to set passwords.

  • session — After a user has been authenticated, these modules are used to manage the user’s session. This module type can also perform additional tasks that are needed to allow access, like mounting a user’s home directory or making the user’s mailbox available.

    Note

    An individual module can address more than one of the above module types. For instance, pam_unix.so has components that address all four module types.

In a PAM configuration file, the module type is the first aspect defined. For example, a typical line in a configuration may look like this:

auth           required    /lib/security/pam_unix.so

This instructs PAM to look at the auth component of the pam_unix.so module.

Stacking Modules

Modules can be stacked, or placed upon one another, so that multiple modules are used together for a particular purpose. Therefore the order in which the modules are listed is very important to the authentication process. Stacking makes it very easy for an administrator to require several conditions to exist before allowing user authentication. For example, rlogin normally uses five stacked auth modules, as seen in its PAM configuration file:

auth   required     /lib/security/pam_nologin.so
auth   required     /lib/security/pam_securetty.so
auth   required     /lib/security/pam_env.so
auth   sufficient   /lib/security/pam_rhosts_auth.so
auth   required     /lib/security/pam_stack.so service=system-auth

Before users are allowed to use rlogin, PAM verifies that the /etc/nologin file does not exist, that they are not trying to log in remotely as a root user over an unencrypted network connection, and that any environmental variables can be loaded. Then, a successful rhosts authentication is performed before the connection is allowed. If rhosts authentication fails, then standard password authentication is performed.

Creating Modules

New PAM modules can be added at any time, and PAM-aware applications can then use them. For example, if you create a one-time-password creation method and write a PAM module to support it, PAM-aware programs can immediately use the new module and password method without being recompiled or otherwise modified. This is very beneficial because it lets you mix and match, as well as test, authentication methods for different programs without recompiling them. Documentation on writing modules is included with the system in the /usr/share/doc/pam-version-number/ directory.


PAM Module Control Flags

All PAM modules generate a success or failure result when checked. Control flags tell PAM what do with the result. Since modules can be stacked in a particular order, control flags give you the ability to set the importance of a module with respect to the modules that follow it. Again, consider the rlogin PAM configuration file:

auth       required         /lib/security/pam_nologin.so
auth       required         /lib/security/pam_securetty.so
auth       required         /lib/security/pam_env.so
auth       sufficient       /lib/security/pam_rhosts_auth.so
auth       required         /lib/security/pam_stack.so service=system-auth
Note

The order in which required modules are called is not critical. The sufficient and requisite control flags are what cause order to become important, as they determine whether or not authentication will fail if a module check fails. The bulleted list below provides an explanation of each type of control flag.

After the module type is specified, the control flags decide how important the success or failure of that particular module should be in the overall goal of allowing access to the service. Four types of control flags are defined by the PAM standard:

  • required — The module must be successfully checked in order to allow authentication. If a required module check fails, the user is not notified until all other modules of the same module type have been checked.

  • requisite — The module must be successfully checked in order for the authentication to be successful. However, if a requisite module check fails, the user is notified immediately with a message reflecting the first failed required or requisite module.

  • sufficient — The module checks are ignored if it fails. But, if a sufficient flagged module is successfully checked and no required flagged modules above it have failed, then no other modules of this module type are checked, and the user is authenticated.

  • optional — The module checks are ignored if it fails. If the module check is successful, it does not play a role in the overall success or failure of that module type. The only time a module flagged as optional is necessary for successful authentication is when no other modules of that type have succeeded or failed. In this case, an optional module determines the overall PAM authentication for that module type.

A newer control flag syntax allowing for even more control is now available for PAM. Please see the PAM docs located in the /usr/share/doc/pam-version-number/ directory for information on this new syntax.


PAM Module Paths

Module paths tell PAM where to find the pluggable module to be used with the module type specified. Usually, it is provided as the full path to the module, such as /lib/security/pam_stack.so. However, if the full path is not given (in other words, the path does not start with a /), then the module indicated is assumed to be in the /lib/security/ directory — the default location for PAM modules.


PAM Module Arguments

PAM uses arguments to pass information to a pluggable module during authentication for a particular module type. These arguments allow the PAM configuration files for particular programs to use a common PAM module, but in different ways. For example, the pam_userdb.so module uses secrets stored in a Berkeley DB file to authenticate the user. Berkeley DB is an open-source database system designed to be embedded in many applications to track information. The module takes a db argument, specifying the Berkeley DB file name to use, which can be different for different services. So, the pam_userdb.so line in a PAM configuration file looks like this:

auth   required  /lib/security/pam_userdb.so db=path/to/file

Invalid arguments are ignored and do not otherwise affect the success or failure of the PAM module. When an invalid argument is passed, an error is usually written to the /var/log/messages file. However, since the reporting method is controlled by the PAM module, the module must be written correctly in order to log the error to this file.


Sample PAM Configuration Files

Following is a sample PAM application configuration file:

#%PAM-1.0
auth     required    /lib/security/pam_securetty.so
auth     required    /lib/security/pam_unix.so shadow nullok
auth     required    /lib/security/pam_nologin.so
account  required    /lib/security/pam_unix.so
password required    /lib/security/pam_cracklib.so retry=3
password required    /lib/security/pam_unix.so shadow nullok use_authtok
session  required   /lib/security/pam_unix.so

The first line is a comment as denoted by the # character — the comment symbol in PAM configuration files. Lines two through four stack three modules for login authentication.

auth          required      /lib/security/pam_securetty.so

This line makes sure that if the user is trying to log in as root, the tty on which they are logging in is listed in the /etc/securetty file, if that file exists.

auth          required      /lib/security/pam_unix.so nullok

This line causes the user to be asked for a password and then checks the password using the information stored in /etc/passwd and, if it exists, /etc/shadow. The pam_unix.so module automatically detects and utilizes shadow passwords, stored in /etc/shadow, to authenticate users. Please refer to Chapter 7 for more information on shadow passwords.

The argument nullok instructs the pam_unix.so module to allow a blank password.

auth          required      /lib/security/pam_nologin.so

This is the final authentication step. It checks to see if the file /etc/nologin exists. If nologin does exist and the user is not root, authentication fails.

Note

In this example, all three auth modules are checked, even if the first auth module fails. This prevents users from knowing at what stage their authentication failed. Such knowledge in the hands of attackers could allow them to more easily deduce how to crack the system.

account       required      /lib/security/pam_unix.so

This line causes any necessary account verification to be done. For example, if shadow passwords have been enabled, the account component of the pam_unix.so module will check to see if the account has expired or if the user has not changed his or her password within the grace period allowed.

password   required   /lib/security/pam_cracklib.so retry=3

If a password has expired, the password component of the pam_cracklib.so module prompts for a new password. It then tests the newly created password to see whether the it can easily be determined by a dictionary-based password-cracking program. If it fails this test the first time, it gives the user two more chances to create a strong password, because of the retry=3 argument.

password   required    /lib/security/pam_unix.so shadow nullok use_authtok

This line specifies that if the program changes the user’s password, it should use the password component of the pam_unix.so module to do so. This will happen only if the auth portion of the pam_unix.so module has determined that the password needs to be changed — for example, if a shadow password has expired.

The argument shadow tells the module to create shadow passwords when updating a user’s password. The argument nullok instructs the module to allow the user to change his or her password from a blank password; otherwise, a null password is treated as an account lock. The final argument on this line, use_authtok, provides a good example of how one can stack PAM modules. This argument tells the module not to prompt the user for a new password. Instead, it is to accept any password that passes through previous password module. This way all new passwords must pass the pam_cracklib.so test for secure passwords before being accepted.

session required /lib/security/pam_unix.so

The final line specifies that the session component of the pam_unix.so module will manage the session. This module logs the username and the service type to /var/log/messages at the beginning and end of each session. It can be supplemented by stacking it with other session modules if you need more functionality.

The next sample configuration file illustrates auth module stacking for the rlogin program — a program that allows users to log in remotely.

#%PAM-1.0
auth        required         /lib/security/pam_nologin.so
auth        required         /lib/security/pam_securetty.so
auth        required         /lib/security/pam_env.so
auth        sufficient       /lib/security/pam_rhosts_auth.so
auth        required         /lib/security/pam_stack.so service=system-auth

First, pam_nologin.so checks to see if /etc/nologin exists. If is does, no one can log in except for root.

auth        required          /lib/security/pam_securetty.so

The pam_securetty.so module then prevents root logins from occurring on insecure terminals. This effectively disallows all root rlogin attempts for security reasons.

Tip

If you need to log in as root, use OpenSSH instead. For more information on the SSH protocol, see Chapter 24.

auth           required          /lib/security/pam_env.so

This line loads the pam_env.so module, which sets the environmental variables specified in /etc/security/pam_env.conf.

auth       sufficient        /lib/security/pam_rhosts_auth.so

The pam_rhosts_auth.so module then authenticates the user using .rhosts in the user’s home directory. If this succeeds, PAM immediately authenticates the rlogin session. If pam_rhosts_auth.so fails to authenticate the user, this failed authentication attempt is ignored.

auth        required        /lib/security/pam_stack.so service=system-auth

If the pam_rhosts_auth.so module fails to authenticate the user, the pam_stack.so module performs normal password authentication. The argument service=system-auth means the user must now pass through the PAM configuration for system authorization found in /etc/pam.d/system-auth.

Note

If you do not want to prompt for a password when the securetty check fails and determines that the user is trying to log in as root remotely, you can change the pam_securetty.so module from required to requisite.


PAM and Device Ownership

Red Hat Linux allows the first privileged user to log in on the physical console of the machine the ability to manipulate devices and perform tasks normally reserved for root. This is done through a PAM module called pam_console.so.

Device Ownership

When a user logs into a machine under Red Hat Linux, the pam_console.so module is called by login or by the graphical login programs, gdm and kdm. If this user is the first user to log in at the physical console — called the console user — the module grants ownership of a variety of devices normally owned by root. The console user owns these devices until the last local session for that user ends. Once the user has logged out, ownership of the devices reverts back to their default values.

The devices affected include sound cards, floppy drives, and CD-ROM drives. This allows a local user to manipulate these devices without attaining root, thus simplifying common tasks for the console user. In the file /etc/security/console.perms, you can edit the list of devices controlled by pam_console.so.

Application Access

The console user is also allowed access to any program with a file bearing the command name in the /etc/security/console.apps/ directory. These files do not need to contain any data but must have the exact name of the command to which they correspond. One notable group of applications the console user has access to are three programs that shut off or reboot the system. These are:

  • /sbin/halt

  • /sbin/reboot

  • /sbin/poweroff

Because these are PAM-aware applications, they call the pam_console.so module as a requirement for use. For more information see the man pages for pam_console, console.perms, and console.apps.


Additional Resources

Following is a list of information sources for using and configuring PAM on your system. In addition to these sources, you should read the PAM configuration files on your system to better understand how they are structured.

Installed Documentation

  • pam man page — Good introductory information on PAM, including the structure and purpose of the PAM configuration files.

  • /usr/share/doc/pam-version-number — Contains a System Administrators’ Guide, a Module Writers’ Manual, and an Application Developers’ Manual. Also contains a copy of the PAM standard, DCE-RFC 86.0.

Useful Website

  • http://www.kernel.org/pub/linux/libs/pam — The primary distribution website for the Linux-PAM project, containing information on various PAM modules, a FAQ, and additional PAM documentation.


Chapter 26: Tripwire

Tripwire is a program that monitors the reliability of critical system files and directories by identifying changes made to them. Tripwire configuration options include the ability to receive alerts via e-mail if particular files are altered and automated integrity checking via a cron job. Using Tripwire for intrusion detection and damage assessment helps you keep track of system changes. Because Tripwire can positively identify files that have been added, modified, or deleted, it can speed recovery from a break-in by keeping the number of files that must be restored to a minimum.

Tripwire compares files and directories against a database of file locations, dates modified, and other data. The database contains baselines, which are snapshots of specified files and directories at a specific point in time. The contents of the baseline database should be generated before the system is at risk of intrusion. After creating the baseline database, Tripwire then compares the current system with the baseline and reports any modifications, additions, or deletions.

While Tripwire is a valuable tool for auditing the security state of Red Hat Linux systems, Tripwire is not supported by Red Hat, Inc. Refer to the Tripwire project’s website (http://www.tripwire.org) for more information about Tripwire.

How to Use Tripwire

Figure 26-1 illustrates how Tripwire works.

Click To expand
Figure 26-1: Using Tripwire

The following describes in more detail the numbered blocks shown in Figure 26-1.

  1. Install Tripwire and customize the policy file. Install the tripwire RPM (see the section “Installing the Tripwire RPM”). Then, customize the sample configuration and policy files (/etc/tripwire/twcfg.txt and /etc/tripwire/twpol.txt, respectively) and run the configuration script, /etc/tripwire/twinstall.sh. For more information, see the section “Customizing Tripwire.”

  2. Initialize the Tripwire database. Build a database of critical system files to monitor based on the contents of the new, signed Tripwire policy file, /etc/tripwire/tw.pol. For more information, see the section “Initializing the Tripwire Database.”

  3. Run a Tripwire integrity check. Compare the newly created Tripwire database with the actual system files, looking for missing or altered files. For more information, see the section “Running an Integrity Check.”

  4. Examine the Tripwire report file. View the Tripwire report file using /usr/sbin/twprint to note integrity violations. For more information, see the section “Viewing Tripwire Reports.”

  5. If unauthorized integrity violations occur, take appropriate security measures. If monitored files have been altered inappropriately, you can either replace the original files from backup copies, reinstall the program, or completely reinstall the operating system.

  6. If the file alterations were valid, verify and update the Tripwire database file. If the changes made to monitored files are intentional, edit Tripwire’s database file to ignore those changes in subsequent reports. For more information, see the section “Updating the Tripwire Database.”

  7. If the policy file fails verification, update the Tripwire policy file.

To change the list of files Tripwire monitors or how it treats integrity violations, update the supplied policy file (/etc/tripwire/twpol.txt), regenerate a signed copy (/etc/tripwire/tw.pol), and update the Tripwire database. For more information, see the section “Updating the Tripwire Policy File.” Refer to the appropriate sections within this chapter for detailed instructions on each step.


Installing the Tripwire RPM

The easiest way to install Tripwire is to select the Tripwire RPM during the Red Hat Linux 8.0 installation process. However, if you have already installed Red Hat Linux 8.0, you can use rpm or Package Management Tool (redhat-config-packages) to install the Tripwire RPM from the Red Hat Linux 8.0 CD-ROMs. If you are not sure whether or not Tripwire is installed, type the following command at a shell prompt:

rpm -q tripwire

If Tripwire is installed, this command will return the following:

tripwire-version-number

The following steps outline how to find and install Tripwire from a CD-ROM using the rpm command-line application:

  1. Insert CD 2 of the Red Hat Linux 8.0 installation CD-ROMs.

  2. If the CD-ROM does not automatically mount, type the following command:

    mount /mnt/cdrom

  3. Verify that the Tripwire RPM is on the CD-ROM by typing:

    ls /mnt/cdrom/RedHat/RPMS/ | grep tripwire

  4. If the RPM is on the CD-ROM, this command will display the package name. If the RPM is not on the CD-ROM, the shell prompt will return. In this case, you will need to check CD 3 and, possibly, CD 1 of the Red Hat Linux 8.0 installation CD-ROMs by first unmounting the CD-ROM and then repeating steps 1 through 3. Unmount the CD-ROM by right-clicking on the CD-ROM icon and selecting Eject or by typing the following command at the shell prompt:

    umount /mnt/cdrom

  5. Once you have located the Tripwire RPM, install it by typing the following command as the root user:

    rpm -Uvh /mnt/cdrom/RedHat/RPMS/tripwire*.rpm

In the /usr/share/doc/tripwire-version-number/ directory, you will find release notes and README files for Tripwire. These documents contain important information about the default policy file and other topics.


Customizing Tripwire

After you have installed the Tripwire RPM, you need to complete the following steps to initialize the software.

Edit /etc/tripwire/twcfg.txt

Although you are not required to edit this sample Tripwire configuration file, you may find it necessary for your situation. For instance, you may want to alter the location of Tripwire files, customize email settings, or customize the level of detail for reports. Below is a list of required user-configurable variables in the /etc/tripwire/twcfg.txt file:

  • POLFILE — Specifies the location of the policy file; /etc/tripwire/tw.pol is the default value.

  • DBFILE — Specifies the location of the database file; /var/lib/tripwire/$(HOSTNAME).twd is the default value.

  • REPORTFILE — Specifies the location of the report files. By default this value is set to /var/lib/tripwire/report/$(HOSTNAME)-$(DATE).twr.

  • SITEKEYFILE — Specifies the location of the site key file; /etc/tripwire/site.key is the default value.

  • LOCALKEYFILE — Specifies the location of the local key file; /etc/tripwire/$(HOSTNAME)-local.key is the default value.

    Note

    If you edit the configuration file and leave any of the above variables undefined, the configuration file will be invalid. If this occurs, when you execute the tripwire command it will report an error and exit.

The rest of the configurable variables in the sample /etc/tripwire/twcfg.txt file are optional. These include the following:

  • EDITOR — Specifies the text editor called by Tripwire. The default value is /bin/vi.

  • LATEPROMPTING — If set to true, this variable configures Tripwire to wait as long as possible before prompting the user for a password, thereby minimizing the amount of time the password is in memory. The default value is false.

  • LOOSEDIRECTORYCHECKING — If set to true, this variable configures Tripwire to report if a file within a watched directory changes and not to report the change for the directory itself. That is, any changes to the directory file will not be reported, though changes to directory contents will be reported. This limits redundancy in Tripwire reports. The default value is false.

  • SYSLOGREPORTING — If set to true, this variable configures Tripwire to report information to the syslog daemon via the user facility. The log level is set to notice. See the syslogd man page for more information. The default value is false.

  • MAILNOVIOLATIONS — If set to true, this variable configures Tripwire to email a report at a regular interval regardless of whether or not any violations have occurred. The default value is true.

  • EMAILREPORTLEVEL — Specifies the level of detail for emailed reports. Valid values for this variable are 0 through 4. The default value is 3.

  • REPORTLEVEL — Specifies the level of detail for reports generated by the twprint command. This value can be overridden on the command line and is set to 3 by default.

  • MAILMETHOD — Specifies which mail protocol Tripwire should use. Valid values are SMTP and SENDMAIL. The default value is SENDMAIL.

  • MAILPROGRAM — Specifies which mail program Tripwire should use. The default value is /usr/sbin/sendmail -oi -t.

After editing the sample configuration file, you will need to configure the sample policy file.

Warning

For security purposes, you should either delete or store in a secure location any copies of the plaintext /etc/tripwire/twcfg.txt file after running the installation script or regenerating a signed configuration file. Alternatively, you can change the permissions so that it is not world-readable.

Edit /etc/tripwire/twpol.txt

Although it is not required, you should edit this heavily commented sample Tripwire policy file to take into account the specific applications, files, and directories on your system. Relying on the unaltered sample configuration from the RPM may not adequately protect your system. Modifying the policy file also increases the usefulness of Tripwire reports by minimizing false alerts for files and programs you are not using and by adding functionality, such as email notification.

Note

Notification via email is not configured by default. See the section “Tripwire and Email” for more on configuring this feature.

If you modify the sample policy file after running the configuration script, see the section “Updating the Tripwire Policy File” for instructions on regenerating a signed policy file.

Warning

For security purposes, you should either delete or store in a secure location any copies of the plaintext /etc/tripwire/twpol.txt file after running the installation script or regenerating a signed configuration file. Alternatively, you can change the permissions so that it is not world-readable.

Run the twinstall.sh Script

As the root user, type /etc/tripwire/twinstall.sh at the shell prompt to run the configuration script. The twinstall.sh script will ask you for site and local passwords. These passwords are used to generate cryptographic keys for protecting Tripwire files. The script then creates and signs these files. When selecting the site and local passwords, consider the following guidelines:

  • Use at least eight alphanumeric and symbolic characters, but for each password do not exceed 1,023.

  • Do not use quotes in a password.

  • Make the Tripwire passwords completely different from the root password or any other password for the system.

  • Use unique passwords for both the site key and the local key.

The site key password protects the Tripwire configuration and policy files. The local key password protects the Tripwire database and report files.

Warning

There is no way to decrypt a signed file if you forget your passwords. If you forget the passwords, the files are unusable and you will have to run the configuration script again.

By encrypting its configuration, policy, database, and report files, Tripwire protects them from being viewed by anyone who does not know the site and local passwords. This means that, even if intruders obtain root access to your system, they will not be able to alter the Tripwire files to hide their tracks. Once encrypted and signed, the configuration and policy files generated by running the twinstall.sh script should not be renamed or moved.


Initialize the Tripwire Database

When initializing its database, Tripwire builds a collection of file system objects based on the rules in the policy file. This database serves as the baseline for integrity checks. To initialize the Tripwire database, use the following command:

/usr/sbin/tripwire --init

This command can take several minutes to run. Once you finish these steps successfully, Tripwire has the baseline snapshot of your file system necessary to check for changes in critical files. After initializing the Tripwire database, run an initial integrity check. This check should be done prior to connecting the computer to the network and putting it into production. For instructions on doing this, see the section “Running an Integrity Check.”

Once Tripwire is configured to your satisfaction, you are free to place the system into production.


Running an Integrity Check

By default, the Tripwire RPM adds a shell script called tripwire-check to the /etc/cron.daily/ directory. This will automatically run an integrity check once per day. You can run a Tripwire integrity check at any time by typing the following command:

/usr/sbin/tripwire --check

During an integrity check, Tripwire compares the current state of file system objects with the properties recorded in its database. Violations are printed to the screen, and an encrypted copy of the report is created in /var/lib/tripwire/report/. You can view the report using the twprint command as outlined in the section “Viewing Tripwire Reports.” If you would like to be notified by email when certain types of integrity violations occur, you can configure this in the policy file. See the section “Tripwire and Email” for instructions on how to set up and test this feature.


Examining Tripwire Reports

The /usr/sbin/twprint command is used to view encrypted Tripwire reports and databases.

Viewing Tripwire Reports

The twprint -m r command will display the contents of a Tripwire report in clear text. You must, however, tell twprint which report file to display. A twprint command for printing Tripwire reports looks similar to the following:

/usr/sbin/twprint -m r --twrfile /var/lib/tripwire/report/name.twr

The -m r option in the command directs twprint to decode a Tripwire report. The --twrfile option directs twprint to use a specific Tripwire report file. The name of the Tripwire report that you want to see includes the name of the host that Tripwire checked to generate the report, plus the creation date and time. You can review previously saved reports at any time. Simply type ls /var/lib/tripwire/report to see a list of Tripwire reports. Tripwire reports can be rather lengthy, depending upon the number of violations found or errors generated. A sample report starts off like this:

Tripwire(R) 2.3.0 Integrity Check Report

Report generated by:            root
Report created on:              Fri Jan 12 04:04:42 2001
Database last updated on:       Tue Jan       9 16:19:34 2001

=============================================================
Report Summary:
=============================================================
Host name:                            some.host.com
Host IP address:                      10.0.0.1
Host ID:                              None
Policy file used:                     /etc/tripwire/tw.pol
Configuration file used:              /etc/tripwire/tw.cfg

Database file used:       /var/lib/tripwire/some.host.com.twd
Command line used:                 /usr/sbin/tripwire -–check

=============================================================
Rule Summary:
=============================================================
-------------------------------------------------------------
Section: Unix File System
-------------------------------------------------------------
Rule Name            Severity Level  Added  Removed  Modified
---------            --------------  -----  -------  --------
Invariant Directories      69          0       0        0
Temporary directories      33          0       0        0
* Tripwire Data Files     100          1       0        0
Critical devices          100          0       0        0
User binaries              69          0       0        0
Tripwire Binaries         100          0       0        0

Viewing Tripwire Databases

You can also use twprint to view the entire database or information about selected files in the Tripwire database. This is useful for seeing just how much information Tripwire is tracking on your system. To view the entire Tripwire database, type:

/usr/sbin/twprint -m d --print-dbfile | less

This command will generate a large amount of output, with the first few lines appearing similar to this:

Tripwire(R) 2.3.0 Database

Database generated by:                      root
Database generated on:                      Tue Jan     9 13:56:42 2001
Database last updated on:                   Tue Jan     9 16:19:34 2001

================================================================
Database Summary:
================================================================
Host name:                              some.host.com
Host IP address:                        10.0.0.1
Host ID:                                None
Policy file used:                       /etc/tripwire/tw.pol
Configuration file used:                /etc/tripwire/tw.cfg
Database file used:                     /var/lib/tripwire/some.host.com.twd
Command line used:                      /usr/sbin/tripwire –init

================================================================
Object Summary:
================================================================
----------------------------------------------------------------
# Section: Unix File System
----------------------------------------------------------------
                      Mode        UID      Size          Modify Time
                     ------     -------   ------      ---------------
 /                drwxr-xr-x    root (0)    XXX        XXXXXXXXXXXXXXXXX
 /bin             drwxr-xr-x    root (0)   4096    Mon Jan 8 08:20:45 2001
 /bin/arch        -rwxr-xr-x    root (0)   2844   Tue Dec 12 05:51:35 2000
 /bin/ash         -rwxr-xr-x    root (0)  64860   Thu Dec  7 22:35:05 2000
 /bin/ash.static  -rwxr-xr-x    root (0) 405576   Thu Dec  7 22:35:05 2000

To see information about a particular file that Tripwire is tracking, such as /etc/hosts, use the following command:

/usr/sbin/twprint -m d --print-dbfile /etc/hosts

The result will look similar to this:

Object name:      /etc/hosts

Property:                       Value:
-------------                   -----------
Object Type                     Regular File
Device Number                   773
Inode Number                    216991
Mode                            -rw-r--r--
Num Links                       1
UID                             root (0)
GID                             root (0)

See the twprint man page for more options.


Updating the Tripwire Database

If you run an integrity check and Tripwire finds violations, you will first need to determine whether the violations discovered are actual security breaches or the product of authorized modifications. If you recently installed an application or edited critical system files, Tripwire will correctly report integrity check violations. In this case, you should update your Tripwire database so those changes are no longer reported as violations. However, if unauthorized changes have been made to system files and generate integrity check violations, you should restore the original file from a backup, reinstall the program, or, if the breach is severe enough, completely reinstall the operating system.

To update its database so it accepts valid policy violations, Tripwire first cross-references a report file against the database, then integrates into it valid violations from the report file. When updating the database, be sure to use the most recent report. Use the following command to update the Tripwire database, where name is the name of the most recent report file:

/usr/sbin/tripwire --update --twrfile /var/lib/tripwire/report/name.twr

Tripwire will display the report file using the default text editor specified on the EDITOR line of the Tripwire configuration file. This gives you an opportunity to deselect files you do not wish to update in the Tripwire database.

Note

It is important that you change only authorized integrity violations in the database.

All proposed updates to the Tripwire database start with an [x] before the file name, similar to the following example:

Added:
[x] "/usr/sbin/longrun"

Modified:
[x] "/usr/sbin"
[x] "/usr/sbin/cpqarrayd"

If you want to specifically exclude a valid violation from being added to the Tripwire database, remove the [x]. To accept any files with an [x] beside them as changes, or to edit files in the default text editor, vi, type i and press Enter to enter insert mode and make any necessary changes. When finished, press the Esc key, type :wq, and press Enter. After the editor closes, enter your local password, and the database will be rebuilt and signed. After a new Tripwire database is written, the newly authorized integrity violations will no longer show up as warnings.


Updating the Tripwire Policy File

If you want to change the files Tripwire records in its database, change email configuration, or modify the severity at which certain violations are reported, you need to edit your Tripwire policy file. First, make whatever changes are necessary to the sample policy file, /etc/tripwire/twpol.txt. If you deleted this file (as you should whenever you are finished configuring Tripwire), you can regenerate it by issuing the following command:

twadmin --print-polfile > /etc/tripwire/twpol.txt

A common change to this policy file is to comment out any files that do not exist on your system so that they will not generate a “file not found” error in your Tripwire reports. For example, if your system does not have a /etc/smb.conf file, you can tell Tripwire not to try to look for it by commenting out its line in twpol.txt with the # character as in the following example:

#    /etc/smb.conf   -> $(SEC_CONFIG) ;

Next, you must generate a new, signed /etc/tripwire/tw.pol file and generate an updated database file based on this policy information. Assuming /etc/tripwire/twpol.txt is the edited policy file, use this command:

/usr/sbin/twadmin --create-polfile -S site.key /etc/tripwire/twpol.txt

You will be asked for the site password. Then, the twpol.txt file will be encrypted and signed. It is important that you update the Tripwire database after creating a new /etc/tripwire/tw.pol file. The most reliable way to accomplish this is to delete your current Tripwire database and create a new database using the new policy file. If your Tripwire database file is named bob.domain.com.twd, type this command:

rm /var/lib/tripwire/bob.domain.com.twd

Then type the following command to create a new database using the updated policy file:

/usr/sbin/tripwire --init

To make sure the database was correctly changed, run the first integrity check manually and view the contents of the resulting report. See the sections “Running an Integrity Check” and “Viewing Tripwire Reports” for more on doing these tasks.

Tripwire and Email

You can configure Tripwire to send an email to one or more accounts if a specific type of policy is violated. In order to do this, you need to figure out what policy rules should be monitored and who should get the email when those rules are broken. Note that on large systems with multiple administrators, you can have different sets of people notified depending on the types of violations.

Once you have determined whom to notify and what rule violations to report to them, edit the /etc/tripwire/twpol.txt file, adding an emailto= line to the rule directive section for each appropriate rule. Do this by adding a comma after the severity= line and putting emailto= on the next line, followed by one or more email addresses. More than one email address can be specified if the addresses are separated by semicolons. For example, if two administrators, Johnray and Bob, need to be notified if a networking program is modified, change the Networking Programs rule directive in the policy file to look like this:

(
     rulename = "Networking Programs",
     severity = $(SIG_HI),
     emailto = johnray@domain.com;bob@domain.com
)

After changing the policy file, follow the instructions in the section “Updating the Tripwire Policy File” to generate an updated, encrypted, and signed copy of the Tripwire policy file.

Sending Test Email Messages

To test Tripwire’s email notification configuration, use the following command:

/usr/sbin/tripwire --test --email your@email.address

A test email will immediately be sent to the email address by the Tripwire program.


Updating the Tripwire Configuration File

If you want to change Tripwire’s configuration file, first edit the sample configuration file, /etc/tripwire/twcfg.txt. If you deleted this file (as you should whenever you are finished configuring Tripwire), you can regenerate it by issuing the following command:

twadmin --print-cfgfile > /etc/tripwire/twcfg.txt

Tripwire will not recognize any configuration changes until the configuration text file is correctly signed and converted to /etc/tripwire/tw.pol with the twadmin command. Use the following command to regenerate a configuration file from the /etc/tripwire/twcfg.txt file:

/usr/sbin/twadmin --create-cfgfile -S site.key /etc/tripwire/twcfg.txt

Since the configuration file does not not alter any Tripwire policies or files tracked by the application, it is not necessary to regenerate the Tripwire database.


Tripwire File Location Reference

Before working with Tripwire, you should know where important files for the application are located. Tripwire stores its files in a variety of places depending on their role.

  • Within the /usr/sbin/ directory you will find the following programs:

    • tripwire

    • twadmin

    • twprint

  • Within the /etc/tripwire/ directory you will find the following files:

    • twinstall.sh — The initialization script for Tripwire.

    • twcfg.txt — The sample configuration file supplied by the Tripwire RPM.

    • tw.cfg — The signed configuration file created by the twinstall.sh script.

    • twpol.txt — The sample policy file supplied by the Tripwire RPM.

    • tw.pol — The signed policy file created by the twinstall.sh script.

    • key files — The local and site keys created by the twinstall.sh script, which ends with a .key file extension.

  • After running the twinstall.sh installation script, you will find the following files in the /var/lib/tripwire/ directory:

    • the Tripwire database — The database of your system’s files, which has a .twd file extension.

    • Tripwire reports — The report/ directory is where Tripwire reports are stored.

The next section explains more about the roles these files play in the Tripwire system.

Tripwire Components

The following sections describe in more detail the roles the files listed in the previous section play in the Tripwire system.

/etc/tripwire/tw.cfg

This is the encrypted Tripwire configuration file, which stores system-specific information, such as the location of Tripwire data files. The twinstall.sh installer script and twadmin command generate this file using the information in the text version of the configuration file, /etc/tripwire/twcfg.txt.

After running the the installation script, the system administrator can change parameters by editing /etc/tripwire/twcfg.txt and regenerating a signed copy of the tw.cfg file using the twadmin command. See the section “Updating the Tripwire Configuration File” for more information on how to do this.

/etc/tripwire/tw.pol

The active Tripwire policy file is an encrypted file containing comments, rules, directives, and variables. This file dictates the way Tripwire checks your system. Each rule in the policy file specifies a system object to be monitored. Rules also describe which changes to the object to report and which to ignore.

System objects are the files and directories you wish to monitor. Each object is identified by an object name. A property refers to a single characteristic of an object that Tripwire software can monitor. Directives control conditional processing of sets of rules in a policy file. During installation, the sample text policy file, /etc/tripwire/twpol.txt, is used to generate the active Tripwire policy file.

After running the the installation script, the system administrator can update the Tripwire policy file by editing /etc/tripwire/twpol.txt and regenerating a signed copy of the tw.pol file using the twadmin command. See the section “Updating the Tripwire Policy File” for more information on how to do this.

/var/lib/tripwire/host_name.twd

When first initialized, Tripwire uses the signed policy file rules to create this database file. The Tripwire database is a baseline snapshot of the system in a known secure state. Tripwire compares this baseline against the current system to determine what changes have occurred. This comparison is called an integrity check.

/var/lib/tripwire/report/host_name-date_of_report-time_of_report.twr

When you perform an integrity check, Tripwire produces report files in the /var/lib/tripwire/report/ directory. The report files summarize any file changes that violated the policy file rules during the integrity check. Tripwire reports are named using the following convention: host_name-date_of_report-time_of_report.twr. These reports detail the differences between the Tripwire database and your actual system files.


Additional Resources

Tripwire can do more than what is covered in this chapter. Refer to these additional sources for more information about Tripwire.

Installed Documentation

  • /usr/share/doc/tripwire-version-number — An excellent starting point for learning about how to customize the configuration and policy files in the /etc/tripwire/ directory.

  • Also, refer to the man pages for tripwire, twadmin, and twprint for help using those utilities.

Useful Websites

  • http://www.tripwire.org — The home of the Tripwire Open Source Project, where you can find the latest news on the application, including a helpful FAQ.

  • http://sourceforge.net/project/showfiles.php?group_id=3130 — This links to the latest official documentation from the Tripwire project.


Part V: Appendixes

Chapter List

Appendix A: Installing Red Hat Linux
Appendix B: Rescue Mode
Appendix C: General Parameters and Modules


Appendix A: Installing Red Hat Linux

This appendix covers the Red Hat Linux installation process. However, it is not intended to be an exhaustive guide to installation. Installation is covered in detail in the Official Red Hat Linux User’s Guide (Red Hat Press/Wiley, 2003).

Which Installation Class Is Best For You?

Usually, Red Hat Linux is installed on its own disk partition or set of partitions, or over another installation of Linux.

Warning

Installing Red Hat Linux over another installation of Linux (including Red Hat Linux) does not preserve any information (files or data) from a prior installation. Make sure you save any important files, such as configuration files or your own important data! To preserve the current data on your existing system, you should back up your data and/or consider performing an upgrade instead.

The following installation types are available:

Personal Desktop

A personal desktop installation is most appropriate if you are new to the world of Linux and would like to give it a try. This installation will create a system for your home, laptop, or desktop use. A graphical environment will be installed.

Workstation

A workstation installation is most appropriate if you would like a graphical desktop environment, as well as software development tools.

Server

A server installation is most appropriate if you would like your system to function as a Linux-based server, and you do not want to heavily customize your system configuration.

Custom

A custom installation allows you the greatest flexibility during your installation. You choose your boot loader, which packages you want, and more. Custom installations are most appropriate for those users familiar with Red Hat Linux installations and for those concerned about losing complete flexibility.

Upgrade

If you already have a version of Red Hat Linux (6.2 or greater) running on your system and you want to quickly update to the latest packages and kernel version, then an upgrade is most appropriate for you.

These classes give you the option of simplifying the installation process (with some potential for loss of configuration flexibility), or retaining flexibility with a slightly more complex installation process. Next, take a detailed look at each class, so you can see which one is right for you.

Personal Desktop Installations

Most suitable for new users, the personal desktop installation will install a graphical desktop environment (the X Window System) and create a system ideal for home or business use. Following are the minimum recommended disk space requirements for a personal desktop installation where only one language (such as English) will be installed.

  • Personal Desktop: 1.5GB

  • Personal Desktop choosing both GNOME and KDE: 1.8GB

If you plan to choose all package groups (for example, the Office/Productivity Applications group is a group of related packages), as well as select additional individual packages, you may want to allow yourself 4GB or more of disk space.

What a Personal Desktop Installation Will Do

If you choose automatic partitioning, a personal desktop installation will create the following partitions:

  • A swap partition. The size of this swap partition is determined by the amount of RAM in your system and the amount of space available on your hard drive. For example, if you have 128MB of RAM, then the swap partition created can be 128MB to 256MB (twice your RAM), depending on how much disk space is available.

  • A 100MB partition mounted as /boot in which the Linux kernel and related files reside.

  • A root partition mounted as / in which all other files are stored (the exact size of this partition is dependent on your available disk space).

Workstation Installations

The workstation installation will install a graphical desktop environment and the X Window System, plus software development tools. Following are the minimum recommended disk space requirements for a workstation installation where only one language (such as English) will be installed.

  • Workstation: 2.0GB

  • Workstation choosing both GNOME and KDE: 2.3GB

If you plan to choose all package groups (for example, the Office/Productivity Applications group is a group of related packages), as well as select additional individual packages, you may want to allow yourself 4GB or more of disk space. If you provide this extra space, you will have room for additional data, if needed.

What a Workstation Installation Will Do

If you choose automatic partitioning, a workstation installation will create the following partitions:

  • A swap partition. The size of the swap partition is determined by the amount of RAM in your system and the amount of space available on your hard drive. For example, if you have 128MB of RAM, then the swap partition created can be 128MB to 256MB (twice your RAM), depending on how much disk space is available.

  • A 100MB partition mounted as /boot in which the Linux kernel and related files reside.

  • A root partition mounted as / in which all other files are stored (the exact size of this partition is dependent on your available disk space).

Server Installations

A server installation is most appropriate for you if you would like your system to function as a Linux-based server, and you do not want to heavily customize your system configuration. Following are the minimum recommended disk space requirements for a server installation where only one language (such as English) will be installed.

  • Server (minimum, no graphical interface): 1.3GB

  • Server (choosing everything, no graphical interface): 1.4GB

  • Server (choosing everything, including a graphical interface): 2.1GB

If you plan to choose all group packages, as well as select additional individual packages, you may want to allow yourself 2.3GB or more of disk space. During the server installation, the X Window System is not configured and no GUI will be loaded when the system boots, unless you choose to install the appropriate packages during package selection.

What a Server Installation Will Do

If you select the Server Installation option, the installation will include the following elements:

  • A swap partition. The size of this swap partition is determined by the amount of RAM on your system and the amount of space available on your hard drive. For example, if you have 128MB of RAM then the swap partition created can be 128MB to 256MB (twice your RAM), depending on how much disk space is available.

  • A 384MB root partition mounted as /.

  • A partition mounted as /usr (the exact size of this partition is dependent on your available disk space).

  • A partition mounted as /home (the exact size of this partition is dependent on your available disk space).

  • A 256MB partition mounted as /var.

  • A 100MB partition mounted as /boot in which the Linux kernel and related files are kept. This disk partitioning scheme results in a reasonably flexible file system configuration for most server tasks.

Custom Installations

The custom installation allows you the most flexibility during your installation. The workstation and server installations automatically go through the installation process for you and omit certain steps. During a custom installation, you have complete control over the packages that will be installed on your system. The recommended disk space requirements for a custom installation are as follows:

  • Custom (minimum): 400MB

  • Custom (choosing everything): 4.5GB

What a Custom Installation Will Do

As you might guess from the name, a custom installation puts the emphasis on flexibility. You have complete control over which packages will be installed on your system. If you choose automatic partitioning, a custom installation will create the following partitions:

  • A swap partition. The size of this swap partition is determined by the amount of RAM in your system and the amount of space available on your hard drive. For example, if you have 128MB of RAM then the swap partition created can be 128MB to 256MB (twice your RAM), depending on how much disk space is available.

  • A 100MB partition mounted as /boot in which the Linux kernel and related files reside.

  • A root partition mounted as / in which all other files are stored (the exact size of this partition is dependent on your available disk space).


Using Windows to Learn About Your Hardware

If your computer is already running Windows 9x, you can use the following steps to get additional configuration information:

  1. In Windows, click once on the My Computer icon using the secondary (typically the right) mouse button. A pop-up menu should appear.

  2. Select Properties. The System Properties window should appear. Note the information listed under Computer — in particular the amount of RAM listed.

  3. Click on the Device Manager tab. You will then see a graphical representation of your computer’s hardware configuration. Make sure the View devices by type radio button is selected.

    Click To expand
    Figure A-1: Windows 9x system properties

At this point, you can either double-click on the icons or single-click on the plus sign to look at each entry in more detail. Look under the following icons for more information:

  • Disk drives — the type (IDE or SCSI) of hard drive will be found here. (IDE drives will typically include the word “IDE,” while SCSI drives will not.)

  • Hard disk controllers — information about your hard-drive controller.

  • CDROM — information about any CD-ROM drives connected to your computer.

    Note

    In some cases, there may be no CD-ROM icon, yet your computer has a functioning CD-ROM drive. This is normal, depending on how Windows was originally installed. In this case, you may be able to get additional information by looking at the CD-ROM driver loaded in your computer’s config.sys file.

  • Mouse — the type of mouse present on your computer.

  • Display adapters — if you are interested in running the X Window System, you should write down the information you find here.

  • Sound, video, and game controllers — if your computer has sound capabilities, you will find information about them here.

  • Network adapters — information on your computer’s network card (if you have one).

  • SCSI controllers — if your computer uses SCSI peripherals, you will find information on the SCSI controller here.

    Click To expand
    Figure A-2: Windows 9x System Properties

This method is not a complete substitute for opening your computer’s case and physically examining each component. However, in many cases it can provide sufficient information to continue with the installation.

Note

This information can also be printed by clicking the Print button. A second window will appear, allowing you to choose the printer, as well as the type of report. The All Devices and System Summary report type is the most complete.

If your computer is already running Windows 2000, you can use the following steps to get configuration information:

  • In Windows, click once on the My Computer icon using the secondary (typically the right) mouse button. A pop-up menu should appear.

  • Select Properties. The System Properties window should appear. Note the information listed under Computer, in particular the amount of RAM listed.

  • Click on the Hardware tab. You will then see your computer’s hardware configuration options.

  • Click the Device Manager button. You will then see a graphical representation of your computer’s hardware configuration. Make sure the View devices by type radio button is selected.

At this point, you can either double-click on the icons or single-click on the plus sign to look at each entry in more detail. Look under the following icons for more information:

  • Disk drives — the type (IDE or SCSI) of hard drive will be found here. (IDE drives will typically include the word “IDE,” while SCSI drives will not.)

  • Hard disk controllers — information about your hard-drive controller.

  • CDROM — information about any CD-ROM drives connected to your computer.

  • Mouse — the type of mouse present on your computer.

  • Display adapters — if you are interested in running the X Window System, write down the information you find here.

  • Sound, video, and game controllers — if your computer has sound capabilities, you will find information about them here.

  • Network adapters — information on your computer’s network card (if you have one).

  • SCSI controllers — if your computer uses SCSI peripherals, you will find information on the SCSI controller here.

This method is not a complete substitute for opening your computer’s case and physically examining each component. However, in many cases it can provide sufficient information to continue with the installation.

Click To expand
Figure A-3: Windows 2000 System Properties
Click To expand
Figure A-4: Windows 2000 System Properties — Hardware
Click To expand
Figure A-5: Windows Device Manager


Recording Your System's Hardware

Team LiB

Recording Your System’s Hardware

Enter information about your system in the table provided as a handy reference to help make your Red Hat Linux installation go more smoothly.

Table A-1: System requirements table
hard drive(s): type, label, size; ex: IDE hda=1.2 GB |
partitions: map of partitions and mountpoints; ex: /dev/hda1=/home, /dev/hda2=/ (fill this in once you know where they will reside) | abcdefghijklmnopqrsjflksjfijdkjfhfksdkfjjiemfmm
memory: amount of RAM installed on your system; ex: 64 MB, 128 MB |
CD-ROM: interface type; ex: SCSI, IDE (ATAPI) |
SCSI adapter: if present, make and model number; ex: BusLogic SCSI Adapter, Adaptec 2940UW |
network card: if present, make and model number; ex: Tulip, 3COM 3C590 |
mouse: type, protocol, and number of buttons; ex: generic 3 button PS/2 mouse, MouseMan 2 button serial mouse |
monitor: make, model, and manufacturer specifications; ex: Optiquest Q53, ViewSonic G773 |
video card: make, model number and size of VRAM; ex: Creative Labs Graphics Blaster 3D, 8MB |
sound card: make, chipset and model number; ex: S3 SonicVibes, Sound Blaster 32/64 AWE IP, DHCP, and BOOTP |
addresses: four numbers, separated by dots; ex: 10.0.2.15 |
netmask: four numbers, separated by dots; ex: 255.255.248.0 |
gateway IP address: four numbers, separated by dots; ex: 10.0.2.245 |
one or more name server IP addresses (DNS): one or more sets of dot-separated numbers; ex: 10.0.2.1 |
domain name: the name given to your organization; ex: Red Hat’s would be redhat.com |
hostname: the name of your computer; your personal choice of names; ex: cookie, southpark |

If any of these networking requirements or terms are unfamiliar to you, contact your network administrator for assistance.


Installing Red Hat Linux

This section introduces the basic procedure used to install Red Hat Linux. It covers several topics:

  • Becoming familiar with the installation program’s user interface

  • Starting the installation program

  • Selecting an installation method

  • Working with various configuration steps during the installation (language, keyboard, mouse, etc.)

  • Finishing the installation


The Graphical Installation Program User Interface

If you have used a graphical user interface (GUI) before, you will be familiar with this process; simply use your mouse to navigate the screens, “click” buttons, or enter text fields. You can also navigate through the installation using the Tab and Enter keys.

Note

If you do not wish to use the GUI installation program, the text-mode installation program is also available. To start the text-mode installation program, use the following boot command: boot: text.

A Note about Virtual Consoles

The Red Hat Linux installation program offers more than the dialog boxes of the installation process. Several different kinds of diagnostic messages are available to you, in addition to a way to enter commands from a shell prompt. The installation program displays these messages on five virtual consoles, among which you can switch using a single keystroke combination.

These virtual consoles can be helpful if you encounter a problem while installing Red Hat Linux. Messages displayed on the installation or system consoles can help pinpoint a problem. Please see Table A-2 for a listing of the virtual consoles, keystrokes used to switch to them, and their contents. Generally, there is no reason to leave the default console (virtual console #7) unless you are attempting to diagnose installation problems.

Table A-2: Console, keystrokes, and contents
Console | Keystrokes | Contents
1 | Ctrl-Alt-F1 | installation dialog
2 | Ctrl-Alt-F2 | shell prompt
3 | Ctrl-Alt-F3 | install log (messages from installation program)
4 | Ctrl-Alt-F4 | system-related messages
5 | Ctrl-Alt-F5 | other messages
7 | Ctrl-Alt-F7 | X graphical display


Starting the Installation Program

To start the installation, you must first boot the installation program. Please make sure you have all the resources you will need for the installation.

Note

Occasionally, some hardware components require a driver diskette during the installation. A driver diskette adds support for hardware that is not otherwise supported by the installation program..

Booting the Installation Program

You can boot the Red Hat Linux installation program using any one of the following media (depending upon what your system can support):

  • Bootable CD-ROM — Your machine supports a bootable CD-ROM drive and you want to perform a local CD-ROM installation.

  • Local boot diskette — Your machine will not support a bootable CD-ROM and you want to install from a local CD-ROM or a hard drive.

  • Network boot diskette — Use a network boot diskette to install via NFS, FTP, or HTTP.

  • PCMCIA boot diskettes — Use PCMCIA boot diskettes when you need PCMCIA support, but your machine does not support booting from the CD-ROM drive or you need PCMCIA support in order to make use of the CD-ROM drive on your system. The PCMCIA boot diskettes can be used for all installation methods (CD-ROM, hard drive, NFS, FTP, and HTTP). To create a boot diskette, refer to the “Boot Disk Creation” section of this appendix.

Insert the boot diskette into your computer’s first diskette drive and reboot (or boot using the CD-ROM, if your computer supports booting from it). Your BIOS settings may need to be changed to allow you to boot from the diskette or CD-ROM.

After a short delay, a screen containing the boot: prompt should appear. The screen contains information on a variety of boot options. Each boot option also has one or more help screens associated with it. To access a help screen, press the appropriate function key as listed in the line at the bottom of the screen.

Tip

To change your BIOS settings, watch the instructions provided on your display when your computer first boots. You will see a line of text telling you to press the Del or F1 key to enter the BIOS settings. Once you have entered your BIOS setup program, find the section where you can alter your boot sequence. The default is often C, A or A, C (depending on whether you boot from your hard drive [C] or a diskette drive [A]). Change this sequence so that the CD-ROM is first in your boot order and that C or A (whichever is your typical boot default) is second. This instructs the computer to look first at the CD-ROM drive for bootable media; if it does not find bootable media on the CD-ROM drive, it will then check your hard drive or diskette drive. Save your changes before exiting the BIOS. For more information, refer to the documentation that came with your system.

As you boot the installation program, be aware of two issues:

  • Once you see the boot: prompt, the installation program will automatically begin if you take no action within the first minute. To disable this feature, press one of the help screen function keys.

  • If you press a help screen function key, there will be a slight delay while the help screen is read from the boot media.

Normally, you need only to press Enter to boot. Watch the boot messages to see if the Linux kernel detects your hardware. If your hardware is properly detected, please continue to the next section. If it does not properly detect your hardware, you may need to restart the installation in expert mode.

Additional Boot Options

While it is easiest for a user to boot from CD-ROM and perform a graphical installation, sometimes there are installation scenarios where booting in a different manner may be needed. This section discusses additional boot options available for Red Hat Linux.

Note

Refer to the “Alternative Boot Loaders” section of this appendix for additional boot options not covered in this section.

  • If you do not wish to perform a graphical installation, you can start a text-mode installation using the following boot command:

    boot: linux text

  • ISO images now have an md5sum embedded in them. To test the checksum integrity of an ISO image, type the following at the installation boot prompt:

    boot: linux mediacheck

The installation program will prompt you to insert a CD or select an ISO image to test. Select OK to perform the checksum operation. This checksum operation can be performed on any Red Hat Linux CD and does not have to be performed in a specific order (for example, CD #1 does not have to be the first CD you verify). It is strongly recommended that you perform this operation on any Red Hat Linux CD that was created from downloaded ISO images. This procedure works with CD-based installations and hard-drive and NFS installations using ISO images.

If the installation program does not properly detect your hardware, you may need to restart the installation in expert mode. Enter expert mode using the following boot command:

boot: linux noprobe

For text-mode installations, use:

boot: linux text noprobe

Expert mode disables most hardware probing and gives you the option of entering options for the drivers loaded during the installation. The initial boot messages will not contain any references to SCSI or network cards. This is normal; these devices are supported by modules that are loaded during the installation process.

If you need to perform the installation in serial mode, type the following command:

boot: linux console=device

For text mode installations, use:

boot: linux text console=device

In the above command, device should be the device you are using (such as ttyS0 or ttyS1). For example, linux text console=ttyS0,115200n8.

Kernel Options

Options can also be passed to the kernel. For example, to instruct the kernel to use all the RAM in a system with 128MB of RAM, enter:

boot: linux mem=128M

For text-mode installations, use:

boot: linux text mem=128M

After entering any options, press Enter to boot using those options.

If you need to specify boot options to identify your hardware, please write them down. The boot options will be needed during the boot loader configuration portion of the installation (please see the “Boot Loader Configuration” section later in this appendix for more information).

Booting without Diskettes

The Red Hat Linux CD-ROM can be booted by computers that support bootable CD-ROMs. Not all computers support this feature, so if your system cannot boot from the CD-ROM, there is one other way to start the installation without using a boot diskette. The following method is specific to x86-based computers only.

If you have MS-DOS installed on your system, you can boot directly from the CD-ROM drive without using a boot diskette. To do this (assuming your CD-ROM is drive D), use the following commands:

C:\ d:
D:\ cd \dosutils
D:\dosutils  autoboot.bat

This method will not work if run in a DOS window — the autoboot.bat file must be executed with DOS as the only operating system. In other words, Windows cannot be running.

If your computer cannot boot directly from CD-ROM (and you cannot use a DOS-based autoboot.bat), you will have to use a boot diskette to start the installation.


Selecting an Installation Method

What type of installation method do you wish to use? The following installation methods are available.

CD-ROM

If you have a CD-ROM drive and the Red Hat Linux CD-ROMs, you can use this method. You will need a boot diskette or a bootable CD-ROM. PCMCIA boot and driver diskettes may also be used. Refer to the “Installing from CD-ROM” section of this appendix for installation instructions.

Hard Drive

If you have copied the Red Hat Linux ISO images to a local hard drive, you can use this method. You will need a boot diskette. PCMCIA boot and driver diskettes may also be used. Refer to the “Installing from Hard Drive” section of this appendix for installation instructions.

NFS Image

If you are installing from an NFS server using ISO images or a mirror image of Red Hat Linux, you can use this method. You will need a network boot diskette. PCMCIA boot and driver diskettes may also be used. Refer to the “Installing from NFS” section of this appendix for installation instructions. NFS installations may also be performed in GUI mode.

FTP

If you are installing directly from an FTP server, use this method. You will need a network boot diskette. PCMCIA boot and driver diskettes may also be used. Refer to the “Installing from FTP” section of this appendix for installation instructions.

HTTP

If you are installing directly from an HTTP (Web) server, use this method. You will need a network boot diskette. PCMCIA boot and driver diskettes may also be used. Refer to the “Installing from HTTP” section of this appendix for installation instructions.


Installing from CD-ROM

To install Red Hat Linux from a CD-ROM, choose the CD-ROM option from the boot loader screen and select OK. When prompted, insert the Red Hat Linux CD in your CD-ROM drive (if you did not boot from the CD-ROM). Once the CD is in the CD-ROM drive, select OK and press Enter. The installation program will then probe your system and attempt to identify your CD-ROM drive. It will start by looking for an IDE (also known as an ATAPI) CD-ROM drive. If the drive is found, continue to the next stage of the installation process.

Note

If you already have another operating system installed and want to create a dual-boot system so that you can use both Red Hat Linux and the other operating system, see Chapter 1 for details.
Note

To abort the installation process at this time, reboot your machine and then eject the boot diskette or CD-ROM. You can safely cancel the installation at any point before the About to Install screen appears.

If your CD-ROM drive is not detected, and it is a SCSI CD-ROM, you can manually select the SCSI CD-ROM type when prompted. Select SCSI if your CD-ROM drive is attached to a supported SCSI adapter; the installation program will then ask you to choose a SCSI driver. Choose the driver that most closely resembles your adapter. You may specify options for the driver if necessary; however, most drivers will detect your SCSI adapter automatically.

What if the IDE CD-ROM Was Not Found?

If you have an IDE (ATAPI) CD-ROM, but the installation program fails to find your IDE (ATAPI) CD-ROM and asks you what type of CD-ROM drive you have, try the following.

Restart the installation, and at the boot: prompt enter linux hdX=cdrom. Replace the X with one of the following letters, depending on the interface the unit is connected to, and whether it is configured as master or slave (also known as primary and secondary):

  • a — first IDE controller, master

  • b — first IDE controller, slave

  • c — second IDE controller, master

  • d — second IDE controller, slave

If you have a third and/or fourth controller, continue assigning letters in alphabetical order, going from controller to controller, and master to slave.


Installing from a Hard Drive

Hard-drive installations require the use of the ISO (or CD-ROM) images. An ISO image is a file containing an exact copy of a CD-ROM disk image. Because Red Hat Linux has so many packages included with its distribution, several ISO images are available. After placing the required ISO images (the binary Red Hat Linux CD-ROMs) in a directory, choose to install from the hard drive. You will then point the installation program at that directory to perform the installation.

Note

Hard-drive installations work from ext2, ext3, or FAT file systems only. If you have a file system other than those listed here, such as reiserfs, you will not be able to perform a hard-drive installation.

Verifying that the ISO images are intact before you attempt an installation will help to avoid problems that are often encountered during a hard-drive installation. To verify the ISO images are intact prior to performing an installation, use an md5sum program (many md5sum programs are available for various operating systems). An md5sum program should be available on the same server as the ISO images.

Note

ISO images now have an md5sum embedded in them. To test the checksum integrity of an ISO image, at the installation boot prompt, type boot: linux mediacheck.

The Select Partition screen (Figure A-6) applies only if you are installing from a disk partition (that is, if you selected Hard Drive in the Installation Method dialog). This dialog allows you to name the disk partition and directory from which you are installing Red Hat Linux.

Click To expand
Figure A-6: Selecting Partition Dialog for Hard Drive Installation

Enter the device name of the partition containing the Red Hat ISO images. There is also a field labeled Directory holding images. If the ISO images are not in the root directory of that partition, enter the path to the ISO images (for example, if the ISO images are in /test/new/RedHat, you would enter /test/new).

After you have identified the disk partition, you will next see the Welcome dialog.


Preparing for a Network Installation

If you are performing a network installation and have booted from a boot disk with the bootnet.img image, the Configure TCP/IP dialog appears.

Setting Up the Server

Because the Red Hat Linux 8.0 installation program is capable of installing Red Hat Linux from multiple CD-ROMs, if you intend to support NFS, FTP, or HTTP installations you can copy the RedHat directory from each CD-ROM comprising Red Hat Linux 8.0 onto a disk drive (in other words, you must create an installation tree).

Tip

An installation tree is the location for all files needed to run and install the Red Hat Linux operating system. An ISO image is a file containing an exact copy of a CD-ROM disk image. Because Red Hat Linux has so many packages included with its distribution, there are several ISO images available. An installation tree differs from an ISO image in that ISO images are broken down into smaller subsets of files that the installation program then calls per ISO image, while an installation tree contains all the necessary files in one complete file structure. Individual ISO images can be combined to create an installation tree.

  • For each binary CD-ROM, execute the following commands:

    mount /mnt/cdrom
cp -var /mnt/cdrom/RedHat /location/of/disk/space (where
/location/of/disk/spaceis a directory you create, such as /export/8.0/)
umount /mnt/cdrom

  • Please note that the Release Notes are not included in the RedHat directory. Unless they are specifically copied over, the Release Notes will not be available during your installation of Red Hat Linux. The Release Notes are also available online at http://www.redhat.com/docs.

  • Next, make /location/of/disk/space accessible to the installation program (for example, exporting it for NFS installations) by editing the /etc/exports file and adding the line:

    /location/of/disk/space *(ro)

  • Finally, run the following command to make /location/of/disk/space available as read-only to each system to mount:

    /sbin/service nfs reload

Using ISO Images for NFS Installs

NFS installations can use ISO (or CD-ROM) images rather than have to copy an entire installation tree. After placing the required ISO images (the binary Red Hat Linux CD-ROMs) in a directory, choose to install via NFS. You will then point the installation program at that directory to perform the installation.

Verifying that the ISO images are intact before you attempt an installation will help to avoid problems that are often encountered during an NFS installation. To verify that the ISO images are intact prior to performing an installation, use an md5sum program (many md5sum programs are available for various operating systems). An md5sum program should be available on the same server as the ISO images.

Note

ISO images now have an md5sum embedded in them. To test the checksum integrity of an ISO image, at the installation boot prompt type boot: linux mediacheck.

Additionally, if a file called updates.img exists in the directory from which you install, it will be used for installation program updates. Refer to the file install-methods.txt in the anaconda RPM package for detailed information on the various ways to install Red Hat Linux, as well as how to apply the installation program updates.

Note

You can have the ISO images for only one release of Red Hat Linux in the directory.


Installing via NFS

The NFS dialog (Figure A-7) applies only if you are installing from an NFS server (if you booted from a network or PCMCIA boot disks and selected NFS Image in the Installation Method dialog). Enter the fully qualified domain name or IP address of your NFS server. For example, if you are installing from a host named eastcoast in the domain redhat.com, enter eastcoast.redhat.com in the NFS Server field.

Click To expand
Figure A-7: NFS Setup Dialog

Next, enter the name of the exported directory. If you followed the setup described in the previous section, you would enter the directory /location/of/disk/space/, which contains the RedHat directory. If the NFS server is exporting a mirror of the Red Hat Linux installation tree, enter the directory that contains the RedHat directory. (If you do not know this directory path, ask your system administrator.) For example, if your NFS server contains the directory /mirrors/redhat/i386/RedHat, enter /mirrors/redhat/i386.

If the NFS server is exporting the ISO images of the Red Hat Linux CD-ROMs, enter the directory that contains the ISO images. Next you will see the Welcome dialog.


Installing via FTP

The FTP dialog (Figure A-8) applies only if you are installing from an FTP server (if you selected FTP in the Installation Method dialog). This dialog allows you to identify the FTP server from which you are installing Red Hat Linux.

Click To expand
Figure A-8: FTP Setup Dialog

Enter the name or IP address of the FTP site you are installing from, and the name of the directory containing the RedHat installation files for your architecture. For example, if the FTP site contains the directory /mirrors/redhat/i386/RedHat, enter /mirrors/redhat/i386.

If everything has been specified properly, a message box appears indicating that base/hdlist is being retrieved. Next you will see the Welcome dialog.

Tip

You can also install Red Hat Linux using ISO images without copying them into a single tree by loopback mounting them as disc1/,disc2/,disc3/.


Installing via HTTP

The HTTP dialog (Figure A-9) applies only if you are installing from an HTTP server (if you selected HTTP in the Installation Method dialog). This dialog prompts you for information about the HTTP server from which you are installing Red Hat Linux. Enter the name or IP address of the HTTP site you are installing from, and the name of the directory there containing the Red Hat installation files for your architecture. For example, if the HTTP site contains the directory /mirrors/redhat/i386/RedHat, enter /mirrors/redhat/i386.

Click To expand
Figure A-9: HTTP Setup Dialog

If everything has been specified properly, a message box appears indicating that base/hdlist is being retrieved. Next you will see the Welcome dialog.

Tip

You can also install Red Hat Linux using ISO images without copying them into a single tree by loopback mounting them as disc1/,disc2/,disc3/.


Welcome to Red Hat Linux

The Welcome screen does not prompt you for any input. Please read over the help text in the left panel for additional instructions and information on where to register your Official Red Hat Linux product. Notice the Hide Help button at the bottom left corner of the screen. The help screen is open by default. If you do not want to view the help information, click on Hide Help to minimize the help portion of the screen. Click the Next button to continue.


Language Selection

Using your mouse, select the language you prefer to use for the installation (see Figure A-10). Selecting the appropriate language will also help target your time zone configuration later in the installation. The installation program will try to define the appropriate time zone based on what you specify on this screen.

Click To expand
Figure A-10: Language Selection

Once you select the appropriate language, click Next to continue.


Keyboard Configuration

Using your mouse, select the correct layout type (for example, U.S. English) for the keyboard you prefer to use for the installation and as the system default (see Figure A-11). Once you have made your selection, click Next to continue.

Tip

To change your keyboard layout type after you have completed the installation, use the Keyboard Configuration Tool. Type the redhat-config-keyboard command in a shell prompt to launch the Keyboard Configuration Tool. If you are not root, it will prompt you for the root password to continue.

Click To expand
Figure A-11: Keyboard Configuration


Mouse Configuration

Choose the correct mouse type for your system. If you cannot find an exact match, choose a mouse type that you are sure is compatible with your system (see Figure A-12). To determine your mouse’s interface, follow the mouse cable back to where it plugs into your system and use the following diagrams. If you are installing Red Hat Linux on a laptop computer, in most cases the pointing device will be PS/2 compatible.

Click To expand
Figure A-12: Mouse Configuration

  • The port for a serial mouse will look similar to:

  • The port for a PS/2 mouse will look similar to:

  • The port for a USB mouse will look similar to:

  • The port for an AT (Advanced Technology) mouse will look similar to:

If you cannot find a mouse that you are sure is compatible with your system, select one of the Generic entries, based on your mouse’s number of buttons, and its interface.

Tip

If you have a scroll mouse, select the MS IntelliMouse entry (with your proper mouse port) as the compatible mouse type.

If you have a PS/2, USB, or Bus mouse, you do not need to pick a port and device. If you have a serial mouse, choose the correct port and device that your serial mouse is on. The Emulate 3 buttons checkbox allows you to use a two-button mouse as if it had three buttons. In general, the graphical interface (the X Window System) is easier to use with a three-button mouse. If you select this checkbox, you can emulate a third, “middle” button by pressing both mouse buttons simultaneously.

Tip

To change your mouse configuration after you have completed the installation, use the Mouse Configuration Tool. Type the redhat-config-mouse command at a shell prompt to launch the Mouse Configuration Tool. If you are not root, it will prompt you for the root password to continue. To configure your mouse to work as a left-handed mouse, reset the order of the mouse buttons. To do this, after you have booted the system, type gpm -B 321 at the shell prompt.


Installation Type

Choose the type of installation you would like to perform (see Figure A-13). Red Hat Linux allows you to choose the installation type that best fits your needs. Your options are Personal Desktop, Workstation, Server, Custom, and Upgrade.

Click To expand
Figure A-13: Choosing Install or Upgrade

To perform an upgrade, please refer to the “What It Means to Upgrade” section of this appendix.


Disk Partitioning Setup

Partitioning allows you to divide your hard drive into isolated sections, where each section behaves as a separate hard drive. Partitioning is particularly useful if you run more than one operating system. If you are not sure how you want your system to be partitioned, read the “Recommended Partitioning Scheme” section of this appendix for more information.

On this screen, you can choose to perform automatic partitioning, or manual partitioning using Disk Druid or fdisk (see Figure A-14). Automatic partitioning allows you to perform an installation without having to partition your drive(s) yourself. If you do not feel comfortable with partitioning your system, it is recommended that you do not choose to partition manually and instead let the installation program partition for you. To partition manually, choose either the Disk Druid or fdisk (recommended for experts only) partitioning tool.

Click To expand
Figure A-14: Disk Partitioning Setup
Warning

The Red Hat Update Agent downloads updated packages to /var/spool/up2date by default. If you partition the system manually and create a separate /var partition, be sure to create the partition large enough to download package updates.

If you chose to manually partition using Disk Druid, continue to the next section. If you chose to manually partition using fdisk, refer to the “Partitioning with fdisk” section later in this appendix.


Automatic Partitioning

Automatic partitioning allows you to have some control over what data is removed (if any) from your system. Your options are:

  • Remove all Linux partitions on this system — select this option to remove only Linux partitions (i.e., partitions created from a previous Linux installation). This will not remove other partitions you may have on your hard drive(s), such as VFAT or FAT32 partitions.

  • Remove all partitions on this system — select this option to remove all partitions on your hard drive(s). This includes partitions created by other operating systems, such as Windows 9x/NT/2000 or NTFS partitions.

    Warning

    If you select this option, all data on the selected hard drive(s) will be removed by the installation program. Do not select this option if you have information that you want to keep on the hard drive(s) where you are installing Red Hat Linux.

  • Keep all partitions and use existing free space — select this option to retain your current data and partitions, assuming you have enough free space available on your hard drive(s).

Using your mouse, choose the hard drive(s) on which you want Red Hat Linux to be installed. If you have two or more hard drives, you can choose which hard drive(s) should contain this installation. Unselected hard drives, and any data on them, will not be touched.

Click To expand
Figure A-15: Automatic Partitioning

To review and make any necessary changes to the partitions created by automatic partitioning, select the Review option. After selecting Review and clicking Next to move forward, you will see the partitions created for you in Disk Druid. You will also be able to make modifications to these partitions if they do not meet your needs. Click Next once you have made your selections.


Partitioning Your System

If you chose automatic partitioning and did not select Review, please skip ahead to the “Adding Partitions” section of this appendix. If you chose automatic partitioning and selected Review, you can either accept the current partition settings (click Next) or modify the setup using Disk Druid, the manual partitioning tool. If you chose Manually partition with fdisk, please skip ahead to the “Partitioning with fdisk” section.

At this point, you must tell the installation program where to install Red Hat Linux. This is done by defining mount points for one or more disk partitions in which Red Hat Linux will be installed. You may also need to create and/or delete partitions at this time (refer to Figure A-16).

Click To expand
Figure A-16: Partitioning with Disk Druid
Note

If you have not yet planned how you will set up your partitions, refer to the “Recommended Partitioning Scheme” section of this appendix. At a bare minimum, you need an appropriately sized root partition and a swap partition equal to twice the amount of RAM you have on the system.

The partitioning tool used by the installation program is Disk Druid. With the exception of certain esoteric situations, Disk Druid can handle the partitioning requirements for a typical installation.

Graphical Display of Hard Drive(s)

Disk Druid offers a graphical representation of your hard drive(s). Using your mouse, click once to highlight a particular field in the graphical display. Double-click to edit an existing partition or to create a partition from existing free space.

Above the display, you will see the drive name (such as /dev/hda), the geom (which shows the hard disk’s geometry and consists of three numbers representing the number of cylinders, heads, and sectors as reported by the hard disk), and the model of the hard drive as detected by the installation program.

Disk Druid’s Buttons

The various buttons described in the following list control Disk Druid’s actions. They are used to change the attributes of a partition (for example, the file system type and mount point) and also to create RAID devices. Buttons on this screen are also used to accept the changes you have made, or to exit Disk Druid. For further explanation, take a look at each button in order:

  • New: Used to request a new partition. When selected, a dialog box appears containing fields (such as mount point and size) that must be filled in.

  • Edit: Used to modify attributes of the partition currently selected in the Partitions section. Selecting Edit opens a dialog box. Some or all of the fields can be edited, depending on whether or not the partition information has already been written to disk.

  • You can also edit free space as represented in the graphical display to create a new partition within that space. Either highlight the free space and then select the Edit button, or double-click on the free space to edit it.

  • Delete: Used to remove the partition currently highlighted in the Current Disk Partitions section. You will be asked to confirm the deletion of any partition.

  • Reset: Used to restore Disk Druid to its original state. All changes made will be lost if you Reset the partitions.

  • RAID: Used to provide redundancy to any or all disk partitions. It should be used only if you have experience using RAID. To read more about RAID, refer to Chapter 11. To make a RAID device, you must first create software RAID partitions. Once you have created two or more software RAID partitions, select RAID to join the software RAID partitions into a RAID device.

  • LVM: Allows you to create an LVM logical volume. The role of LVM (Logical Volume Manager) is to present a simple, logical view of underlying physical storage space, such as a hard drive(s). LVM manages individual physical disks — or, to be more precise, the individual partitions present on them. It should be used only if you have experience using LVM. To create an LVM logical volume, you must first create partitions of the type “physical volume (LVM).” Once you have created one or more physical volume (LVM) partitions, select LVM to create an LVM logical volume.

Partition Fields

Above the partition hierarchy are labels that present information about the partitions you are creating. The labels are defined as follows:

  • Device: This field displays the partition’s device name.

  • Mount Point/RAID/Volume: A mount point is the location within the directory hierarchy at which a volume exists; the volume is “mounted” at this location. This field indicates where the partition will be mounted. If a partition exists but is not set, you need to define its mount point. Double-click on the partition or click the Edit button.

  • Type: This field shows the partition’s type (for example, ext2, ext3, or vfat).

  • Format: This field shows if the partition being created will be formatted.

  • Size (MB): This field shows the partition’s size (in MB).

  • Start: This field shows the sector on your hard drive where the partition begins.

  • End: This field shows the sector on your hard drive where the partition ends.

  • Hide RAID device/LVM Volume Group members: Select this option if you do not want to view any RAID device or LVM Volume Group members that have been created.

Recommended Partitioning Scheme

Unless you have a reason for doing otherwise, Red Hat recommends that you create the following partitions:

  • A /swap partition (at least 32MB) — swap partitions are used to support virtual memory. In other words, data is written to a swap partition when there is not enough RAM to store the data your system is processing. The size of your swap partition should be equal to twice your computer’s RAM, or 32MB, whichever amount is larger. For example, if you have 1GB of RAM or less, your swap partition should be at least equal to the amount of RAM on your system, up to two times the RAM. For more than 1GB of RAM, 2GB of swap is recommended. Creating a large swap space partition will be especially helpful if you plan to upgrade your RAM at a later time.

  • A /boot partition (75MB) — the partition mounted on /boot contains the operating system kernel (which allows your system to boot Red Hat Linux), along with files used during the bootstrap process. Because of the limitations of most PC BIOSes, creating a small partition to hold these files is a good idea. For most users, a 75MB boot partition is sufficient.

    Warning

    Do not create your /boot partition as an LVM partition type. The boot loaders included with Red Hat Linux cannot read LVM partitions and you will not be able to boot your Red Hat Linux system.
    Warning

    If your hard drive is more than 1024 cylinders (and your system was manufactured before the turn of the century), you may need to create a /boot partition if you want the / (root) partition to use all of the remaining space on your hard drive.

  • A root partition (1.5–4.5GB) — this is where / (the root directory) will be located. In this setup, all files (except those stored in /boot) are on the root partition. A 1.5GB root partition will permit the equivalent of a personal desktop or workstation installation (with very little free space), while a 4.5GB root partition will let you install every package.

Adding Partitions

To add a new partition, select the New button. A dialog box appears (see Figure A-17).

Click To expand
Figure A-17: Creating a new partition
Note

You must dedicate at least one partition for this installation, and optionally more. For more information, see the “Recommended Partitioning Scheme” section above.

  • Mount Point: Enter the partition’s mount point. For example, if this partition should be the root partition, enter /; enter /boot for the /boot partition, and so on. You can also use the pull-down menu to choose the correct mount point for your partition.

  • File System Type: Using the pull-down menu, select the appropriate file system type for this partition. For more information on file system types, see the next section, “File System Types.”

  • Allowable Drives: This field contains a list of the hard disks installed on your system. If a hard disk’s box is highlighted, then a desired partition can be created on that hard disk. If the box is not checked, then the partition will never be created on that hard disk. By using different checkbox settings, you can have Disk Druid place partitions as you see fit, or let Disk Druid decide where partitions should go.

  • Size (Megs): Enter the size (in megabytes) of the partition. Note, this field starts with 100MB; unless this is changed, only a 100MB partition will be created.

  • Additional Size Options: Choose whether to keep this partition at a fixed size, to allow it to “grow” (fill up the available hard-drive space) to a certain point, or to allow it to grow to fill any remaining hard-drive space available. If you choose Fill all space up to (MB), you must give size constraints in the field to the right of this option. This allows you to keep a certain amount of space free on your hard drive for future use.

  • Force to be a primary partition: Select whether the partition you are creating should be one of the first four partitions on the hard drive. If unselected, the partition created will be a logical partition. See the “Recommended Partitioning Scheme” section earlier in this appendix for more information.

  • Check for bad blocks: Checking for bad blocks can help prevent data loss by locating the bad blocks on a drive and making a list of them to prevent use of them in the future. If you wish to check for bad blocks while formatting each file system, please make sure to select this option. Selecting Check for bad blocks may dramatically increase your total installation time. Since most newer hard drives are quite large, checking for bad blocks may take a long time; the length of time depends on the size of your hard drive. If you choose to check for bad blocks, you can monitor your progress on virtual console #6.

  • Ok: Select Ok once you are satisfied with the settings and wish to create the partition.

  • Cancel: Select Cancel if you do not want to create the partition.

File System Types

Red Hat Linux allows you to create different partition types, based on the file system they will use. The following is a brief description of the different file systems available, and how they can be utilized.

  • ext2 — An ext2 file system supports standard UNIX file types (regular files, directories, symbolic links, etc). It provides the ability to assign long file names, up to 255 characters. Versions prior to Red Hat Linux 7.2 used ext2 file systems by default.

  • ext3 — The ext3 file system is based on the ext2 file system and has one main advantage — journaling. Using a journaling file system reduces time spent recovering a file system after a crash as there is no need to fsck the file system. The ext3 file system will selected by default and is highly recommended.

    Note

    The fsck application is used to check the file system for metadata consistency and optionally to repair one or more Linux file systems.

  • physical volume (LVM) — Creating one or more physical volume (LVM) partitions allows you to create an LVM logical volume.

  • software RAID — Creating two or more software RAID partitions allows you to create a RAID device. For more information regarding RAID, refer to Chapter 11.

  • swap — Swap partitions are used to support virtual memory. In other words, data is written to a swap partition when there is not enough RAM to store the data your system is processing.

  • vfat — The VFAT file system is a Linux file system that is compatible with Windows 9x/NT long file names on the FAT file system.

Editing Partitions

To edit a partition, select the Edit button or double-click the existing partition.

Note

If the partition already exists on your hard disk, you will be able to change only the partition’s mount point. If you want to make any other changes, you will need to delete the partition and re-create it.

Deleting a Partition

To delete a partition, highlight it in the Partitions section and click the Delete button. You will be asked to confirm the deletion. Skip to the “Boot Loader Configuration” section for further installation instructions.


Partitioning with fdisk

This section applies only if you chose to use fdisk to partition your system. To partition your system without using fdisk, please return to the start of the “Partitioning Your Disk” section. If you have already completed disk partitioning, skip to the “Boot Loader Configuration” section for further installation instructions.

Warning

Unless you have previously used fdisk and understand how it works, we do not recommend that you use it. It is much easier for new users to accidentally corrupt or lose data using fdisk. Disk Druid is easier to understand than fdisk. To exit fdisk, click Back to return to the previous screen, deselect fdisk, and then click Next.

If you have chosen to use fdisk, the next screen will prompt you to select a drive to partition using fdisk. Once you have chosen which drive to partition, you will be presented with the fdisk command screen. If you do not know what command to use, type m at the prompt for help. When you are finished making partitions, type w to save your changes and quit. You will be taken back to the original fdisk screen, where you can partition another drive or continue the installation.

Note

None of the changes you make take effect until you save them and exit fdisk using the w command. You can quit fdisk at any time without saving changes using the q command.

After you have partitioned your drive(s), click Next. You will need to use Disk Druid to assign mount points to the partitions you just created with fdisk. You will not be able to add new partitions using Disk Druid, but you can edit mount points for the partitions you have already created. For each partition created with fdisk, click the Edit button, choose the appropriate mount point for that partition from the pull-down menu, and click OK.


Boot Loader Configuration

In order to boot the system without a boot diskette, you usually need to install a boot loader. A boot loader is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the operating system kernel software. The kernel, in turn, initializes the rest of the operating system. The installation program provides two boot loaders for you to choose from, GRUB and LILO.

GRUB (GRand Unified Bootloader), which is installed by default, is a very powerful boot loader. GRUB can load a variety of free operating systems, as well as proprietary operating systems, with chain loading (the mechanism for loading unsupported operating systems by loading another boot loader, such as DOS or Windows). LILO (LInux LOader) is a versatile boot loader for Linux. It does not depend on a specific file system, can boot Linux kernel images from floppy diskettes and hard disks, and can even boot other operating systems.

Click To expand
Figure A-18: Boot Loader Configuration

If you do not want to install GRUB as your boot loader, click Change boot loader. You can then choose to install LILO or choose not to install a boot loader at all.

If you already have a boot loader that can boot Linux and do not want to overwrite your current boot loader, or if you plan to boot the system using boot diskettes, choose Do not install a boot loader by clicking the Change boot loader button.

Warning

If you choose not to install GRUB or LILO for any reason, you will not be able to boot the system directly, and you will need to use another boot method (such as a boot diskette). Use this option only if you are sure you have another way of booting the system.

Every bootable partition is listed, including partitions used by other operating systems. The partition holding your system’s root file system will have a label of Red Hat Linux (for GRUB) or linux (for LILO). Other partitions may also have boot labels. If you would like to add or change the boot label for other partitions that have been detected by the installation program, click once on the partition to select it. Once it’s been selected, you can change the boot label by clicking the Edit button.

Select Default beside the preferred boot partition to choose your default bootable OS. You will not be able to move forward in the installation unless you choose a default boot image.

Note

The Label column lists what you must enter at the boot prompt, in nongraphical boot loaders, in order to boot the desired operating system. Once you have loaded the GRUB boot screen, use the arrow keys to choose a boot label or type e for edit. You will be presented with a list of items in the configuration file for the boot label you have selected. At the graphical LILO screen, press Ctrl-x to exit to the boot: prompt. If you forget the boot labels defined on your system, you can always press Tab at the prompt to display a list of defined boot labels.

Boot loader passwords provide a security mechanism in an environment where physical access to your server is available. If you are installing a boot loader, create a password to protect your system. Without a boot loader password, users with access to your system can pass options to the kernel that can compromise your system security. With a boot loader password in place, the password must first be entered in order to select any nonstandard boot options.

If you choose to use a boot loader password to enhance your system security, be sure to select the checkbox labeled Use a boot loader password. Once it has been selected, enter a password and confirm it. To configure more advance boot loader options, such as changing the drive order or passing options to the kernel, be sure that Configure advanced boot loader options is selected before clicking Next.

Advanced Boot Loader Configuration

Now that you have chosen which boot loader to install, you can also determine where you want the boot loader to be installed. You may install the boot loader in one of two places.

The master boot record (MBR)

This is the recommended place to install a boot loader, unless the MBR already starts another operating system loader, such as System Commander. The MBR is a special area on your hard drive that is automatically loaded by your computer’s BIOS and is the earliest point at which the boot loader can take control of the boot process. If you install it in the MBR, when your machine boots, GRUB (or LILO) will present a boot prompt. You can then boot Red Hat Linux or any other operating system that you have configured the boot loader to boot.

The first sector of your boot partition

This is recommended if you are already using another boot loader on your system. In this case, your other boot loader will take control first. You can then configure that boot loader to start GRUB (or LILO), which will then boot Red Hat Linux.

If your system will use only Red Hat Linux, you should choose the MBR. For systems with Windows 95/98, you should also install the boot loader to the MBR so that it can boot both operating systems. Click the Change Drive Order button if you would like to rearrange the drive order. Changing the drive order may be useful if you have multiple SCSI adapters or both SCSI and IDE adapters and want to boot from the SCSI device.

Click To expand
Figure A-19: Boot Loader Installation

The Force LBA32 (not normally required) option allows you to exceed the 1024 cylinder limit for the /boot partition. If you have a system that supports the LBA32 extension for booting operating systems above the 1024-cylinder limit, and you want to place your /boot partition above cylinder 1024, select this option. If you wish to add default options to the boot command, enter them into the Kernel parameters field. Any options you enter will be passed to the Linux kernel every time it boots.

Rescue Mode

If you need to use rescue mode, there are several options available to you.

  • Using the CD-ROM to boot, type linux rescue at the boot: prompt.

  • By booting your system from an installation boot diskette made from the boot.img image. This method requires that the Red Hat Linux CD-ROM #1 be inserted as the rescue image or that the rescue image be on the hard drive as an ISO image. Once you have booted using this diskette, type linux rescue at the boot: prompt.

  • By booting from a network diskette made from the bootnet.img or PCMCIA boot diskettes made from pcmcia.img. Once you have booted using this diskette, type linux rescue at the boot: prompt. You can do this only if your network connection is working. You will need to identify the network host and transfer type. For an explanation of how to specify this information, see Appendix B.

Alternative Boot Loaders

If you do not wish to use a boot loader, you have several alternatives.

Boot diskette

You can use the boot diskette created by the installation program (if you create one).

LOADLIN

You can load Linux from MS-DOS. Unfortunately, this requires that a copy of the Linux kernel (and an initial RAM disk, if you have a SCSI adapter) be available on an MS-DOS partition. The only way to accomplish this is to boot your Red Hat Linux system using some other method (for example, from a boot diskette) and then copy the kernel to an MS-DOS partition. LOADLIN is available from ftp://metalab.unc.edu/pub/Linux/system/boot/dualboot/ and associated mirror sites.

SYSLINUX

SYSLINUX is an MS-DOS program very similar to LOADLIN. It is also available from ftp://metalab.unc.edu/pub/Linux/system/boot/loaders/ and associated mirror sites.

Commercial boot loaders

You can load Linux using commercial boot loaders. For example, System Commander and Partition Magic are able to boot Linux (but still require that GRUB or LILO be installed in your Linux root partition).

Note

Boot loaders such as LOADLIN and System Commander are considered to be third-party boot loaders and are not supported by Red Hat.

SMP Motherboards, GRUB, and LILO

This section is specific to SMP motherboards only. SMP, short for Symmetric Multiprocessing, is a computer architecture providing fast performance by making multiple CPUs available to complete individual processes simultaneously (multiprocessing). If the installation program detects an SMP motherboard on your system, it will automatically create two boot loader entries.

Note

Intel Pentium 4 systems with hyperthreading will have an SMP kernel installed by default.

The two GRUB entries will be Red Hat Linux (kernel version) and Red Hat Linux (kernel version-smp). The Red Hat Linux (kernel version-smp) entry will boot by default. However, if you have trouble with the SMP kernel, you can elect to boot the Red Hat Linux (kernel version) entry instead. You will retain all the functionality as before, but you will be operating with only a single processor.

The two LILO entries will be linux and linux-up. The linux entry will boot by default. However, if you have trouble with the SMP kernel, you can elect to boot the linux-up entry instead. You will retain all the functionality as before, but you will be operating with only a single processor.


Network Configuration

If you do not have a network device, you will not see this screen. Skip ahead to the “Firewall Configuration” section. If you have a network device and you have not already configured your networking (such as booting from a network boot disk you created and entering your network information as prompted), you now have the opportunity (as shown in Figure A-20) to do so.

Click To expand
Figure A-20: Network Configuration

The installation program will automatically detect any network devices you have and display them in the Network Devices list. Once you have selected a network device, click Edit. From the Edit Interface pop-up screen, you can choose to configure the IP address and Netmask of the device via DHCP (or manually if DHCP is not selected) and you can choose to activate the device at boot time. If you select Activate on boot, your network interface will be started when you boot. If you do not have DHCP client access or you are unsure what to provide here, please contact your network administrator.

Note

Do not use the numbers as seen in this sample configuration. These values will not work for your own network configuration. If you are not sure what values to enter, contact your network administrator for assistance.

If you have a hostname (fully qualified domain name) for the network device, you can choose to have DHCP (Dynamic Host Configuration Protocol) automatically detect it, or you can manually enter the hostname in the field provided. Finally, if you entered the IP and Netmask information manually, you may also enter the Gateway address and the Primary, Secondary, and Tertiary DNS addresses.

Figure A-21: Editing a Network Device
Tip

Even if your computer is not part of a network, you can enter a hostname for your system. If you do not take this opportunity to enter a name, your system will be known as localhost.
Tip

To change your network configuration after you have completed the installation, use the Network Administration Tool. Type the redhat-config-network command in a shell prompt to launch the Network Administration Tool. If you are not root, it will prompt you for the root password to continue.


Firewall Configuration

Red Hat Linux offers firewall protection for enhanced system security. A firewall exists between your computer and the network and determines which resources on your computer remote users on the network can access. A properly configured firewall can greatly increase the security of your system.

Click To expand
Figure A-22: Firewall Configuration

Choose the appropriate security level for your system.

High

If you choose High, your system will not accept connections (other than the default settings) that are not explicitly defined by you. By default, only the following connections are allowed:

  • DNS replies

  • DHCP — so any network interfaces that use DHCP can be properly configured

If you choose High, your firewall will not allow the following:

  • Active mode FTP (passive mode FTP, used by default in most clients, should still work)

  • IRC DCC file transfers

  • RealAudio

  • Remote X Window System clients

If you are connecting your system to the Internet, but do not plan to run a server, this is the safest choice. If additional services are needed, you can choose Customize to allow specific services through the firewall.

Note

If you select a medium- or high-level firewall during this installation, network authentication methods (NIS and LDAP) will not work.

Medium

If you choose Medium, your firewall will not allow remote machines to have access to certain resources on your system. By default, access to the following resources are not allowed:

  • Ports lower than 1023 — the standard reserved ports, used by most system services, such as FTP, SSH, telnet, HTTP, and NIS

  • The NFS server port (2049) — NFS is disabled for both remote servers and local clients

  • The local X Window System display for remote X clients

  • The X Font server port (by default, xfs does not listen on the network; it is disabled in the font server)

If you want to allow resources such as RealAudio while still blocking access to normal system services, choose Medium. Select Customize to allow specific services through the firewall.

Note

If you select a medium- or high-level firewall during this installation, network authentication methods (NIS and LDAP) will not work.

No Firewall

No firewall provides complete access to your system and does no security checking. Security checking is the disabling of access to certain services. This should be selected only if you are running on a trusted network (not the Internet) or plan to do more firewall configuration later. Choose Customize to add trusted devices or to allow additional incoming services.

Trusted Devices

Selecting any of the Trusted Devices allows access to your system for all traffic from that device; it is excluded from the firewall rules. For example, if you are running a local network but are connected to the Internet via a PPP dial-up, you can check eth0 and any traffic coming from your local network will be allowed. Selecting eth0 as trusted means all traffic over the Ethernet is allowed, but the ppp0 interface is still firewalled. If you want to restrict traffic on an interface, leave it unchecked. It is not recommended that you make any device that is connected to public networks, such as the Internet, a Trusted Device.

Allow Incoming

Enabling these options allow the specified services to pass through the firewall. Note that during a workstation installation, the majority of these services are not installed on the system.

DHCP

If you allow incoming DHCP queries and replies, you allow any network interface that uses DHCP to determine its IP address. DHCP is normally enabled. If DHCP is not enabled, your computer can no longer get an IP address.

SSH

SSH (Secure SHell) is a suite of tools for logging in to and executing commands on a remote machine. If you plan to use SSH tools to access your machine through a firewall, enable this option. You need to have the openssh-server package installed in order to access your machine remotely, using SSH tools.

Telnet

Telnet is a protocol for logging in to remote machines. Telnet communications are unencrypted and provide no security from network snooping. Allowing incoming Telnet access is not recommended. If you do want to allow inbound Telnet access, you will need to install the telnet-server package.

WWW (HTTP)

The HTTP protocol is used by Apache (and by other Web servers) to serve Web pages. If you plan on making your Web server publicly available, enable this option. This option is not required for viewing pages locally or for developing Web pages. You will need to install the httpd package if you want to serve Web pages. Enabling WWW (HTTP) will not open a port for HTTPS. To enable HTTPS, specify it in the Other ports field.

Mail (SMTP)

If you want to allow incoming mail delivery through your firewall, so that remote hosts can connect directly to your machine to deliver mail, enable this option. You do not need to enable this if you collect your mail from your ISP’s server using POP3 or IMAP, or if you use a tool such as Fetchmail.

Warning

An improperly configured SMTP server can allow remote machines to use your server to send spam.

FTP

The FTP protocol is used to transfer files between machines on a network. If you plan on making your FTP server publicly available, enable this option. You need to install the wu-ftpd package (and possibly the anonftp package) for this option to be useful.

Other ports

You can allow access to ports that are not listed here by listing them in the Other ports field. Use the following format: port:protocol. For example, if you want to allow IMAP access through your firewall, specify imap:tcp. You can also explicitly specify numeric ports; to allow UDP packets on port 1234 through the firewall, specify 1234:udp. To specify multiple ports, separate them with commas.

Tip

To change your security-level configuration after you have completed the installation, use the Security Level Configuration Tool. Type the redhat-config-securitylevel command in a shell prompt to launch the Security Level Configuration Tool. If you are not root, it will prompt you for the root password to continue.


Language Support Selection

Red Hat Linux can install and support multiple languages for use on your system. You must select a language to use as the default language. The default language will be used on the system once the installation is complete. If you choose to install other languages during this installation, you can change your default language after the installation. If you are going to use only one language on your system, selecting only that language will save significant disk space. The default language is the language you selected to use during the installation.

To use more than one language on your system, choose specific languages to be installed or select all languages to have all available languages installed on your Red Hat Linux system. Use the Reset button to cancel your selections. Resetting will revert to the default; only the language you selected for use during the installation will be installed.

Warning

If you select only one language, you will be able to use only that specified language after the installation is complete.
Tip

To change the language configuration after you have completed the installation, use the Language Configuration Tool. Type the redhat-config-language command in a shell prompt to launch the Language Configuration Tool. If you are not root, it will prompt you for the root password to continue.

Click To expand
Figure A-23: Language Support Selection


Time Zone Configuration

You can set your time zone by selecting your computer’s physical location or by specifying your time zone’s offset from Universal Time, Coordinated (UTC). Notice the two tabs at the top of the screen (see Figure A-24). The first tab allows you to configure your time zone by your location. On the interactive map, you can also click on a specific city, which is marked by a yellow dot; a red X will appear indicating your selection. You can also scroll through a list and choose a time zone. The second tab allows you to specify a UTC offset. The tab displays a list of offsets to choose from, as well as an option to set Daylight Savings Time.

Click To expand
Figure A-24: Configuring the Time Zone

On both tabs, you can select System Clock uses UTC. Select this if you know that your system is set to UTC.

Tip

To change your time zone configuration after you have completed the installation, use the Time and Date Properties Tool. Type the redhat-config-date command in a shell prompt to launch the Time and Date Properties Tool. If you are not root, it will prompt you for the root password to continue.


Account Configuration

The Account Configuration screen allows you to set your root password. Additionally, you can set up user accounts for you to log in to once the installation is complete (see Figure A-25).

Click To expand
Figure A-25: Account Creation

Setting the Root Password

Setting up a root account and password is one of the most important steps during your installation. Your root account is similar to the administrator account used on Windows NT machines. The root account is used to install packages, upgrade RPMs, and perform most system maintenance. Logging in as root gives you complete control over your system.

Note

The root user (also known as the superuser) has complete access to the entire system; for this reason, logging in as the root user is best done only to perform system maintenance or administration.

Use the root account only for system administration. Create a non-root account for your general use and su - to root when you need to fix something quickly. These basic rules will minimize the chances of a typo or an incorrect command doing damage to your system.

Tip

To become root, type su - at the shell prompt in a terminal window and then press Enter. Then, enter the root password and press Enter.

The installation program will prompt you to set a root password for your system. You must enter a root password. The installation program will not let you proceed to the next step without entering a root password.

Note

A root password is the administrative password for your Red Hat Linux system. You should log in as root only when needed for system maintenance. The root account does not operate within the restrictions placed on normal user accounts, so changes made as root can have implications for your entire system.

The root password must be at least six characters long; the password you type is not echoed to the screen. You must enter the password twice; if the two passwords do not match, the installation program will ask you to enter them again. You should make the root password something you can remember, but not something that is easy for someone else to guess. Your name, your phone number, qwerty, password, root, 123456, and anteater are all examples of bad passwords. Good passwords mix numerals with upper- and lowercase letters and do not contain dictionary words: Aard387vark or 420BMttNT, for example. Remember that the password is case-sensitive. If you write down your password, keep it in a secure place. However, it is recommended that you do not write down this or any password you create.

Note

Do not use one of the example passwords offered in this book. Using one of these passwords could be considered a security risk.
Tip

To change your root password after you have completed the installation, use the Root Password Tool. Type the redhat-config-rootpassword command in a shell prompt to launch the Root Password Tool. If you are not root, it will prompt you for the root password to continue.

Setting Up User Accounts

If you choose to create a user account now, you will have an account to log in to once the installation has completed. This allows you to safely and easily log in to your computer without having to be root to create your user account.

Click the Add button to add a new, non-root, user. Enter a user name for the user account. Next, enter and confirm a password for that user account. Enter the full name of the account user and click OK. Your account information will be added to the account list. You can also edit or delete the user accounts you have created but no longer want.

Figure A-26: Creating a User Account
Tip

To change your user account configuration after you have completed the installation, use the User Manager. Type the redhat-config-users command in a shell prompt to launch the User Manager. If you are not root, it will prompt you for the root password to continue.


Authentication Configuration

If you are performing a personal desktop, workstation, or server installation, please skip ahead to the “Package Group Selection” section. You may also skip this section if you will not be setting up network passwords. If you do not know whether you should do this, please ask your system administrator for assistance.

Unless you are setting up NIS authentication, you will notice that only MD5 and shadow passwords are selected (see Figure A-27). We recommend you use both to make your machine as secure as possible. To configure the NIS option, you must be connected to an NIS network. If you are not sure whether you are connected to an NIS network, please ask your system administrator.

Click To expand
Figure A-27: Authentication Configuration

  • Enable MD5 passwords — allows a long password to be used (up to 256 characters), instead of the standard eight characters or less.

  • Enable shadow passwords — provides a secure method for retaining passwords. The passwords are stored in /etc/shadow, which can be read only by root.

  • Enable NIS — allows you to run a group of computers in the same Network Information Service domain with a common password and group file. You can choose from the following options:

    • NIS Domain — allows you to specify the domain or group of computers your system belongs to

    • Use broadcast to find NIS server — allows you to broadcast a message to your local area network to find an available NIS server

    • NIS Server — causes your computer to use a specific NIS server, rather than broadcast a message to the local area network asking for any available server to host your system.

      Note

      If you have selected a medium- or high-level firewall during this installation, network authentication methods (NIS and LDAP) will not work.

  • Enable LDAP — tells your computer to use LDAP for some or all authentication. LDAP consolidates certain types of information within your organization. For example, all of the different lists of users within your organization can be merged into one LDAP directory. For more information about LDAP, refer to Chapter 17. You can choose from the following options:

    • LDAP Server — allows you to access a specified server (by providing an IP address) running the LDAP protocol

    • LDAP Base DN — allows you to look up user information by its Distinguished Name (DN)

    • Use TLS (Transport Layer Security) lookups —allows LDAP to send encrypted user names and passwords to an LDAP server before authentication

  • Enable Kerberos — Kerberos is a secure system for providing network authentication services. For more information about Kerberos, see Chapter 23. There are three options to choose from here:

    • Realm —allows you to access a network that uses Kerberos, composed of one or a few servers (also known as KDCs) and a potentially large number of clients

    • KDC —allows you access to the Key Distribution Center (KDC), a machine that issues Kerberos tickets (sometimes called a Ticket Granting Server or TGS)

    • Admin Server —allows you to access a server running kadmind

  • Enable SMB Authentication — sets up PAM to use an SMB server to authenticate users. You must supply two pieces of information here:

    • SMB Server — indicates which SMB server your workstation will connect to for authentication

    • SMB Workgroup — indicates which workgroup the configured SMB servers are in

      Tip

      To change your authentication configuration after you have completed the installation, use the authconfig command. Type the authconfig command at a shell prompt. If you are not root, it will prompt you for the root password to continue.


Package Group Selection

After your partitions have been selected and configured for formatting, you are ready to select packages for installation.

Note

Unless you chose a custom installation, the installation program will automatically choose most packages for you.

You can select package groups, which group components together according to function (for example, X Window System, Editors), individual packages, or a combination of the two. To select a component, click the checkbox beside it (see Figure A-28).

Click To expand
Figure A-28: Package Group Selection

Select each component you wish to install. Selecting Everything (at the end of the component list) during a custom installation installs all packages included with Red Hat Linux. Once a package group has been selected, click on Details to view which packages will be installed by default and to add optional packages to or remove them from that group.

To select packages individually, check the Select Individual Packages box at the bottom of the screen.

Click To expand
Figure A-29: Package Group Details

Selecting Individual Packages

After selecting the components you wish to install, you can select or deselect individual packages using your mouse (see Figure A-30). You can choose to view the individual packages in Tree View or Flat View. Tree View allows you to see the packages grouped by application type. Flat View allows you to see all of the packages in an alphabetical listing on the right of the screen.

Click To expand
Figure A-30: Selecting individual packages

Using Tree View, you see a listing of package groups. When you expand this list (by double-clicking the folder arrow beside a package group name) and pick one group, the list of packages in that group appears in the panel on the right. Flat View allows you to see all of the packages in an alphabetical listing on the right of the screen. To sort packages alphabetically, click the Package tab. To sort packages by size, click the Size (MB) tab.

To select an individual package, double-click the checkbox beside the package name. A check mark in the box means that a package has been selected. For more information about a specific package, click on the individual package name. The package information will appear at the bottom of the screen. You can also select or deselect all packages listed within a particular group by clicking on the Select all in group or Unselect all in group buttons.

Note

Some packages (such as the kernel and certain libraries) are required for every system and are not available to select or deselect. These base packages are selected by default.

Unresolved Dependencies

Many software packages, in order to work correctly, depend on other software packages that must be installed on your system. For example, many of the graphical Red Hat system administration tools require the python and pythonlib packages. To make sure your system has all the packages it needs in order to be fully functional, the installation program checks these package dependencies each time you install or remove software packages.

If any package requires another package that you have not selected to install, the program presents a list of these unresolved dependencies and gives you the opportunity to resolve them (see Figure A-31). The Unresolved Dependencies screen appears only if you are missing packages that are needed by the packages you have selected. At the bottom of the screen, under the list of missing packages, an Install packages to satisfy dependencies checkbox is selected by default. If you leave this checked, the installation program will resolve dependencies automatically by adding all required packages to the list of selected packages.

Click To expand
Figure A-31: Unresolved Dependencies

If you do not wish to install packages that require other packages, select Do not install packages that have dependencies. To install only the packages you have selected and leave the dependencies unresolved, select Ignore package dependencies.

Tip

To install or remove packages after you have completed the installation, use the Package Management Tool. Type the redhat-config-packages command at a shell prompt to launch the Package Management Tool. If you are not root, it will prompt you for the root password to continue.


Preparing to Install

You should now see a screen preparing you for the installation of Red Hat Linux. For your reference, a complete log of your installation can be found in /root/install.log once you reboot your system.

Warning

If, for some reason, you would rather not continue with the installation process, this is your last opportunity to safely cancel the process and reboot your machine. Once you press the Next button, partitions will be written and packages will be installed. If you wish to abort the installation, you should reboot now before any existing information on any hard drive is overwritten.

To cancel this installation process, press your computer’s Reset button or use the Control-Alt-Del key combination to restart your machine.


Installing Packages

At this point there is nothing left for you to do until all the packages have been installed (see Figure A-32). How quickly this happens depends on the number of packages you have selected and your computer’s speed.

Click To expand
Figure A-32: Installing packages


Boot Disk Creation

To create a boot disk, insert a blank, formatted diskette into your diskette drive (see Figure A-33) and click Next. It is highly recommended that you create a boot disk. If for some reason your system is not able to boot properly using GRUB, LILO, or a third-party boot loader, a boot disk will enable you to properly boot your Red Hat Linux system.

Click To expand
Figure A-33: Creating your boot disk

After a short delay, your boot disk will be created; remove it from your diskette drive and label it clearly. Note that if you would like to create a boot disk after the installation, you will be able to do so. For more information, please see the mkbootdisk man page by typing man mkbootdisk at the shell prompt. If you do not want to create a boot disk, make sure to select the appropriate option before you click Next.

If you boot your system with the boot disk (instead of with GRUB or LILO) , make sure you create a new boot disk whenever you make any changes to your kernel (including the installation of a new kernel).


Video Card Configuration

The installation program will now present a list of video cards for you to choose from. If you decided to install the X Window System packages, you now have the opportunity to configure an X server for your system. If you did not choose to install the X Window System packages, skip ahead to “Configuring Your Monitor.”

If your video card does not appear on the list (see Figure A-34), X may not support it. However, if you have technical knowledge about your card, you may choose Unlisted Card and attempt to configure it by matching your card’s video chipset with one of the available X servers.

Click To expand
Figure A-34: Video card setup

Next, enter the amount of video memory installed on your video card. If you are not sure, consult the documentation accompanying your video card. You will not damage your video card by choosing more memory than is available, but the X server may not start correctly if you do. If you decide that the values you have selected are incorrect, you can click the Restore original values button to return to the suggested settings. You can also select Skip X Configuration if you would rather configure X after the installation or not at all.

Tip

To change your X configuration after you have completed the installation, use the X Configuration Tool. Type the redhat-config-xfree86 command at a shell prompt to launch the X Configuration Tool. If you are not root, it will prompt you for the root password to continue.


X Configuration: Monitor and Customization

In order to complete X configuration, you must configure your monitor and customize your X settings. If you chose to skip X configuration, go to the next section., “Configuring Your Monitor.”

Configuring Your Monitor

The installation program will present you with a list of monitors to select from. From this list, you can either use the monitor that is automatically detected for you, or choose another monitor.

Note

If you are installing Red Hat Linux on a laptop with an LCD screen, select the most appropriate Generic model available.

If your monitor does not appear on the list, select the most appropriate Generic model available. If you select a Generic monitor, the installation program will suggest horizontal and vertical sync ranges. These values are generally available in the documentation that accompanies your monitor, or from your monitor’s vendor or manufacturer; please check your documentation to make sure these values are set correctly.

Warning

Do not select a monitor similar to your monitor unless you are certain that the monitor you are selecting does not exceed the capabilities of your monitor. Doing so may overclock your monitor and damage or destroy it.

The horizontal and vertical ranges that the installation program suggests for the selected monitor are also displayed below the list of monitors. If you decide that your monitor selection or the horizontal and vertical ranges are incorrect, you can click the Restore original values button to return to the original suggested settings. Click Next when you have finished configuring your monitor.

Custom Configuration

Choose the correct color depth and resolution for your X configuration. Click Test Setting to try out this configuration. If you do not like what you see during the test, click No to choose another resolution.

Note

If you need to exit the X configuration test, use the Ctrl-Alt-Backspace key combination. This will not work in some test cases.

It is recommended that you test your configuration to make sure the resolution and color settings are usable. You can also choose whether you want to boot your system into a graphical or text environment once the installation is complete. Unless you have special needs, booting into a graphical environment (similar to a Windows environment) is recommended. If you choose to boot into a text environment, you will be presented with a command prompt (similar to a DOS environment).

Click To expand
Figure A-35: Monitor selection
Tip

To change your X configuration after you have completed the installation, use the X Configuration Tool. Type the redhat-config-xfree86 command at a shell prompt to launch the X Configuration Tool. If you are not root, it will prompt you for the root password to continue.

Click To expand
Figure A-36: X Customization
Tip

To change your X configuration after you have completed the installation, use the X Configuration Tool. Type the redhat-config-xfree86 command at a shell prompt to launch the X Configuration Tool. If you are not root, it will prompt you for the root password to continue.


Installation Complete

Congratulations! Your Red Hat Linux 8.0 installation is now complete! The installation program will prompt you to prepare your system for reboot. Remember to remove any installation media (diskette in the diskette drive or CD in the CD-ROM drive) if they are not ejected automatically upon reboot. If you do not have a boot loader installed and configured, you will need to use the boot disk you created during the installation now.

After your computer’s normal power-up sequence has completed, you should see the graphical boot loader prompt, at which you can do any of the following things:

  • Press Enter — causes the default boot entry to be booted.

  • Select a boot label, followed by Enter — causes the boot loader to boot the operating system corresponding to the boot label. (Type ? or press Tab at LILO’s text-mode boot loader prompt for a list of valid boot labels.)

  • Do nothing — after the boot loader’s timeout period (by default, five seconds), the boot loader will automatically boot the default boot entry.

Do whatever is appropriate to boot Red Hat Linux. You should see one or more screens of messages scroll by. Eventually, you should see a login: prompt or a GUI login screen (if you installed the X Window System and chose to start X automatically).

Tip

If you are not sure what to do next, we suggest you begin with the Official Red Hat Linux User’s Guide (Red Hat Press/Wiley, 2003), which covers topics relating to the basics of your system and is an introduction to using Red Hat Linux.


What It Means to Upgrade

The installation process for Red Hat Linux 8.0 includes the ability to upgrade from prior versions of Red Hat Linux (version 6.2 and later) that are based on RPM technology. Upgrading your system installs the modular 2.4.x kernel as well as updated versions of the packages that are currently installed on your system.

The upgrade process preserves existing configuration files by renaming them with an .rpmsave extension (for example, sendmail.cf.rpmsave). The upgrade process also creates a log of its actions in /root/upgrade.log. As software evolves, configuration file formats can change, so you should carefully compare your original configuration files to the new files before integrating your changes.

Some upgraded packages may require the installation of other packages for proper operation. If you choose to customize your packages to upgrade, you may be required to resolve dependency problems. Otherwise, the upgrade procedure takes care of these dependencies, but it may need to install additional packages that are not on your system.

Depending on how you have partitioned your system, the upgrade program may prompt you to add an additional swap file. If the upgrade program does not detect a swap file that equals twice your RAM, it will ask you if you would like to add a new swap file. If your system does not have a lot of RAM (less than 32MB), it is recommended that you add this swap file.


Upgrading Your System

At this point, you should have chosen Upgrade as your preferred installation type (see Figure A-37).

Click To expand
Figure A-37: Choosing Install or Upgrade


Upgrading Your File System

If the installation program detects the ext2 file system on your Red Hat Linux system, you can choose to retain your current ext2 file system or migrate to the ext3 file system. Following is a brief description of the ext2 and ext3 file systems and how they can be utilized.

Note

This section pertains only to users performing an upgrade from Red Hat Linux version 7.1 or earlier, or from a Red Hat Linux 7.2 or 7.3 installation where ext2 was chosen as the file system.

ext2

An ext2 file system supports standard UNIX file types (regular files, directories, symbolic links, etc). It provides the ability to assign long file names, up to 255 characters. Versions prior to Red Hat Linux 8.0 used ext2 file systems by default.

ext3

The ext3 file system is based on the ext2 file system and has one main advantage — journaling. Using a journaling file system reduces time spent recovering a file system after a crash as there is no need to fsck1the file system. It is recommended, but not required, that you choose to migrate to the ext3 file system. If you choose to migrate to the ext3 file system, existing system data will not be modified.

Note

The fsck application is used to check and optionally to repair one or more Linux file systems.


Customizing Your Upgrade

Do you want to choose the packages to be upgraded or let the installation program perform an automated upgrade (see Figure A-38)?

Click To expand
Figure A-38: Upgrade Customization

To perform an automated upgrade, click Next.

To customize your packages for this upgrade, select the Customize packages to be upgraded option and click Next.


Boot Loader Configuration

A software boot loader is used to start Red Hat Linux on your computer. It can also start other operating systems, such as Windows. If you are using a Red Hat Linux software boot loader (GRUB or LILO), it will be detected automatically.

On the Boot Loader Configuration Screen, your options are:

  • Update boot loader configuration — Choose this option to keep your current boot loader configuration (GRUB or LILO depending on what you have currently installed) and have updates applied.

  • Skip boot loader updating — Choose this option if you do not want to make any changes to your current boot loader configuration. If you are using a third-party boot loader, you will want to skip updating your boot loader.

  • Create new boot loader configuration — Choose this option if you want to create a new boot loader for your system. If you currently have LILO and want to switch to GRUB, or if you have been using boot diskettes to boot your Red Hat Linux system and want to use a software boot loader such as GRUB or LILO, you will want to create a new boot loader configuration (see Chapter 1 for more information).

Once you have made your selection, click Next to continue.

Creating a New Boot Loader Configuration

In order to boot the system without a boot diskette, you usually need to install a boot loader. A boot loader is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the operating system kernel software. The kernel, in turn, initializes the rest of the operating system. The installation program provides two boot loaders for you to choose from, GRUB and LILO.

GRUB (GRand Unified Bootloader), which is installed by default, is a very powerful boot loader. GRUB can load a variety of free operating systems, as well as proprietary operating systems, with chain loading (the mechanism for loading unsupported operating systems by loading another boot loader, such as DOS or Windows). LILO (LInux LOader) is a versatile boot loader for Linux. It does not depend on a specific file system, can boot Linux kernel images from floppy diskettes and hard disks, and can even boot other operating systems. If you do not want to install GRUB as your boot loader, click Change boot loader. You can then choose to install LILO or choose not to install a boot loader at all.

If you already have a boot loader that can boot Linux and do not want to overwrite your current boot loader, or if you plan to boot the system using boot diskettes, choose Do not install a boot loader by clicking on the Change boot loader button.

Warning

If you choose not to install GRUB or LILO for any reason, you will not be able to boot the system directly, and you will need to use another boot method (such as a boot diskette). Use this option only if you are sure you have another way of booting the system!

Every bootable partition is listed, including partitions used by other operating systems. The partition holding the system’s root file system will have a Label of Red Hat Linux (for GRUB) or linux (for LILO). Other partitions may also have boot labels. If you would like to add or change the boot label for other partitions that have been detected by the installation program, click once on the partition to select it. Once it’s selected, you can change the boot label by clicking the Edit button. Select Default beside the preferred boot partition to choose your default bootable OS. You will not be able to move forward in the installation unless you choose a default boot image.

Note

The Label column lists what you must enter at the boot prompt, in nongraphical boot loaders, in order to boot the desired operating system. Once you have loaded the GRUB boot screen, use the arrow keys to choose a boot label or type e for edit. You will be presented with a list of items in the configuration file for the boot label you have selected. At the graphical LILO screen, press Ctrl-x to exit to the boot: prompt. If you forget the boot labels defined on your system, you can always press Tab at the prompt to display a list of defined boot labels.

Boot loader passwords provide a security mechanism in an environment where physical access to your server is available. If you are installing a boot loader, you should create a password to protect your system. Without a boot loader password, users with access to your system can pass options to the kernel that can compromise your system security. With a boot loader password in place, the password must first be entered in order to select any nonstandard boot options. If you choose to use a boot loader password to enhance your system security, be sure to select the checkbox labeled Use a boot loader password. Once it’s selected, enter a password and confirm it.

To configure more advanced boot loader options, such as changing the drive order or passing options to the kernel, be sure that Configure advanced boot loader options is selected before clicking Next.

Advanced Boot Loader Configuration

Now that you have chosen which boot loader to install, you can also determine where you want the boot loader to be installed. You may install the boot loader in one of two places.

The master boot record (MBR)

This is the recommended place to install a boot loader, unless the MBR already starts another operating system loader, such as System Commander. The MBR is a special area on your hard drive that is automatically loaded by your computer’s BIOS and is the earliest point at which the boot loader can take control of the boot process. If you install it in the MBR, when your machine boots, GRUB (or LILO) will present a boot prompt. You can then boot Red Hat Linux or any other operating system that you have configured the boot loader to boot.

The first sector of your boot partition

This is recommended if you are already using another boot loader on your system. In this case, your other boot loader will take control first. You can then configure that boot loader to start GRUB (or LILO), which will then boot Red Hat Linux.

If your system will use only Red Hat Linux, you should choose the MBR. For systems with Windows 9x, you should also install the boot loader to the MBR so that it can boot both operating systems. Click the Change Drive Order button if you would like to rearrange the drive order. Changing the drive order may be useful if you have multiple SCSI adapters or both SCSI and IDE adapters and want to boot from the SCSI device.

The Force LBA32 (not normally required) option allows you to exceed the 1024-cylinder limit for the /boot partition. If you have a system that supports the LBA32 extension for booting operating systems above the 1024-cylinder limit and you want to place your /boot partition above cylinder 1024, select this option. If you wish to add default options to the boot command, enter them in the Kernel parameters field. Any options you enter will be passed to the Linux kernel every time it boots.


Selecting Packages to Upgrade

On this screen, you can choose which packages you would like to upgrade. You can choose to view the individual packages in Tree View or Flat View. Tree View allows you to see the packages grouped by application type. Flat View allows you to see all of the packages in an alphabetical listing on the right of the screen. Using Tree View, you see a listing of package groups. When you expand this list (by double-clicking on the folder arrow beside a package group name) and pick one group, the list of packages in that group appears in the panel on the right. Flat View allows you to see all of the packages in an alphabetical listing on the right of the screen.

To sort packages alphabetically, click on the Package tab. To sort packages by size, click the Size (MB) tab. To select an individual package, click the checkbox beside the package name. A check mark in the box means that a package has been selected. For more information about a specific package, click on the individual package name. The package information will appear at the bottom of the screen. You can also select or deselect all packages listed within a particular group by clicking on the Select all in group or Unselect all in group buttons. Certain packages (for example, the kernel and certain libraries) are required for every Red Hat Linux system and are not available to select or deselect. These base packages are selected by default.

Unresolved Dependencies

If any package requires another package that you have not selected to install, the program presents a list of these unresolved dependencies and gives you the opportunity to resolve them. The Unresolved Dependencies screen appears only if you are missing packages that are needed by your customized package selection. At the bottom of the screen, under the list of missing packages, an Install packages to satisfy dependencies radio button is selected by default. If you leave this selected, the installation program will resolve package dependencies automatically by adding all required packages to the list of selected packages.

If you do not wish to install packages that require other packages, select Do not install packages that have dependencies. To install only the packages you have selected and leave the dependencies unresolved, select Ignore package dependencies.

Tip

To install or remove packages after you have completed the installation, use the Package Management Tool. Type the redhat-config-packages command at a shell prompt to launch the Package Management Tool. If you are not root, it will prompt you for the root password to continue.


Upgrading Packages

At this point there is nothing left for you to do until all the packages have been upgraded or installed.


Boot Diskette Creation

To create a boot diskette, insert a blank, formatted diskette into your diskette drive and click Next. It is highly recommended that you create a boot diskette. If, for some reason your system is not able to boot properly using GRUB, LILO, or a third-party boot loader, a boot diskette will enable you to properly boot your Red Hat Linux system.

After a short delay, your boot diskette will be created; remove it from your diskette drive and label it clearly. Note that if you would like to create a boot diskette after the installation, you will be able to do so. For more information, please see the mkbootdisk man page by typing man mkbootdisk at the shell prompt. If you do not want to create a boot diskette, make sure to select the appropriate option before you click Next.

If you boot your system with the boot diskette (instead of with GRUB or LILO), make sure you create a new boot diskette whenever you make any changes to your kernel (including the installation of a new kernel).


Upgrade Complete

Congratulations! Your Red Hat Linux 8.0 upgrade is now complete! You will now be prompted to prepare your system for reboot. Do not forget to remove any diskette in the floppy drive or CD in the CD-ROM drive if they are not ejected automatically upon reboot. If you do not have a boot loader installed and configured, you will need to use your boot diskette now.

Tip

If you need a quick review of some of the basic Linux concepts of Red Hat Linux, refer to the Official Red Hat Linux User’s Guide (Red Hat Press/Wiley, 2003).

To uninstall Red Hat Linux from your system, you will need to remove the GRUB or LILO information from your master boot record (MBR). In DOS, Windows NT, and Windows 95, you can use fdisk to create a new MBR with the undocumented flag /mbr. This will only rewrite the MBR to boot the primary DOS partition. The command should look like the following:

fdisk /mbr

If you need to remove Linux from a hard drive and have attempted to do this with the default DOS fdisk, you will experience the Partitions exist but they do not exist problem. The best way to remove non-DOS partitions is with a tool that understands partitions other than DOS. You can do this with the installation media by typing the following at the boot: prompt:

boot: linux expert

Select Install (i.e., not Upgrade) and at the point when you should partition the drive, choose fdisk. In fdisk, type p to print out the partition numbers, and remove the Linux partitions with the d command. When you are satisfied with the changes you have made, you can quit with a w, and the changes will be saved to disk. If you deleted too much, type q, and no changes will be made. Once you have removed the Linux partitions, you can reboot your computer using Control-Alt-Del instead of continuing with the install.


Appendix B: Rescue Mode

When things go wrong, there are ways to fix problems. However, these methods require that you understand the system well. This appendix describes how to boot into rescue mode and single-user mode, where you can use your own knowledge to repair the system.

What Is Rescue Mode?

Rescue mode provides the ability to boot a small Linux environment entirely from a diskette or CD-ROM, or via some other method. As the name implies, rescue mode is provided to rescue you from something. During normal operation, your Red Hat Linux system uses files located on your system’s hard drive to do everything — run programs, store your files, and more.

However, there may be times when you are unable to get Linux running completely enough to access its files on your system’s hard drive. Using rescue mode, you can access the files stored on your system’s hard drive, even if you cannot actually run Linux from that hard drive. Normally, you will need to get into rescue mode for one of two reasons:

  • You are unable to boot Linux.

  • You are having hardware or software problems, and you want to get a few important files off your system’s hard drive.

Next, we take a closer look at each of these scenarios.

Unable to Boot Linux

This problem is often caused by the installation of another operating system after you have installed Red Hat Linux. Some other operating systems assume that you have no other operating systems on your computer, and they overwrite the Master Boot Record (MBR) that originally contained the GRUB or LILO boot loader. If the boot loader is overwritten in this manner, you will not be able to boot Red Hat Linux unless you can get into rescue mode.

Another common problem occurs when using a partitioning tool to resize a partition or create a new partition from free space after installation and the tool changes the order of your partitions. If the number of your / partition changes, the boot loader will not be able to find it to mount the partition. To fix this problem, boot in rescue mode and modify /boot/grub/grub.conf if you are using GRUB or /etc/lilo.conf if you are using LILO.

Hardware/Software Problems

This category includes a wide variety of different situations. Two examples include failing hard drives and failing to run LILO after building a new kernel (if you are using LILO as your boot loader). If you are using GRUB, you do not have to execute a command to reread the GRUB configuration file.

However, if you specify an invalid root device or kernel in the GRUB configuration file, you might not know it until you reboot your computer. In these situations, you may be unable to boot Red Hat Linux. If you can get into rescue mode, you might be able to resolve the problem or at least get copies of your most important files.


Booting Rescue Mode

To start your system in rescue mode, boot from a Red Hat Linux boot disk or the Red Hat Linux CD-ROM #1, and enter the following command at the installation boot prompt:

boot: linux rescue

You can get to the installation boot prompt in one of these ways:

  • By booting your system from an installation boot diskette made from the boot.img image. This method requires that the Red Hat Linux CD-ROM #1 be inserted as the rescue image or that the rescue image be on the hard drive as an ISO image. To create an installation boot diskette, insert a blank floppy disk and use the images/boot.img file on the Red Hat Linux CD-ROM #1 with the command dd if=boot.img of=/dev/fd0.

  • By booting your system from the Red Hat Linux CD-ROM #1.

  • By booting from a network disk made from the bootnet.img or PCMCIA boot disk made from pcmcia.img. You can do this only if your network connection is working. You will need to identify the network host and transfer type. For an explanation of how to specify this information, refer to the Official Red Hat Linux User’s Guide (Red Hat Press/Wiley, 2003).

After booting off a boot disk or Red Hat Linux CD-ROM #1 and providing a valid rescue image, you will see the following message:

The rescue environment will now attempt to find your Red Hat Linux
installation and mount it under the directory /mnt/sysimage. You can
then make any changes required to your system. If you want to proceed
with this step choose 'Continue'. You can also choose to mount your
filesystem read-only instead of read-write by choosing 'Read-only'.

If for some reason this process fails, you can choose “Skip.” This step will be skipped and you will go directly to a command shell.

If you select Continue, the rescue diskette will attempt to mount your file system under the directory /mnt/sysimage. If the rescue process fails to mount a partition, it will notify you. If you select Read-Only, the rescue process will attempt to mount your file system under the directory /mnt/sysimage, but in read-only mode. If you select Skip, your file system will not be mounted. Choose Skip if you think your file system is corrupted.

Once you have your system in rescue mode, a prompt appears on VC (virtual console) 1 and VC 2 (use the Ctrl-Alt-F1 key combination to access VC 1 and Ctrl-Alt-F2 to access VC 2):

sh-2.05a#

If you selected Continue to mount your partitions automatically and they were mounted successfully, you are in single-user mode. To mount a Linux partition manually inside rescue mode, create a directory such as /foo and type the following command:

mount -t ext3 /dev/hda5 /foo

In the above command, /foo is a directory that you have created and /dev/hda5 is the partition you want to mount. If the partition is of type ext2, replace ext3 with ext2. If you do not know the names of your partitions, use the following command to list them:

fdisk -l

If your file system is mounted and you want to make your system the root partition, use the command chroot /mnt/sysimage. This is useful if you need to run commands such as rpm that require your root partition to be mounted as /. To exit the chroot environment, type exit, and you will return to the prompt.

From the bash# prompt, you can run many useful commands including:

anaconda          gzip        mkfs.ext2       probe
badblocks         head        mknod           ps
bash              hwclock     mkraid          python2.2
cat               ifconfig    mkswap          raidstart
chattr            init        mlabel          raidstop
chmod             insmod      mmd             rcp
chroot            less        mmount          rlogin
clock             ln          mmove           rm
collage           loader      modprobe        rmmod
cp                ls          mount           route
cpio              lsattr      mpartition      rpm
dd                lsmod       mrd             rsh
ddcprobe          mattrib     mread           sed
depmode           mbadblocks  mren            sh
df                mcd         mshowfat        sync
e2fsck            mcopy       mt              tac
fdisk             mdel        mtools          tail
fsck              mdeltree    mtype           tar
fsck.ext2         mdir        mv              touch
fsck.ext3         mdu         mzip            traceroute
ftp               mformat     open            umount
gnome-pty-helper  minfo       parted          uncpio
grep              mkdir       pico            uniq
gunzip            mke2fs      ping            zcat


Booting into Single-User Mode

You may be able to boot into single-user mode directly. If your system boots but does not allow you to log in when it has completed booting, try single-user mode. If you are using GRUB, use the following steps to boot into single-user mode:

  1. If you have a GRUB password configured, type p and enter the password.

  2. Select Red Hat Linux with the version of the kernel that you wish to boot and type e for edit. You will be presented with a list of items in the configuration file for the kernel you just selected.

  3. Select the line that starts with kernel and type e to edit the line.

  4. Go to the end of the line and type single as a separate word (press the Spacebar and then type single). Press Enter to exit edit mode.

  5. Back at the GRUB screen, type b to boot into single-user mode.

If you are using LILO, specify one of these options at the LILO boot prompt (if you are using the graphical LILO, you must press Ctrl-x to exit the graphical screen and go to the boot: prompt):

boot: linux single
boot: linux emergency

In single-user mode, your computer boots to runlevel 1. Your local file systems will be mounted, but your network will not be activated. You will have a usable system maintenance shell.

In emergency mode, you are booted into the most minimal environment possible. The root file system will be mounted read-only, and almost nothing will be set up. The main advantage of emergency mode over linux single is that your init files are not loaded. If init is corrupted or not working, you can still mount file systems to recover data that could be lost during a reinstallation.

Have you ever rebuilt a kernel and, eager to try out your handiwork, rebooted before running /sbin/lilo? If you did not have an entry for an older kernel in lilo.conf, you had a problem. If you want to know a solution to this problem, read this section.

In many cases, you can boot your Red Hat Linux system from the Red Hat Linux boot disk 1 with your root file system mounted and ready to go. Here is how to do it:

Enter the following command at the boot disk’s boot: prompt:

linux single root=/dev/hdXX initrd=

Replace the XX in /dev/hdXX with the appropriate letter and number for your root partition.

What does this command do? First, it starts the boot process in single-user mode, with the root partition set to your root partition. The empty initrd specification bypasses the installation-related image on the boot disk, which will cause you to enter single-user mode immediately.

Is there a negative side to using this technique? Unfortunately, yes. Because the kernel on the Red Hat Linux boot disk has support only for IDE built-in, if your system is SCSI-based you will not be able to do this. In that case, you will have to access rescue mode using the linux rescue command mentioned above.


Appendix C: General Parameters and Modules

This appendix is provided to illustrate some of the possible parameters available for some common hardware device drivers. A driver is software enabling your system to use a particular hardware device. Without the driver, the kernel may not know how to access the device correctly. In most cases, these additional parameters are unnecessary, since the kernel may already be able to use the device without them. You should use the settings provided in this appendix only if you are having trouble getting Red Hat Linux to use a particular device or you need to override the system’s default parameters for the device.

During the installation of Red Hat Linux, some limits are placed on file systems and some device drivers supported by the kernel. After installation, however, support exists for all file systems available under Linux. At the time of installation, the modularized kernel has support for (E)IDE devices (including ATAPI CD-ROM drives), SCSI adapters, and network cards.

Note

Because Red Hat Linux supports installation on many different types of hardware, some drivers (including those for SCSI adapters, network cards, and many CD-ROMs) are not built into the Linux kernel used by the installation program. Rather, they are available as modules and are loaded as you need them during the installation process. If necessary, you will have the chance to specify options for these modules when they are loaded from the driver disk.

To specify module parameters when a driver is loaded, type linux expert at the boot: prompt and insert the driver disk when prompted to do so by the installation program. After reading the driver disk, the installation program will ask you to select the type of device you are configuring. On that screen, you can elect to specify a module parameter. Then, the installation program will display a screen where you can type the correct parameters based on the particular type of device you are configuring.

After the installation is complete, you may want to rebuild a kernel that includes support for your specific hardware configuration. Note that in most cases, a custom-built kernel is not necessary.

Cross-reference

See Chapter 12 for more information about rebuilding your kernel.

Specifying Module Parameters

If you are providing parameters upon loading a module, you can usually specify them using one of two methods:

  • Specify a full set of parameters in one statement. For example, the parameter cdu31=0x340,0 could be used with a Sony CDU 31 or 33 at port 340 with no IRQ.

  • Specify the parameters individually. This method is used when one or more parameters in the first set are not needed. For example, cdu31_port=0x340 cdu31a_irq=0 can be used as the parameter for the same CD-ROM used as an example for the first method. An OR is used in the CD-ROM, SCSI, and Ethernet tables in this appendix to show where the first parameter method stops and the second method begins.

    Note

    Use only one method, not both, when loading a module with particular parameters.
    Warning

    When a parameter has commas, make sure you do not put a space after a comma.


CD-ROM Module Parameters

Even though parameters are specified after loading the driver disk and specifying the device, one of the more commonly used parameters (hdX=cdrom) can be entered at the boot prompt (boot:) during installation. This exception to the rule is allowed since it deals with support for IDE/ATAPI CD-ROMs, which is already part of the kernel.

Note

Not all of the CD-ROM drives that are listed in Table C-1 are supported. Please check the Hardware Compatibility List on Red Hat’s website at http://hardware.redhat.com to make sure your CD-ROM drive is supported.

In the following tables, most modules listed without any parameters can either be auto-probed to find the hardware or they require you to manually change settings in the module source code and recompile.

Table C-1: Hardware parameters
Hardware | Module | Parameters
ATAPI/IDE CD-ROM Drives |  | hdX=cdrom
Aztech CD268-01A, Orchid CD-3110, Okano/Wearnes CDD110, Conrad TXC, CyCDROM CR520, CyCDROM CR540 (non-IDE) | Aztcd.o | aztcd=io_port
Sony CDU-31A CD-ROM | Cdu31a.o | cdu31a=io_port,IRQ OR cdu31a_port=base_addr cdu31a_irq=irq
Philips/LMS CDROM drive 206 with cm260 host adapter card | cm206.o | cm206=io_port,IRQ
Goldstar R420 CD-ROM | gscd.o | gscd=io_port
ISP16, MAD16, or Mozart sound card CD-ROM interface (OPTi 82C928 and OPTi 82C929) with Sanyo/Panasonic, Sony, or Mitsumi drives | isp16.o | isp16=io_port,IRQ,dma, drive_type OR isp16_cdrom_base=io_port isp16_cdrom_irq=IRQ isp16_cdrom_dma=dma isp16_cdrom_type=drive_type
Mitsumi CD-ROM, Standard | mcd.o | mcd=io_port,IRQ
Mitsumi CD-ROM, Experimental | mcdx.o | mcdx=io_port_1,IRQ_1, io_port_n,IRQ_n
Optics storage 8000 AT “Dolphin” drive, Lasermate CR328A | optcd.o |
Parallel-Port IDE CD-ROM | pcd.o |
SB Pro 16 Compatible | sbpcd.o | sbpcd=io_port
Sanyo CDR-H94A | sjcd.o | sjcd=io_port OR sjcd_base=io_port
Sony CDU-535 & 531 (some Procomm drives) | sonycd535.o | sonycd535=io_port

Table C-2 shows some examples of these modules in use.

Table C-2: Hardware parameters configuration examples
Configuration | Example
ATAPI CD-ROM, jumpered as master on the second IDE channel | hdc=cdrom
non-IDE Mitsumi CD-ROM on port 340, IRQ 11 | mcd=0x340,11
Three non-IDE Mitsumi CD-ROM drives using the experimental driver, io ports 300, 304, and 320 with IRQs 5, 10 and 11 | mcdx=0x300,5,0x304,10,0x320,11
Sony CDU 31 or 33 at port 340, no IRQ | cdu31=0x340,0 OR cdu31_port=0x340 cdu31a_irq=0
Aztech CD-ROM at port 220 | aztcd=0x220
Panasonic-type CD-ROM on a SoundBlaster interface at port 230 | sbpcd=0x230,1
Phillips/LMS cm206 and cm260 at IO 340 and IRQ 11 | cm206=0x340,11
Goldstar R420 at IO 300 | gscd=0x300
Mitsumi drive on a MAD16 soundcard at IO Addr 330 and IRQ1, probing DMA | isp16=0x330,11,0,Mitsumi
Sony CDU 531 at IO address 320 | sonycd535=0x320
Note

Most newer Sound Blaster cards come with IDE interfaces. For these cards, you do not need to use sbpcd parameters; use only hdX parameters.

Table C-3: SCSI Parameters
Hardware | Module | Parameters
Adaptec 28xx, R9xx, 39xx | aic7xxx.o |
3ware Storage Controller | 3w-xxxx.o |
NCR53c810/820/720, NCR53c700/710/700-66 | 53c7,8xx.o |
AM53/79C974 (PC-SCSI) Driver | AM53C974.o |
Most Buslogic (now Mylex) cards with “BT” part number | BusLogic.o |
Mylex DAC960 RAID Controller | DAC960.o |
MCR53c406a-based SCSI | NCR53c406a.o |
Initio INI-A100U2W | a100u2w.o | a100u2w=io,IRQ,scsi_id
Adaptec AACRAID | aacraid.o |
Advansys SCSI Cards | advansys.o |
Adaptec AHA-152x | aha152x.o | aha152x=io,IRQ,scsi_id
Adaptec AHA 154x and 631x-based | aha1542.o |
Adaptec AHA 1740 | aha1740.o |
Adaptec AHA-274x, AHA-284x, AHA-29xx, AHA-394x, AHA-398x, AHA-274x, AHA-274xT, AHA-2842, AHA-2910B, AHA-2920C, AHA-2930/U/U2, AHA-2940/W/U/UW/AU/, U2W/U2/U2B/, U2BOEM, AHA-2944D/WD/UD/UWD, AHA-2950U2/W/B, AHA-3940/U/W/UW/, AUW/U2W/U2B, AHA-3950U2D, AHA-3985/U/W/UW, AIC-777x, AIC-785x, AIC-786x, AIC-787x, AIC-788x , AIC-789x, AIC-3860 | aic7xxx.o |
ACARD ATP870U PCI SCSI Controller | atp870u.o |
Compaq Smart Array 5300 Controller | cciss.o |
Compaq Smart/2 RAID Controller | cpqarray.o |
Compaq FibreChannel Controller | cpqfc.o |
Domex DMX3191D | dmx3191d.o |
Data Technology Corp DTC3180/3280 | dtc.o |
DTP SCSI host adapters (EATA/DMA) PM2011B/9X ISA, PM2021A/9X ISA, PM2012A, PM2012B, PM2022A/9X EISA, PM2122A/9X, PM2322A/9X, SmartRAID PM3021, PM3222, PM3224 | eata.o |
DTP SCSI Adapters PM2011, PM2021, PM2041, PM3021, PM2012B, PM2022, PM2122, PM2322, PM2042, PM3122, PM3222, PM3332, PM2024, PM2124, PM2044, PM2144, PM3224, PM3334 | eata_dma.o |
Sun Enterprise Network Array (FC-AL) | fcal.o |
Future Domain TMC-16xx SCSI | fdomain.o |
NCR5380 (generic driver) | g_NCR5380.o |
ICP RAID Controller | gdth.o |
I2O Block Driver | i2o_block.o |
IOMEGA MatchMaker parallel port SCSI adapter | imm.o |
Always IN2000 ISA SCSI card | in2000.o | in2000=setup_string:value OR in2000 setup_string=value
Initio INI-9X00U/UW SCSI host adapters | initio.o |
IBM ServeRAID | ips.o |
AMI MegaRAID 418, 428, 438, 466, 762 | megaraid.o |
NCR SCSI controllers with 810/810A/815/825/825A/860/875/876/895 chipsets | ncr53c8xx.o | ncr53c8xx=option1:value1,option2:value2,... OR ncr53c8xx="option1:value1 option2:value2..."
Pro Audio Spectrum/Studio 16 | pas16.o |
PCI-2000 IntelliCache | pci2000.o |
PCI-2220I EIDE RAID | pci2220i.o |
IOMEGA PPA3 parallel port SCSI host adapter | ppa.o |
Perceptive Solutions PSI-240I EIDE | psi240i.o |
Qlogic 1280 | qla1280.o |
Qlogic 2x00 | qla2x00.o |
QLogic Fast SCSI FASXXX ISA/VLB/PCMCIA | qlogicfas.o |
QLogic ISP2100 SCSI-FCP | qlogicfc.o |
QLogic ISP1020 Intelligent SCSI cards IQ-PCI, IQ-PCI-10, IQ-PCI-D | qlogicisp.o |
Qlogic ISP1020 SCSI SBUS | qlogicpti.o |
Future Domain TMC-885, TMC-950 Seagate ST-01/02, Future Domain TMC-8xx | seagate.o | controller_type=2 base_address=base_addr irq=IRQ
Cards with the sym53c416 chipset | sym53c416.o | sym53c416=PORTBASE,[IRQ] OR sym53c416 io=PORTBASE irq=IRQ
Trantor T128/T128F/T228 SCSI Host Adapter | t128.o |
Tekram DC-390(T) PCI | tmscsim.o |
UltraStor 14F/34F (not 24F) | u14-34f.o |
UltraStor 14F, 24F, and 34F | ultrastor.o |
WD7000 Series | wd7000.o |

Table C-4 shows some examples of these modules in use.

Table C-4: SCSI parameters configuration examples
Configuration | Example
Adaptec AHA1522 at port 330, IRQ 11, SCSI ID 7 | aha152x=0x330,11,7
Adaptec AHA1542 at port 330 | bases=0x330
Future Domain TMC-800 at CA000, IRQ 10 | controller_type=2 base_address=0xca000 irq=10
Table C-5: Ethernet module parameters
Hardware | Module | Parameters
3Com 3c501 | 3c501.o | 3c501=io_port,IRQ
3Com 3c503 and 3c503/16 | 3c503.o | 3c503=io_port,IRQ OR 3c503 io=io_port_1,io_port_n irq=IRQ_1,IRQ_n
3Com EtherLink Plus (3c505) | 3c505.o | 3c505=io_port,IRQ OR 3c505 io=io_port_1,io_port_n irq=IRQ_1,IRQ_2
3Com EtherLink 16 | 3c507.o | 3c507=io_port,IRQ OR 3c507 io=io_port irq=IRQ
3Com EtherLink III | 3c509.o | 3c509=io_port,IRQ
3Com ISA EtherLink XL “Corkscrew” | 3c515.o |
3Com EtherLink PCI III/XL Vortex (3c590, 3c592, 3c595, 3c597) Boomerang (3c900, 3c905, 3c595) | 3c59x.o | full_duplex= 0 is off 1 is on
RTL8139, SMC EZ Card Fast Ethernet | 8139too.o |
RealTek cards using RTL8129 or RTL8139 Fast Ethernet chipsets | 8139too.o |
Apricot 82596 | 82596.o |
Ansel Communications Model 3200 | ac3200.o | ac3200=io_port,IRQ OR ac3200 io=io_port_1,io_port_n irq=IRQ_1,IRQ_n
Alteon AceNIC Gigabit | acenic.o |
Aironet Arlan 655 | arlan.o |
Allied Telesis AT1700 | at1700.o | at1700=io_port,IRQ OR at1700 io=io_port irq=IRQ
Broadcom BCM5700 10/100/1000 ethernet adapter | bcm5700.o |
Crystal SemiconductorCS89[02]0 | cs89x0.o |
EtherWORKS DE425 TP/COAX EISA, DE434 TP PCI, DE435/450 TP/COAX/AUI PCI DE500 10/100 PCI Kingston, LinkSys, SMC8432, SMC9332, Znyx31[45], and Znyx346 10/100 cards with DC21040 (no SROM), DC21041[A], DC21140[A], DC21142, DC21143 chipsets | de4x5.o de4x5=io_port OR de4x5 io=io_port de4x5 args='ethX[fdx] autosense=MEDIA_STRING' |
D-Link DE-600 Ethernet Pocket Adapter | de600.o |
D-Link DE-620 Ethernet Pocket Adapter | de620.o |
DIGITAL DEPCA & EtherWORKS DEPCA, DE100, DE101, DE200 Turbo, DE201Turbo DE202 Turbo TP/BNC, DE210, DE422 EISA | depca.o depca=io_port,IRQ OR depca io=io_port irq=IRQ |
Digi Intl. RightSwitch SE-X EISA and PCI | dgrs.o |
Davicom DM9102(A)/DM9132/DM9801 Fast Ethernet | dmfe.o |
Intel Ether Express/100 driver | e100.o | e100_speed_duplex=X If X = 0 = autodetect speed and duplex 1 = 10Mbps, half duplex 2 = 10Mbps, full duplex 3 = 100Mbps, half duplex 4 = 100Mbps, full duplex
Intel EtherExpress/1000 Gigabit | e1000.o |
Cabletron E2100 | e2100.o | e2100=io_port,IRQ,mem OR e2100 io=io_port irq=IRQ mem=mem
Intel EtherExpress Pro10 | eepro.o | eepro=io_port,IRQ OR eepro io=io_port irq=IRQ
Intel i82557/i82558 PCI EtherExpressPro driver | eepro100.o |
Intel EtherExpress 16 (i82586) | eexpress.o | eexpress=io_port,IRQ OR eexpress io=io_port irq=IRQ options= 0x10 10base T half duplex 0x20 10base T full duplex 0x100 100base T half duplex 0x200 100baseT full duplex
SMC EtherPower II 9432 PCI (83c170/175 EPIC series) | epic100.o |
Racal-Interlan ES3210 EISA | es3210.o |
ICL EtherTeam 16i/32 EISA | eth16i.o | eth16i=io_port,IRQ OR eth16i ioaddr=io_port IRQ=IRQ
EtherWORKS 3 (DE203, DE204 and DE205) | ewrk3.o | ewrk=io_port,IRQ OR ewrk io=io_port irq=IRQ
A Packet Engines GNIC-II Gigabit | hamachi.o |
HP PCLAN/plus | hp-plus.o | hp-plus=io_port,IRQ OR hp-plus io=io_port irq=IRQ
HP LAN Ethernet | hp.o | hp=io_port,IRQ OR hp io=io_port irq=IRQ
100VG-AnyLan Network Adapters HP J2585B, J2585A, J2970, J2973, J2573 Compex ReadyLink ENET100-VG4, FreedomLine 100/VG | hp100.o | hp100=io_port,name OR hp100 hp100_port=io_port hp100_name=name
IBM Token Ring 16/4, Shared-Memory IBM Token Ring 16/4 | ibmtr.o | ibmtr=io_port OR io=io_port
AT1500, HP J2405A, NE2100/clone | lance.o |
Mylex LNE390 EISA | lne390.o |
NatSemi DP83815 Fast Ethernet | natsemi.o |
NE1000 / NE2000 (non-pci) | ne.o | ne=io_port,IRQ OR ne io=io_port irq=IRQ
PCI NE2000 cards RealTEk RTL-8029, Winbond 89C940, Compex RL2000, PCI NE2000 clones, NetVin, NV5000SC, Via 82C926, SureCom NE34 | ne2k-pci.o |
Novell NE3210 EISA | ne3210.o |
MiCom-Interlan NI5010 | ni5010.o |
NI5210 card (i82586 Ethernet chip) | ni52.o | ni52=io_port,IRQ OR ni52 io=io_port irq=IRQ
NI6510 Ethernet | ni65.o |
IBM Olympic-based PCI token ring | olympic.o |
AMD PCnet32 and AMD PCnetPCI | pcnet32.o |
SIS 900/701G PCI Fast Ethernet | sis900.o |
SysKonnect SK-98XX Gigabit | sk98lin.o |
SMC Ultra and SMC EtherEZ ISA ethercard (8K, 83c790) | smc-ultra.o | smc-ultra=io_port,IRQ OR smc-ultra io=io_port irq=IRQ
SMC Ultra32 EISA Ethernet card (32K) | smc-ultra32.o |
Sun BigMac Ethernet | sunbmac.o |
Sundance ST201 Alta | sundance.o |
Sun Happy Meal Ethernet | sunhme.o |
Sun Quad Ethernet | sunqe.o |
ThunderLAN | tlan.o |
Digital 21x4x Tulip PCI Ethernet cards SMC EtherPower 10 PCI(8432T/8432BT) SMC EtherPower 10/100 PCI(9332DST) DEC EtherWorks 100/10 PCI(DE500-XA) DEC EtherWorks 10 PCI(DE450) DEC QSILVER's, Znyx 312 etherarray Allied Telesis LA100PCI-T Danpex EN-9400, Cogent EM110 | tulip.o | io=io_port
VIA Rhine PCI Fast Ethernet cards with either the VIA VT86c100A Rhine-II PCI or 3043 Rhine-I D-Link DFE-930-TX PCI 10/100 | via-rhine.o |
AT&T GIS (nee NCR) WaveLan ISA Card | wavelan.o | wavelan=[IRQ,0],io_port, NWID
WD8003 and WD8013-compatible Ethernet cards | wd.o | wd=io_port,IRQ,mem, mem_end OR wd io=io_port irq=IRQ mem=mem mem_end=end
Compex RL100ATX-PCI | winbond.o |
Packet Engines Yellowfin | yellowfin.o |

Table C-6 shows sample configurations for NE2000 and Wavelan Ethernet cards.

Table C-6: Ethernet parameter configuration examples
Configuration | Example
NE2000 ISA card at IO address 300 and IRQ 11 | ne=0x300,11 ether=0x300,11,eth0
Wavelan card at IO 390, autoprobe for IRQ, and use the NWID to 0x4321 | wavelan=0,0x390,0x4321 ether=0,0x390,0x4321,eth0

Using Multiple Ethernet Cards

You can use multiple Ethernet cards in one machine. If each card uses a different driver (for example, a 3c509 and a DE425), you simply need to add alias (and possibly options) lines for each card to /etc/modules.conf. See Chapter 13 for more information.

If any two Ethernet cards use the same driver (such as two 3c509 cards or a 3c595 and a 3c905), you will need to either give the two card addresses on the driver’s options line (for ISA cards) or simply add one alias line for each card (for PCI cards).

For additional information about using more than one Ethernet card, see the Linux Ethernet-HOWTO at http://www.redhat.com/mirrors/LDP/HOWTO/Ethernet-HOWTO.html.


Index

Symbols

%include option, kickstart files, %include
/dev directory, The /dev Directory
/etc directory, The /etc Directory
/etc/fstab
mounting NFS, Mounting NFS File Systems using /etc/fstab
/etc/hosts file, /etc/hosts
/etc/openldap/schema/ directory, The /etc/openldap/schema/ Directory
/etc/resolv.conf file, /etc/resolv.conf
/etc/sysconfig directory, The /etc/sysconfig/ Directory, /etc/sysconfig/amd, /etc/sysconfig/clock, /etc/sysconfig/dhcpd, /etc/sysconfig/harddisks, /etc/sysconfig/init, /etc/sysconfig/ipchains, /etc/sysconfig/irda, /etc/sysconfig/mouse, /etc/sysconfig/named, /etc/sysconfig/network, /etc/sysconfig/radvd, /etc/sysconfig/sendmail, /etc/sysconfig/squid, /etc/sysconfig/vncservers, cbq, rhn
/etc/sysconfig/network file, /etc/sysconfig/network
/etc/systconfig/network-scripts/ifcfg file, /etc/sysconfig/network-scripts/ifcfg-interface-name
/etc/tripwire/twcfg.txt file, Tripwire, Edit /etc/tripwire/twcfg.txt
/etc/tripwire/twpol.txt file, Tripwire, Edit /etc/tripwire/twpol.txt
/lib directory, The /lib Directory
/mnt directory, The /mnt Directory
/opt directory, The /opt Directory
/proc directory, The /proc Directory, /proc, Viewing Virtual Files, Changing Virtual Files
process directories, Process Directories
top level files, Top-level Files in the proc File System, /proc/apm, /proc/cpuinfo, /proc/devices, /proc/execdomains, /proc/, /proc/interrupts, /proc/iomem, /proc/ioports, /proc/isapnp, /proc/ksyms, /proc/locks, /proc/meminfo, /proc/misc, /proc/modules, /proc/mtrr, /proc/pci, /proc/slabinfo, /proc/stat, /proc/uptime, /proc/version
/proc/bus/, /proc/bus/
/proc/driver/, /proc/driver/
/proc/fs, /proc/fs
/proc/ide/, /proc/ide/, The Device Directory
/proc/irq/, /proc/irq/
/proc/net/, /proc/net/
/proc/scsi/, /proc/scsi/
/proc/self/, /proc/self/
/proc/sys/, /proc/sys/, /proc/sys/dev/, /proc/sys/fs/, /proc/sys/kernel/, /proc/sys/net/, /proc/sys/vm/
/proc/sysvipc/, /proc/sysvipc/
/proc/tty/, /proc/tty/
/sbin directory, The /sbin Directory
/sbin/init program
boot process and, The /sbin/init Program
/usr directory, The /usr Directory
/usr/local directory, The /usr/local Directory, /usr/local in Red Hat Linux
/var directory, The /var Directory


Index_A

Team LiB

Index

A

access
secure servers, Accessing Your Secure Server
access control
at, Controlling Access to at and batch
batch, Controlling Access to at and batch
services, Chapter 21: Controlling Access to Services, Runlevels, What Is TCP wrappers?, TCP wrapper Advantages, Host-Based Access Control Lists, Formatting Rules, Access Control Using xinetd, /etc/xinetd.conf, Files in the /etc/xinetd.d/ Directory, Access Control within xinetd, Binding and Port Redirection, The Services Configuration Tool, ntsysv, chkconfig
Account Configuration, Account Configuration, Setting the Root Password, Setting Up User Accounts
alias files, configuration files, Alias and Clone Files
aliases
network devices, Device Aliases
printers, Names and Aliases
also Kerberos, Advantages of Kerberos
also Network Administration Tool, Chapter 13: Network Configuration
anacron, anacron
configuration, Configuring anacron Tasks
starting/stopping, Starting and Stopping the Service
Apache HTTP Server
configuration, New in Red Hat Linux 8.0, Basic Settings, Site Configuration, Logging, Environment Variables, Directories, Virtual Hosts Settings, General Options, SSL, Additional Virtual Host Options, Server Settings, Performance Tuning, Saving Your Settings, Apache HTTP Secure Server Configuration, openssl, OpenSSH packages, stunnel, An Overview of Certificates and Security
LDAP and, PHP4, the Apache HTTP Server, and LDAP
OpenSSH packages, OpenSSH packages
openssl-devel package, openssl-devel
stunnel package, stunnel
arguments
PAM modules, PAM Module Arguments
at
access control, Controlling Access to at and batch
commnad-line options, Additional Command-Line Options
job configuration, Configuring at Jobs
pending jobs, Viewing Pending Jobs
auth option, kickstart files, auth or authconfig (required)
authconfig option, kickstart files, auth or authconfig (required)
authentication
configuration, Authentication Configuration
kickstart installation configuration, Authentication
OpenLDAP and, Configuring Your System to Authenticate Using OpenLDAP, PAM and LDAP, Migrating Old Authentication Information to LDAP Format
authentication \t, see also kerberos
autofs
mounting NFS, Mounting NFS File Systems using autofs
automated tasks
anacron, anacron, Configuring anacron Tasks, Starting and Stopping the Service
at, at and batch, Configuring at Jobs, Viewing Pending Jobs, Additional Command-Line Options, Controlling Access to at and batch
batch, at and batch, Configuring batch Jobs, Viewing Pending Jobs, Additional Command-Line Options, Controlling Access to at and batch
cron, cron, Configuring cron Tasks, Controlling Access to cron, Starting and Stopping the Service
automatic paritioning, Automatic Partitioning
autostep option, kickstart files, autostep (optional)


Index_B

Team LiB

Index

B

batch
access control, Controlling Access to at and batch
command-line options, Additional Command-Line Options
job configuration, Configuring batch Jobs
pending jobs, Viewing Pending Jobs
BIND
Forward Master Zone, Adding a Forward Master Zone
Reverse Master Zone, Adding a Reverse Master Zone
Slave Zone, Adding a Slave Zone
BIND Configuration Tool, Chapter 16: BIND Configuration
BIOS
boot process and, The BIOS
boot command (GRUB), GRUB Commands
boot disk creation, Boot Diskette Creation
boot disk, creating, Boot Disk Creation
boot loader, The Boot Loader
configuration, Boot Loader Configuration, The first sector of your boot partition, Commercial boot loaders, SMP Motherboards, GRUB, and LILO, Boot Loader Configuration, Creating a New Boot Loader Configuration, The first sector of your boot partition
kernel and, Configuring the Boot Loader, GRUB, LILO
MBR, The master boot record (MBR)
boot loader, kickstart installation configuration, Boot Loader Options
boot process, The Boot Process, A Detailed Look at the Boot Process
/sbin/init program, The /sbin/init Program
BIOS, The BIOS
boot loader, The Boot Loader
kernel, The Kernel
other architectures, Differences in the Boot Processes of Other Architectures
running programs, Running Programs at Boot Time
booting
GRUB, Chapter 3: GRUB, GRUB and the x86 Boot Process, Features of GRUB, Installing GRUB, Device Names, File Names, GRUB’s Root File System, Menu Interface, Order of Interface Use, GRUB Commands, Special Configuration File Commands, Configuration File Structure
rescue mode, Booting Rescue Mode
single-user mode, Booting into Single-User Mode
bootloader option, kickstart files, bootloader (required)


Index_C

Team LiB

Index

C

CA (Certificate Authority), An Overview of Certificates and Security
certificate requests, Generating a Certificate Request to Send to a CA
CD-ROM
installation, CD-ROM
installation from, Installing from CD-ROM, What if the IDE CD-ROM Was Not Found?
CD-ROM module parameters, CD-ROM Module Parameters
certificates
CA requests, Generating a Certificate Request to Send to a CA
keys, Generating a Key
self-signed certificates, Creating a Self-Signed Certificate
testing, Testing Your Certificate
certificates, security, An Overview of Certificates and Security, Types of Certificates
keys and, Using Pre-Existing Keys and Certificates
chainloader command (GRUB), GRUB Commands
chkconfig utilty, Chapter 21: Controlling Access to Services
CIPE (Crypto IP Encapsulation) connections, Establishing a CIPE Connection
ciphertext
Kerberos and, ciphertext
clearpart option, kickstart files, clearpart (optional)
clients
DHCP, Configuring a DHCP Client
e-mail security, Secure Email Clients
Kerberos and, client
Kerberos 5, Configuring a Kerberos 5 Client
OpenSSH, Configuring an OpenSSH Client, Using the ssh Command, Using the scp Command, Generating an RSA Key Pair for Version 2, Generating a DSA Key Pair for Version 2, Generating an RSA Key Pair for Version 1.3 and 1.5, Configuring SSH Agent with GNOME, Configuring SSH Agent
clone files, configuration files, Alias and Clone Files
color command (GRUB menu configuration file), Special Configuration File Commands
command options, Fetchmail, Fetchmail Command Options, Special Options
command-line
configuration, Command-Line Configuration
command-line configuration
printers, Command-Line Configuration, Removing a Printer, --model=model
command-line interface (GRUB), Command-Line Interface
command-line options
at, Additional Command-Line Options
batch, Additional Command-Line Options
commands
GRUB, GRUB Commands, Special Configuration File Commands
shutdown, Shutting Down
compatibility
Kerberos and, Disadvantages of Kerberos
configuration
Account Configuration, Account Configuration, Setting the Root Password, Setting Up User Accounts
anacron, Configuring anacron Tasks, Starting and Stopping the Service
Apache HTTP server, New in Red Hat Linux 8.0, Basic Settings, Site Configuration, Logging, Environment Variables, Directories, Virtual Hosts Settings, General Options, SSL, Additional Virtual Host Options, Server Settings, Performance Tuning, Saving Your Settings, Apache HTTP Secure Server Configuration, openssl, OpenSSH packages, stunnel, An Overview of Certificates and Security
at jobs, Configuring at Jobs
authentication, Authentication Configuration
batch jobs, Configuring batch Jobs
BIND Configuration Tool, Chapter 16: BIND Configuration
boot loader, Boot Loader Configuration, The first sector of your boot partition, Commercial boot loaders, SMP Motherboards, GRUB, and LILO, Boot Loader Configuration, Creating a New Boot Loader Configuration, The first sector of your boot partition
command-line, Command-Line Configuration
console, Defining the Console, Enabling Console Access for Other Applications
console access, Console Access, Disabling Console Program Access, Disabling All Console Access
cron, Controlling Access to cron, Starting and Stopping the Service
cron tasks, Configuring cron Tasks
DHCP clients, Configuring a DHCP Client
DHCP servers, Configuring a DHCP Server, Configuration File, Lease Database, Starting and Stopping the Server, DHCP Relay Agent
Fetchmail, Fetchmail Configuration Options, User Options
file access, console, Making Files Accessible from the Console
firewalls, The Security Level Configuration Tool, High, Medium, Trusted Devices, Telnet, FTP, Other ports, GNOME Lokkit, Basic, DHCP, Configuring Services, Mail Relay, Activating the iptables Service, Firewalls and iptables, Firewall Configuration, Medium, No Firewall, WWW (HTTP), Other ports
groups, User and Group Configuration, Modifying Group Properties
interfaces, Ethernet Interfaces, Dial-up Interfaces, Alias and Clone Files
Kerberos 5 client, Configuring a Kerberos 5 Client
Kerberos 5 Server, Configuring a Kerberos 5 Server
keyboard installation, Keyboard Configuration
kickstart installation, Basic Configuration, Installation Method, CD-ROM, Hard Drive, Boot Loader Options, Partition Information, Creating Partitions, Creating Software RAID Partitions, Network Configuration, Authentication, Firewall Configuration, X Configuration, General, Video Card, Monitor, Package Selection, Pre-Installation Script, Post-Installation Script, chroot Environment, Saving the File
mouse installation, Mouse Configuration
network, Network Configuration
networks, Chapter 13: Network Configuration, Establishing an Ethernet Connection, Establishing an ISDN Connection, Establishing a Modem Connection, Establishing an xDSL Connection, Establishing a Token Ring Connection, Establishing a CIPE Connection, Establishing a Wireless Connection, Managing Hosts, Managing DNS Settings, Activating Devices, Working with Profiles, Device Aliases, Network Configuration Files, /etc/sysconfig/network-scripts/ifcfg-interface-name
OpenLDAP files, OpenLDAP Configuration Files, slapd.conf, The /etc/openldap/schema/ Directory
OpenSSH client, Configuring an OpenSSH Client, Using the ssh Command, Using the scp Command, Generating an RSA Key Pair for Version 2, Generating a DSA Key Pair for Version 2, Generating an RSA Key Pair for Version 1.3 and 1.5, Configuring SSH Agent with GNOME, Configuring SSH Agent
OpenSSH server, Configuring an OpenSSH Server
PAM, PAM Configuration Files, PAM Service Names, Sample PAM Configuration Files
printers, Chapter 8: Printer Configuration, Adding a Local Printer, Adding a Remote UNIX Printer, Adding a Samba (SMB) Printer, Adding a Novell NetWare (NCP) Printer, Adding a JetDirect Printer, Selecting the Print Driver and Finishing, Printing a Test Page, Driver Options, Saving the Configuration File, Command-Line Configuration, Removing a Printer, --model=model, Switching Print Systems, CUPS Configuration Interface
Procmail, Procmail Configuration
RAID, Software RAID Configuration
Samba, Configuring Samba
Sendmail, Common Sendmail Configuration Changes, Masquerading
shutdown disabling, Disabling Shutdown Via Ctrl-Alt-Del
time and date, Time and Date Properties
time zone, Time Zone Configuration
Tripwire files, updating, Updating the Tripwire Configuration File
users, User and Group Configuration, Adding a New User, Modifying User Properties, Groups
video cards, Video Card Configuration
Windows and, Using Windows to Learn About Your Hardware
X configuration, X Configuration: Monitor and Customization, Configuring Your Monitor, Custom Configuration
XFree86, XFree86 Server Configuration Files, DRI, InputDevice, Monitor, Screen, ServerLayout
xfs, xfs Configuration, Adding Fonts
xinetd files, xinetd Configuration Files
connections
networks, Establishing an Ethernet Connection, Establishing an ISDN Connection, Establishing a Modem Connection, Establishing an xDSL Connection, Establishing a Token Ring Connection, Establishing a CIPE Connection, Establishing a Wireless Connection
Samba shares, Connecting to a Samba Share
console
application access, Enabling Console Access for Other Applications
defining, Defining the Console
file access, Making Files Accessible from the Console
console access
disabling, Disabling Console Program Access, Disabling All Console Access
properties, Console Access
control flags, PAM modules, PAM Module Control Flags
credential cache, Kerberos, credential cache or ticket file
cron, cron
access control, Controlling Access to cron
configuration, Configuring cron Tasks
starting/stopping, Starting and Stopping the Service
crypt hash
Kerberos, crypt hash
CUPS
configuration, Switching Print Systems, CUPS Configuration Interface
CUPS (Common Unix Printing System), Chapter 8: Printer Configuration
custom installation, Which Installation Class Is Best For You?, Custom Installations, What a Custom Installation Will Do
cutoff variable (diskcheck command), cutoff[/dev/partition]


Index_D

Team LiB

Index

D

daemons
OpenLDAP, OpenLDAP Daemons and Utilities, NSS, PAM, and LDAP, LDAP Client Applications
databases
initialization, Initialize the Tripwire Database
Tripwire, Viewing Tripwire Databases, Updating the Tripwire Database
default command (GRUB menu configuration file), Special Configuration File Commands
defaultCutoff variable (diskcheck command), defaultCutoff
delivering recipes, Procmail, Delivering versus Non-Delivering Recipes
desktop environments
X Window System, Desktop Environments
device option, kickstart files, device (optional)
device probe option, kickstart files, deviceprobe (optional)
Device section, XFree86 configuration, Device
devices
naming, Device Names
networks, Activating Devices, Working with Profiles, Device Aliases
ownership, Device Ownership
df command, File Systems
DHCP
client configuration, Configuring a DHCP Client
firewall configuration and, DHCP
lease database, Lease Database
server configuration, Configuring a DHCP Server, Configuration File, Lease Database, Starting and Stopping the Server, DHCP Relay Agent
DHCP (Dynamic Host Configuration Protocol), Chapter 15: Dynamic Host Configuration Protocol (DHCP)
DHCP Relay Agent, DHCP Relay Agent
dial-up interface, configuration files, Dial-up Interfaces
direct loading method (bootup), GRUB and the x86 Boot Process
directories
Apache HTTP server, Directories
Disk Druid, partitioning and, Partitioning Your System
buttons, Disk Druid’s Buttons
disk partitioning, setup, Disk Partitioning Setup
diskcheck command
filesystem monitoring, Monitoring File Systems, mailProg
displaymem command (GRUB), GRUB Commands
DNS (doman name system), Managing DNS Settings
DRI (Direct Rendering Infrastructure), XFree86 configuration, DRI
driverdisk option, kickstart files, driverdisk (optional)
drivers
print drivers, Selecting the Print Driver and Finishing, Driver Options, Saving the Configuration File


Index_E

Team LiB

Index

E

e-mail
Fetchmail, Fetchmail, Fetchmail Configuration Options, User Options, Fetchmail Command Options, Special Options
MDA (Mail Delivery Agent), Mail Delivery Agent
MTA (Mail Transfer Agent), Mail Transfer Agent
MUA (Mail User Agent), Mail User Agent
Procmail, Procmail, Procmail Configuration, Procmail Recipes, Flags, Special Conditions and Actions, Recipe Examples
protocols, Protocols, IMAP, POP, SMTP
security, Security, Secure Email Clients, Secure Email Servers
Sendmail, Sendmail, History, Common Sendmail Configuration Changes, Masquerading, Stopping Spam with Sendmail, Using Sendmail with LDAP
installation, The Default Sendmail Installation
Tripwire, Tripwire and Email
encryption
Kerberos and, ciphertext
environment variables
Apache HTTP server, Environment Variables
Ethernet
cards, Using Multiple Ethernet Cards
connections, Establishing an Ethernet Connection
interface configuration files, Ethernet Interfaces
parameters, Table C-5: Ethernet module parameters
exclude variable (diskcheck command), exclude
exporting
NFS, Exporting NFS File Systems
ext3 file system, Features of ext3, Easy Transition, Converting to an Ext3 File System, Reverting to an Ext2 File System


Index_F

Team LiB

Index

F

fallback command (GRUB menu configuration file), Special Configuration File Commands
fdisk
partitioning, Partitioning with fdisk
Fetchmail, Fetchmail
command options, Fetchmail Command Options, Special Options
configuration options, Fetchmail Configuration Options, User Options
FHS (Filesystem Hierarchy Standard), Overview of File System Hierarchy Standard (FHS), The /etc Directory, The /proc Directory, The /usr Directory, The /var Directory, /usr/local in Red Hat Linux
fields
partition fields, Partition Fields
filenames
GRUB, File Names
files
configuration, Saving the Configuration File
Tripwire, referencing, Tripwire File Location Reference, /etc/tripwire/tw.pol, /var/lib/tripwire/report/host_name-date_of_report-time_of_report.twr
XFree86 configuration, Files
filesystem
ext3, Features of ext3, Data Integrity, Easy Transition, Converting to an Ext3 File System, Reverting to an Ext2 File System
FHS, Overview of File System Hierarchy Standard (FHS), The /etc Directory, The /proc Directory, The /usr Directory, The /var Directory, /usr/local in Red Hat Linux
information about, displaying, File Systems
monitoring, Monitoring File Systems, mailProg
overview, Why Share a Common Structure?
special file locations, Special File Locations
sysctl command, Using sysctl
upgrading, Upgrading Your File System
firewall option, kickstart files, firewall (optional)
firewalls
configuration, The Security Level Configuration Tool, High, Medium, Trusted Devices, Telnet, FTP, Other ports, GNOME Lokkit, Basic, DHCP, Configuring Services, Mail Relay, Activating the iptables Service, Firewalls and iptables, Firewall Configuration, Medium, No Firewall, WWW (HTTP), Other ports
kickstart installation configuration, Firewall Configuration
packet filtering and, Packet Filtering
Security Level Configuration Tool, The Security Level Configuration Tool, High, Medium, Trusted Devices, Telnet, FTP, Other ports
flags, Procmail recipes, Flags
floppy group, The floppy Group
fonts
xfs, Fonts, xfs Configuration, Adding Fonts
Forward Master Zone, BIND, Adding a Forward Master Zone
FTP
firewall configuration and, FTP
installation, FTP
installation from, Installing via FTP
functions
network functions, Network Functions


Index_G

Team LiB

Index

G

GID (Group ID), Chapter 7: Users and Groups
GNOME Lokkit, firewall configuration and, GNOME Lokkit, Basic, DHCP, Configuring Services, Mail Relay
GNOME System Monitor
system processes, System Processes
grep command
ps aux command and, System Processes
groups
configuration, User and Group Configuration, Modifying Group Properties
creating, Standard Groups, Table 7-2: Standard groups
packages, Package Group Selection, Selecting Individual Packages, Unresolved Dependencies
standard, Standard Groups, Table 7-2: Standard groups
UPGs, User Private Groups, User Private Group, setgid bit on Directories, User Private Group Rationale
GRUB
kernel and, GRUB
GRUB (Grand Unified Boot loader), Chapter 3: GRUB
commands, GRUB Commands, Special Configuration File Commands
device names, Device Names
features, Features of GRUB
filenames, File Names
installing, Installing GRUB
Intel x86 architecture systems and, GRUB and the x86 Boot Process
interfaces, Menu Interface, Order of Interface Use
menu configuration file, Configuration File Structure
root filesystem, GRUB’s Root File System
GRUB (GRand Unified Bootloader), Boot Loader Configuration
GUI (graphical user interface)
installation and, The Graphical Installation Program User Interface, A Note about Virtual Consoles


Index_H

Team LiB

Index

H

hard disks
space usage, displaying information about, File Systems
hard drive
installation from, Installing from a Hard Drive
hard drives
installation and, Hard Drive
hardware
Hardware Browser, Hardware
installation and, Recording Your System’s Hardware, Table A-1: System requirements table
parameters, Table C-1: Hardware parameters
hardware RAID, Hardware RAID
hiddenmenu command (GRUB menu configuration file), Special Configuration File Commands
host management, networks, Managing Hosts
hostname formats, NFS, Hostname Formats
HTTP server
installation, HTTP
installation from, Installing via HTTP
httpd package, Apache server, httpd
httpd-devel package, Apache server, httpd-devel
httpd-manual package, Apache server, httpd-manual


Index_I

Team LiB

Index

I

ICMP (Internet Control Message Protocol)
iptables and, ICMP Protocol, Modules with Additional Match Options
ignore variable (diskcheck command), ignore
IMAP (Internet Message Access Protocol), IMAP
info grub command (GRUB), GRUB Commands
init runlevels, Init Runlevels, Initscript Utilities
initrd command (GRUB), GRUB Commands
initrd image, kernel, Making an initrd Image
InputDevice section, XFree86 configuration, InputDevice
install command (GRUB), GRUB Commands
install option, kickstart files, install (optional)
installation
Account Configuration, Account Configuration, Setting the Root Password, Setting Up User Accounts
boot disk creation, Boot Disk Creation, Boot Diskette Creation
boot loader configuration, Boot Loader Configuration, The first sector of your boot partition, Commercial boot loaders, SMP Motherboards, GRUB, and LILO
booting program, Booting the Installation Program, Additional Boot Options, Booting without Diskettes
CD-ROM, CD-ROM, Installing from CD-ROM, What if the IDE CD-ROM Was Not Found?
classes, Which Installation Class Is Best For You?, Workstation Installations, Server Installations, What a Custom Installation Will Do
custom, Which Installation Class Is Best For You?, Custom Installations, What a Custom Installation Will Do
firewalls, configuration, Firewall Configuration, Medium, No Firewall, WWW (HTTP), Other ports
FTP, FTP, Installing via FTP
GRUB, Installing GRUB
GUI, The Graphical Installation Program User Interface, A Note about Virtual Consoles
hard drive and, Installing from a Hard Drive
hard drives, Hard Drive
hardware, Recording Your System’s Hardware, Table A-1: System requirements table
HTTP server, HTTP, Installing via HTTP
keyboard configuration, Keyboard Configuration
kickstart installations, What Are Kickstart Installations?, Creating the Kickstart File, Kickstart Options, --enableldapauth, --enablehesiod, --enablecache, --upgrade, --opts=, --trust=, harddrive, keyboard (required), lang (required), langsupport (required), --lba32, --emulthree, --bootproto=, part or partition (required for installs, ignored for upgrades), --maxsize=, --end=, Sample Configuration, text (optional), --monitor=, zerombr (optional), --ignoredeps, --interpreter /usr/bin/python, Example, --interpreter /usr/bin/python, Post-installation Script Examples, Creating a Kickstart Boot Diskette, Making the Kickstart File Available on the Network, Making the Installation Tree Available, Starting a Kickstart Installation, ks=floppy, ksdevice= <device>, Basic Configuration, Installation Method, CD-ROM, Hard Drive, Boot Loader Options, Partition Information, Creating Partitions, Creating Software RAID Partitions, Network Configuration, Authentication, Firewall Configuration, X Configuration, General, Video Card, Monitor, Package Selection, Pre-Installation Script, Post-Installation Script, chroot Environment, Saving the File
language selection, Language Selection
language support, Language Support Selection
mouse configuration, Mouse Configuration
network, Network Configuration
networks, Setting Up the Server, Using ISO Images for NFS Installs
NFS, NFS Image, Installing via NFS
packages, Installing Packages, Package Group Selection, Selecting Individual Packages, Unresolved Dependencies, Installing Packages
partitioning, Disk Partitioning Setup, Automatic Partitioning, Partitioning Your System, Disk Druid’s Buttons, Partition Fields, Recommended Partitioning Scheme, Adding Partitions, Deleting a Partition
personal desktop, Which Installation Class Is Best For You?, Personal Desktop Installations
Sendmail, The Default Sendmail Installation
server, Which Installation Class Is Best For You?
server installation, Server Installations, What a Server Installation Will Do
time zone configuration, Time Zone Configuration
Tripwire RPM, Installing the Tripwire RPM
types, Installation Type
ugrade, Which Installation Class Is Best For You?
upgrade, Customizing Your Upgrade, Selecting Packages to Upgrade, Upgrading Packages
upgrading, What It Means to Upgrade
virtual consoles, A Note about Virtual Consoles
Windows and, Using Windows to Learn About Your Hardware
workstation, Which Installation Class Is Best For You?, Workstation Installations
X configuration, X Configuration: Monitor and Customization, Configuring Your Monitor, Custom Configuration
Installation Method, kickstart installation configuration, Installation Method, CD-ROM, Hard Drive
integrity checks
Tripwire, Running an Integrity Check
Intel x86 architectures
GRUB and, GRUB and the x86 Boot Process
interactive option, kickstart files, interactive (optional)
interface control scripts, Interface Control Scripts
interfaces
configuration files, Ethernet Interfaces, Dial-up Interfaces, Alias and Clone Files
CUPS configuration, CUPS Configuration Interface
GRUB, Menu Interface, Order of Interface Use
ipchains, Differences between iptables and ipchains
iptables
command options, Options Used in iptables Commands, Tables, Structure, Commands, Parameters, TCP Protocol, UDP Protocol, Modules with Additional Match Options, Target Options, Listing Options
ipchains comparison, Differences between iptables and ipchains
structure, Structure
tables, Tables
iptables, firewall configuration and, Activating the iptables Service, Firewalls and iptables
ISDN connections, Establishing an ISDN Connection
Itanium-based computers
EFI (Extensible Firmware Interface), The BIOS


Index_J-K

Team LiB

Index

J-K

JetDirect printer, Chapter 8: Printer Configuration
JetDirect printers, Adding a JetDirect Printer
kadmin utility, Configuring a Kerberos 5 Server
KDC (Key Distribution Center), Kerberos, Key Distribution Center (KDC)
Kerberos
advantages of, Advantages of Kerberos
ciphertext and, ciphertext
clients, client
compatibility, Disadvantages of Kerberos
credential cache, credential cache or ticket file
crypt hash, crypt hash
disadvantages, Disadvantages of Kerberos
KDC, Key Distribution Center (KDC)
key table, key table or keytab
keys, key
keytab, key table or keytab
overview, How Kerberos Works
PAM and, Kerberos and PAM
plain text and, plain text
principals, principal
realm, realm
service, service
TGS, Ticket Granting Service (TGS)
TGT, Ticket Granting Ticket (TGT)
ticket files, credential cache or ticket file
tickets, ticket
Kerberos 5 client
configuration, Configuring a Kerberos 5 Client
Kerberos 5 Server
configuration, Configuring a Kerberos 5 Server
kernel, The Kernel
boot loader and, Configuring the Boot Loader, GRUB, LILO
custom, Building a Custom Kernel, Building a Modularized Kernel, Making an initrd Image, Building a Monolithic Kernel
initrd image, Making an initrd Image
management, Chapter 12: Kernel Management, Preparing to Upgrade, Obtaining the Upgraded Kernel, Performing the Upgrade, GRUB, LILO, Building a Modularized Kernel, Kernel Modules, Kernel Module Utilities
modularized, building, Building a Modularized Kernel
modules, Kernel Modules, Kernel Module Utilities
monolithic, Building a Monolithic Kernel
upgraded version, obtaining, Obtaining the Upgraded Kernel
upgrading, Preparing to Upgrade, Performing the Upgrade
version 2.4, The 2.4 Kernel
kernel command (GRUB), GRUB Commands
key pairs
OpenSSH client configuration, Generating Key Pairs, Generating an RSA Key Pair for Version 2, Generating an RSA Key Pair for Version 1.3 and 1.5, Configuring SSH Agent with GNOME, Configuring SSH Agent
key table
Kerberos, key table or keytab
keyboard
configuration, Keyboard Configuration
keyboard option, kickstart files, keyboard (required)
keys
certificates and, Using Pre-Existing Keys and Certificates
Kerberos, key
keys, security
generating, Generating a Key
keytab, Kerberos, key table or keytab
Kickstart Configurator, Kickstart Configurator, Basic Configuration, NFS, Boot Loader Options, Partition Information, Creating Partitions, Creating Software RAID Partitions, Network Configuration, Authentication, X Configuration, General, Video Card, Monitor, Package Selection, Pre-Installation Script, Post-Installation Script, chroot Environment, Saving the File
kickstart files
creating, Creating the Kickstart File
location, Making the Kickstart File Available, Making the Kickstart File Available on the Network
networks, Making the Kickstart File Available on the Network
options, Kickstart Options, --enableldapauth, --enablehesiod, --enablecache, --upgrade, --opts=, --trust=, harddrive, keyboard (required), lang (required), langsupport (required), --lba32, --emulthree, --bootproto=, part or partition (required for installs, ignored for upgrades), --maxsize=, --end=, Sample Configuration, text (optional), --monitor=, zerombr (optional), --ignoredeps, --interpreter /usr/bin/python, Example, --interpreter /usr/bin/python, Post-installation Script Examples
packages, Package Selection, --ignoredeps
post-installation script, Post-installation Script, --interpreter /usr/bin/python, Post-installation Script Examples
pre-installation script, Pre-installation Script, Post-installation Script Examples
kickstart installation
configuration, Basic Configuration, Installation Method, CD-ROM, Hard Drive, Boot Loader Options, Partition Information, Creating Partitions, Creating Software RAID Partitions, Network Configuration, Authentication, Firewall Configuration, X Configuration, General, Video Card, Monitor, Package Selection, Pre-Installation Script, Post-Installation Script, chroot Environment, Saving the File
diskette-based, Creating a Kickstart Boot Diskette
file creation, Creating the Kickstart File
network-based, Making the Kickstart File Available on the Network
starting, Starting a Kickstart Installation, ks=floppy, ksdevice= <device>
tree availability, Making the Installation Tree Available
kickstart installations, What Are Kickstart Installations?
files, Kickstart Options, --enableldapauth, --enablehesiod, --enablecache, --upgrade, --opts=, --trust=, harddrive, keyboard (required), lang (required), langsupport (required), --lba32, --emulthree, --bootproto=, part or partition (required for installs, ignored for upgrades), --maxsize=, --end=, Sample Configuration, text (optional), --monitor=, zerombr (optional), --ignoredeps, --interpreter /usr/bin/python, Example, --interpreter /usr/bin/python, Post-installation Script Examples


Index_L

Team LiB

Index

L

lang option, kickstart files, lang (required)
langsupport option, kickstart files, langsupport (required)
language selection, installation, Language Selection
language support, installation and, Language Support Selection
LDAP
client applications, LDAP Client Applications
OpenLDAP, OpenLDAP 2.0 Feature Enhancements
terminology, LDAP Terminology
LDAP (Lightweight Directory Access Protocol), Chapter 17: Lightweight Directory Access Protocol (LDAP)
Sendmail and, Using Sendmail with LDAP
LDAP Over IPC, OpenLDAP 2.0 Feature Enhancements
lease database, DHCP, Lease Database
less command, System Processes
levels, RAID, Level 0, Level 4, Level 5
LILO
kernel and, LILO
LILO (Linux Loader), Boot Loader Configuration
lilo option, kickstart files, lilo (replaced by bootloader)
lilocheck option, kickstart files, lilocheck (optional)
linear RAID, Linear RAID
local printer, Chapter 8: Printer Configuration
local printers
adding, Adding a Local Printer
lockfiles, Procmail, Specifying a Local Lockfile
logging
Apache HTTP server, Logging
logvol option, kickstart files, logvol (optional)
lpd spool, printers, Chapter 8: Printer Configuration


Index_M

Team LiB

Index

M

Mail (SMTP), firewall configuration and, Mail (SMTP)
mailFrom variable (diskcheck command), mailFrom
mailProg variable (diskcheck command), mailProg
mailTo variable (diskcheck command), mailTo
masquearding, Sendmail, Masquerading
MBR (Master Boot Record), Partition Information, The master boot record (MBR)
MDA (Mail Delivery Agent), Mail Delivery Agent
mem command, Memory Usage
memory
usage, Memory Usage
menu configuration file commands (GRUB), Special Configuration File Commands
menu configuration file structure (GRUB), Configuration File Structure
menu entry editor interface (GRUB), Menu Entry Editor Interface
menu interface (GRUB), Menu Interface
migrating passwords, Kerberos and, Disadvantages of Kerberos
mntpoint option, kickstart files, <mntpoint>
mod_ssl security module, Apache HTTP server, Apache HTTP Secure Server Configuration, openssl, OpenSSH packages, stunnel, An Overview of Certificates and Security
modem connections, Establishing a Modem Connection
modularized kernel, building, Building a Modularized Kernel
modules
kernel, Kernel Modules, Kernel Module Utilities
PAM, PAM Modules, Stacking Modules, Creating Modules, PAM Module Control Flags, PAM Module Paths, PAM Module Arguments
parameters, Specifying Module Parameters
modules section, XFree86 configuration, Module
monitor
X configuration, Configuring Your Monitor
X Windows kickstart configuration, Monitor
Monitor section, XFree86 configuration, Monitor
monitoring
filesystem, Monitoring File Systems, mailProg
monolithic kernel, Building a Monolithic Kernel
mounting NFS, Mounting NFS File Systems
/etc/fstab, Mounting NFS File Systems using /etc/fstab
autofs, Mounting NFS File Systems using autofs
mouse
configuration, Mouse Configuration
mouse option, kickstart files, mouse (required)
MTA
Sendmail, Sendmail, History, The Default Sendmail Installation, Common Sendmail Configuration Changes, Masquerading, Stopping Spam with Sendmail, Using Sendmail with LDAP
MTA (Mail Transfer Agent), Mail Transfer Agent
MUA
Fetchmail, Fetchmail, Fetchmail Configuration Options, User Options, Fetchmail Command Options, Special Options
Procmail, Procmail, Procmail Configuration, Procmail Recipes, Flags, Special Conditions and Actions, Recipe Examples
MUA (Mail User Agent), Mail User Agent


Index_N

Team LiB

Index

N

names
printers, Names and Aliases
NCP Queue, Chapter 8: Printer Configuration
network
configuration, Network Configuration
Network Administration Tool, Chapter 13: Network Configuration
CIPE connections, Establishing a CIPE Connection
Ethernet connections, Establishing an Ethernet Connection
ISDN connections, Establishing an ISDN Connection
modem connections, Establishing a Modem Connection
token ring connections, Establishing a Token Ring Connection
wireless connections, Establishing a Wireless Connection
xDSL connections, Establishing an xDSL Connection
network option, kickstart files, network (optional)
networks
configuration, Chapter 13: Network Configuration, Establishing an Ethernet Connection, Establishing an ISDN Connection, Establishing a Modem Connection, Establishing an xDSL Connection, Establishing a Token Ring Connection, Establishing a CIPE Connection, Establishing a Wireless Connection, Activating Devices, Working with Profiles, Device Aliases
configuration \t , see also network administration tool
configuration files, Network Configuration Files, /etc/sysconfig/network-scripts/ifcfg-interface-name
devices, Activating Devices, Working with Profiles, Device Aliases
DNS settings, Managing DNS Settings
functions, Network Functions
host management, Managing Hosts
installation, Setting Up the Server, Using ISO Images for NFS Installs
interface control scripts, Interface Control Scripts
kickstart files, Making the Kickstart File Available on the Network
kickstart installation configuration, Network Configuration
NFS
command-line configuration, Command-Line Configuration
exporting, Exporting NFS File Systems
hostname formats, Hostname Formats
installing from, NFS Image, Installing via NFS
mounting, Mounting NFS File Systems, Mounting NFS File Systems using /etc/fstab, Mounting NFS File Systems using autofs
NFS (Network File System), Why Use NFS?
non-delivering recipies, Procmail, Delivering versus Non-Delivering Recipes
Novell NetWare (NCP) printers, Adding a Novell NetWare (NCP) Printer
Novell printers, Chapter 8: Printer Configuration
nss_ldap package, NSS, PAM, and LDAP
NTP (Network Time Protocol)
Kerberos and, Configuring a Kerberos 5 Server
ntsysv, Chapter 21: Controlling Access to Services
ntsysv utility, ntsysv, chkconfig


Index_O

Team LiB

Index

O

OpenLDAP, OpenLDAP 2.0 Feature Enhancements
authentication and, Configuring Your System to Authenticate Using OpenLDAP, PAM and LDAP, Migrating Old Authentication Information to LDAP Format
configuration files, OpenLDAP Configuration Files, slapd.conf, The /etc/openldap/schema/ Directory
daemons, OpenLDAP Daemons and Utilities, NSS, PAM, and LDAP, LDAP Client Applications
setup, OpenLDAP Setup Overview
utilities, OpenLDAP Daemons and Utilities, NSS, PAM, and LDAP, LDAP Client Applications
openss package, Apache server, openssl
OpenSSH
client configuration, Configuring an OpenSSH Client, Using the ssh Command, Using the scp Command, Generating an RSA Key Pair for Version 2, Generating a DSA Key Pair for Version 2, Generating an RSA Key Pair for Version 1.3 and 1.5, Configuring SSH Agent with GNOME, Configuring SSH Agent
reasons to use, Why Use OpenSSH?
server configuration, Configuring an OpenSSH Server
OpenSSH packages, Apache server, OpenSSH packages
openssl-devel package, Apache HTTP server, openssl-devel


Index_P

Team LiB

Index

P

Package Management Tool, Package Management Tool
package installation, Installing Packages
package removal, Removing Packages
Package Selection window, kickstart installation configuration, Package Selection
packages
installation, Installing Packages, Package Group Selection, Selecting Individual Packages, Unresolved Dependencies, Installing Packages, Selecting Packages to Upgrade, Upgrading Packages
kickstart files, Package Selection, --ignoredeps
removing, Removing Packages
packet filtering
firewalls and, Packet Filtering
PAM
advantages of, Advantages of PAM
configuration, Sample PAM Configuration Files
configuration files, PAM Configuration Files, PAM Service Names
device ownership and, Device Ownership
modules, PAM Modules, Stacking Modules, Creating Modules, PAM Module Control Flags, PAM Module Paths, PAM Module Arguments
PAM (Pluggable Application Modules), Chapter 25: Pluggable Authentication Modules (PAM)
PAM (Pluggable Authentication Modules), Kerberos and, Kerberos and PAM
pam_ldap module, NSS, PAM, and LDAP
parameters
CD-ROM module, CD-ROM Module Parameters
Ethernet, Table C-5: Ethernet module parameters
modules, Specifying Module Parameters
SCSI, Table C-3: SCSI Parameters
paramters
hardware parameters, Table C-1: Hardware parameters
partition option, kickstart files, part or partition (required for installs, ignored for upgrades)
partitioning
automatic, Automatic Partitioning
disk, Disk Partitioning Setup
Disk Druid, Partitioning Your System, Disk Druid’s Buttons
fdisk and, Partitioning with fdisk
fields, Partition Fields
hard drive display, Graphical Display of Hard Drive(s)
system, Partitioning Your System, Disk Druid’s Buttons, Partition Fields, Recommended Partitioning Scheme, Adding Partitions, Deleting a Partition
partitions
information about, displaying, File Systems
partitions, kickstart installation configuration, Partition Information, Creating Partitions, Creating Software RAID Partitions
password command (GRUB menu configuration file), Special Configuration File Commands
passwords
migrating, Disadvantages of Kerberos
Samba, Samba Passwords
shadow utilities, Shadow Utilities
performance tuning
Apache HTTP server, Performance Tuning
personal desktop installation, Which Installation Class Is Best For You?, Personal Desktop Installations
PHP4, LDAP and, PHP4, the Apache HTTP Server, and LDAP
plain text
Kerberos and, plain text
policy files
Tripwire, updating, Updating the Tripwire Policy File, Sending Test Email Messages
POP (Post Office Protocol), POP
post-installation script
kickstart files, Post-installation Script, --interpreter /usr/bin/python, Post-installation Script Examples
kickstart installation configuration, Post-Installation Script, chroot Environment
pre-installation script
kickstart files, Pre-installation Script, Post-installation Script Examples
kickstart installation configuration, Pre-Installation Script
prefdm
runlevel 3, Runlevel 5: prefdm
principals
Kerberos, principal
print systems, CUPS configuration, Switching Print Systems
Printer Configuration Tool, Chapter 8: Printer Configuration
printers
aliases, Names and Aliases
configuration, Chapter 8: Printer Configuration, Adding a Local Printer, Adding a Remote UNIX Printer, Adding a Samba (SMB) Printer, Adding a Novell NetWare (NCP) Printer, Adding a JetDirect Printer, Selecting the Print Driver and Finishing, Printing a Test Page, Driver Options, Saving the Configuration File, Command-Line Configuration, Removing a Printer, --model=model, Switching Print Systems, CUPS Configuration Interface
JetDirect, Chapter 8: Printer Configuration
modifying existing, Modifying Existing Printers, Names and Aliases
names, Names and Aliases
Novell, Chapter 8: Printer Configuration
queues, Chapter 8: Printer Configuration, Queue Type
Windows printers, Chapter 8: Printer Configuration
printersr
Unix printers, Chapter 8: Printer Configuration
printing
print job management, Managing Your Print Jobs
process directories, /proc, Process Directories
Procmail, Procmail
configuration, Procmail Configuration
recipes, Procmail Recipes, Flags, Special Conditions and Actions, Recipe Examples
profiles, networks, Working with Profiles
properties
console access, Console Access
groups, Modifying Group Properties
time and date, Time and Date Properties
time zone, Time Zone Configuration
users, Modifying User Properties, Groups
protocols
e-mail, Protocols, IMAP, POP, SMTP
ps aux command, System Processes


Index_Q-R

Team LiB

Index

Q-R

queues
printers, Queue Type
queues, printers, Chapter 8: Printer Configuration
RAID
hardware RAID, Hardware RAID
levels, Level 0, Level 4, Level 5
linear RAID, Linear RAID
software RAID, Software RAID, Software RAID Configuration
RAID (Redundant Array of Independent Disks), What Is RAID?, Who Should Use RAID?
raid option, kickstart files, raid (optional)
realm, Kerberos, realm
reboot option, kickstart files, reboot (optional)
recipes, Procmail, Procmail Recipes, Flags, Special Conditions and Actions, Recipe Examples
Red Hat Network, Red Hat Network
CD-ROMs, Installation CD-ROMs
errata list, Errata List
reports
Tripwire, Viewing Tripwire Reports
rescue mode, What Is Rescue Mode?, Unable to Boot Linux, Hardware/Software Problems
booting, Booting Rescue Mode
resources
system information, Additional Resources
Reverse Master Zone, BIND, Adding a Reverse Master Zone
root command (GRUB), GRUB Commands
root filesystem, GRUB’s Root File System
GRUB, GRUB’s Root File System
rootnoverify command (GRUB), GRUB Commands
rootpw option, kickstart files, rootpw (required)
RPM (Red Hat Package Manager)
filesystem and, Special File Locations
runlevel 3
prefdm, Runlevel 5: prefdm
startx, Runlevel 3: startx
runlevels, Init Runlevels, Initscript Utilities
service access control and, Runlevels


Index_S

Team LiB

Index

S

Samba, Samba
configuration, Configuring Samba
passwords, Samba Passwords
shares, connecting to, Connecting to a Samba Share
Samba (SMB) printers, Adding a Samba (SMB) Printer
SASL (Simple Authentication and Security Layer), OpenLDAP 2.0 Feature Enhancements
scp command
OpenSSH client configuration and, Using the scp Command
Screen section, XFree86 configuration, Screen
scripts
interface control scripts, Interface Control Scripts
SCSI
parameters, Table C-3: SCSI Parameters
security
Apache HTTP server, Apache HTTP Secure Server Configuration, openssl, OpenSSH packages, stunnel, An Overview of Certificates and Security
certificates, Using Pre-Existing Keys and Certificates, Types of Certificates
certificates and, An Overview of Certificates and Security
e-mail, Security, Secure Email Clients, Secure Email Servers
keys, Generating a Key
Security Level Configuration Tool, firewalls, The Security Level Configuration Tool, High, Medium, Trusted Devices, Telnet, FTP, Other ports
self-signed certificates, Creating a Self-Signed Certificate
Sendmail, Sendmail, History
configuration changes, Common Sendmail Configuration Changes, Masquerading
installation, default, The Default Sendmail Installation
LDAP, Using Sendmail with LDAP
spam, Stopping Spam with Sendmail
server installation, Which Installation Class Is Best For You?, Server Installations, What a Server Installation Will Do
ServerFlags section, XFree86 configuration, ServerFlags
ServerLayout section, XFree86 configuration, ServerLayout
servers
Apache HTTP server, New in Red Hat Linux 8.0, Basic Settings, Site Configuration, Logging, Environment Variables, Directories, Virtual Hosts Settings, General Options, SSL, Additional Virtual Host Options, Server Settings, Performance Tuning, Saving Your Settings
DHCP, Configuration File, Lease Database, Starting and Stopping the Server, DHCP Relay Agent
e-mail security, Secure Email Servers
Kerberos 5 Server, Configuring a Kerberos 5 Server
OpenSSH, Configuring an OpenSSH Server
secure, accessing, Accessing Your Secure Server
service
Kerberos, service
services
access control, Chapter 21: Controlling Access to Services, Runlevels, What Is TCP wrappers?, TCP wrapper Advantages, Host-Based Access Control Lists, Formatting Rules, Access Control Using xinetd, /etc/xinetd.conf, Files in the /etc/xinetd.d/ Directory, Access Control within xinetd, Binding and Port Redirection, The Services Configuration Tool, ntsysv, chkconfig
Services Configuration Tool, Chapter 21: Controlling Access to Services, The Services Configuration Tool
sftp command
OpenSSH client configuration and, Using the sftp Command
shadow utilities, Shadow Utilities
shutdown
disabling, Disabling Shutdown Via Ctrl-Alt-Del
shutdown command, Shutting Down
single-user mode
booting to, Booting into Single-User Mode
site configuration, Apache HTTP server, Site Configuration
skipx option, kickstart files, skipx (optional)
slapd.conf file, slapd.conf
Slave Master Zone, BIND, Adding a Slave Zone
SMB networks
printers, Chapter 8: Printer Configuration
SMTP (Simple Mail Transfer Protocol), SMTP
software RAID, Software RAID
configuration, Software RAID Configuration
spam
Sendmail and, Stopping Spam with Sendmail
splashimage command (GRUB menu configuration file), Special Configuration File Commands
SSH (Secure Shell), Why Use OpenSSH?
firewall configuration and, SSH
ssh command
OpenSSH client configuration and, Using the ssh Command
SSL (Secure Sockets Layer), OpenLDAP 2.0 Feature Enhancements
SSL (Secure Sockets Layer) protocol, An Overview of Certificates and Security
stacking modules, PAM, Stacking Modules
standard groups, Standard Groups, Table 7-2: Standard groups
standard users, Standard Users, Table 7-1: Standard users
startx
runlevel 3, Runlevel 3: startx
stunnel package, Apache HTTP server, stunnel
sysctl command, Using sysctl
system partitioning, Partitioning Your System, Disk Druid’s Buttons, Partition Fields, Recommended Partitioning Scheme, Adding Partitions, Deleting a Partition
system processes
displaying list of current, System Processes
SysV init, SysV init


Index_T

Team LiB

Index

T

tables
iptables, Tables
TCP
iptables command options, TCP Protocol
TCP wrappers, access control and, What Is TCP wrappers?, TCP wrapper Advantages
Telnet
firewall configuration and, Telnet
test pages, printer configuration, Printing a Test Page
testing
certificates, Testing Your Certificate
text option, kickstart files, text (optional)
TGS (Ticket Granting Service), Kerberos, Ticket Granting Service (TGS)
TGT (Ticket Granting Ticket), Kerberos, Ticket Granting Ticket (TGT)
threads
viewing, System Processes
ticket files, Kerberos, credential cache or ticket file
tickets
Kerberos, ticket
time and date properties, Time and Date Properties
time zone
configuration, Time Zone Configuration
time zone properties, Time Zone Configuration
timeout command (GRUB menu configuration file), Special Configuration File Commands
timezone option, kickstart files, timezone (required)
title command (GRUB menu configuration file), Special Configuration File Commands
TLS (Transport Layer Security), OpenLDAP 2.0 Feature Enhancements
token ring connections, Establishing a Token Ring Connection
top command, System Processes
Tripwire, Chapter 26: Tripwire, How to Use Tripwire
configuration files, Updating the Tripwire Configuration File
customization, Customizing Tripwire, Edit /etc/tripwire/twcfg.txt, Edit /etc/tripwire/twpol.txt
database initialization, Initialize the Tripwire Database
databases, Viewing Tripwire Databases, Updating the Tripwire Database
e-mail messages, Tripwire and Email
file location reference, Tripwire File Location Reference, /etc/tripwire/tw.pol, /var/lib/tripwire/report/host_name-date_of_report-time_of_report.twr
integrity checks, Running an Integrity Check
policy files, updating, Updating the Tripwire Policy File, Sending Test Email Messages
reports, Viewing Tripwire Reports
Tripwire RPM installation, Installing the Tripwire RPM
twinstall.sh script, Run the twinstall.sh Script


Index_U

Team LiB

Index

U

UDP protocol
iptables command options, UDP Protocol
UID (User ID), Chapter 7: Users and Groups
Unix printers, Chapter 8: Printer Configuration
remote, Adding a Remote UNIX Printer
upgrade installation, Which Installation Class Is Best For You?, What It Means to Upgrade
customizing, Customizing Your Upgrade
packages, Selecting Packages to Upgrade, Upgrading Packages
upgrade option, kickstart files, upgrade (optional)
upgraded kernel, obtaining, Obtaining the Upgraded Kernel
upgrading
filesystem, Upgrading Your File System
kernel, Preparing to Upgrade
upgrading kernel, Performing the Upgrade
UPGs (user private groups), User Private Groups, User Private Group, setgid bit on Directories
rationale, User Private Group Rationale
users
configuration, User and Group Configuration, Adding a New User, Modifying User Properties, Groups
creating, Standard Users, Table 7-1: Standard users
standard, Standard Users, Table 7-1: Standard users
utilities
kadmin, Configuring a Kerberos 5 Server
kernel modules, Kernel Module Utilities
ntsysv, ntsysv, chkconfig
OpenLDAP, OpenLDAP Daemons and Utilities, NSS, PAM, and LDAP, LDAP Client Applications
shadow utilities, Shadow Utilities


Index_V

Team LiB

Index

V

variables
environment variables, Environment Variables
video card
X Windows kickstart configuration, Video Card
video cards
configuration, Video Card Configuration
virtual consoles
installation and, A Note about Virtual Consoles
virtual file system
/proc directory, A Virtual File System, Viewing Virtual Files, Changing Virtual Files
virtual hosts
Apache HTTP server, Virtual Hosts Settings, General Options, SSL, Additional Virtual Host Options
volgroup option, kickstart files, volgroup (optional)


Index_W

Team LiB

Index

W

window managers, X Window System, Window Managers
Windows
configuration information, Using Windows to Learn About Your Hardware
Windows printers, Chapter 8: Printer Configuration
wireless connections, Establishing a Wireless Connection
workstation installation, Which Installation Class Is Best For You?, Workstation Installations
WWW (HTTP)
firewall configuration and, WWW (HTTP)


Index_X

Team LiB

Index

X

X configuration, X Configuration: Monitor and Customization, Configuring Your Monitor, Custom Configuration
X Window System, The Power of X
desktop environments, Desktop Environments
fonts, Fonts, xfs Configuration
runlevel 3, startfx, Runlevel 3: startx
runlevel 5, prefdm, Runlevel 5: prefdm
window managers, Window Managers
X Windows
kickstart installation configuration, X Configuration, General, Video Card, Monitor
xconfig option, kickstart files, xconfig (optional)
xDSL connections, Establishing an xDSL Connection
XFree86, The Power of X, XFree86
server configuration files, XFree86 Server Configuration Files, DRI, InputDevice, Monitor, Screen, ServerLayout
xfs, Fonts, xfs Configuration
adding fonts, Adding Fonts
configuration, xfs Configuration
xinetd, access control and, Access Control Using xinetd, /etc/xinetd.conf, Files in the /etc/xinetd.d/ Directory, Access Control within xinetd, Binding and Port Redirection


Index_Z

Team LiB

Index

Z

zerombr option, kickstart files, zerombr (optional)


List of Figures

Chapter 1: Kickstart Installations

Figure 1-1: Kickstart basic configuration
Figure 1-2: Kickstart Installation Method screen
Figure 1-3: Boot loader options
Figure 1-4: Partition information
Figure 1-5: Creating partitions
Figure 1-6: Creating a software RAID partition
Figure 1-7: Creating a software RAID device
Figure 1-8: Network configuration
Figure 1-9: Authentication
Figure 1-10: Firewall configuration
Figure 1-11: X configuration
Figure 1-12: X configuration: video card
Figure 1-13: X configuration: monitor
Figure 1-14: Package selection
Figure 1-15: Pre-installation script
Figure 1-16: Post-installation script
Figure 1-17: Preview

Chapter 5: Gathering System Information

Figure 5-1: GNOME System Monitor
Figure 5-2: Hardware Browser

Chapter 6: General System Configuration

Figure 6-1: Time and Date properties
Figure 6-2: The Package Management Tools
Figure 6-3: Individual package selection
Figure 6-4: Package Installation Summary
Figure 6-5: Package Removal Summary

Chapter 7: Users and Groups

Figure 7-1: User Manager
Figure 7-2: New User
Figure 7-3: User Properties
Figure 7-4: New Group
Figure 7-5: Group properties

Chapter 8: Printer Configuration

Figure 8-1: The Printer Configuration Tool
Figure 8-2: Adding a printer
Figure 8-3: Adding a local printer
Figure 8-4: Local printer device
Figure 8-5: Adding a remote printer
Figure 8-6: Choosing the printer server
Figure 8-7: Adding an SMB printer
Figure 8-8: Choosing the print server
Figure 8-9: Adding an NCP printer
Figure 8-10: Choosing the print server
Figure 8-11: Adding a JetDirect printer
Figure 8-12: Choosing a print server
Figure 8-13: Selecting a print driver
Figure 8-14: Editing a printer
Figure 8-15: Printer System Switcher
Figure 8-16: CUPS configuration tool

Chapter 11: Redundant Array of Independent Disks (RAID)

Figure 11-1: Creating a new RAID partition
Figure 11-2: Making a RAID device
Figure 11-3: Creating a RAID array

Chapter 13: Network Configuration

Figure 13-1: Ethernet settings
Figure 13-2: Ethernet device
Figure 13-3: ISDN settings
Figure 13-4: ISDN device
Figure 13-5: Modem settings
Figure 13-6: Modem device
Figure 13-7: xDSL settings
Figure 13-8: xDSL device
Figure 13-9: Token Ring settings
Figure 13-10: Token Ring device
Figure 13-11: CIPE settings
Figure 13-12: Wireless settings
Figure 13-13: Wireless device
Figure 13-14: Hosts configuration
Figure 13-15: DNS configuration
Figure 13-16: Activating devices
Figure 13-17: Office profile
Figure 13-18: Home profile
Figure 13-19: Network device alias example

Chapter 16: BIND Configuration

Figure 16-1: Adding a forward master zone
Figure 16-2: Adding a reverse master zone
Figure 16-3: Adding a slave zone
Figure 16-4: Adding a slave zone

Chapter 19: Apache HTTP Server Configuration

Figure 19-1: Basic settings
Figure 19-2: Available addresses
Figure 19-3: Site configuration
Figure 19-4: Logging
Figure 19-5: Environment variables
Figure 19-6: Directories
Figure 19-7: Directory settings
Figure 19-8: Virtual hosts
Figure 19-9: SSL support
Figure 19-10: Server configuration
Figure 19-11: Performance tuning

Chapter 21: Controlling Access to Services

Figure 21-1: The Services Configuration Tool

Chapter 22: Basic Firewall Configuration

Figure 22-1: The Security Level Configuration Tool
Figure 22-2: Basic
Figure 22-3: Local Hosts
Figure 22-4: DHCP

Chapter 26: Tripwire

Figure 26-1: Using Tripwire

Appendix A: Installing Red Hat Linux

Figure A-1: Windows 9x system properties
Figure A-2: Windows 9x System Properties
Figure A-3: Windows 2000 System Properties
Figure A-4: Windows 2000 System Properties — Hardware
Figure A-5: Windows Device Manager
Figure A-6: Selecting Partition Dialog for Hard Drive Installation
Figure A-7: NFS Setup Dialog
Figure A-8: FTP Setup Dialog
Figure A-9: HTTP Setup Dialog
Figure A-10: Language Selection
Figure A-11: Keyboard Configuration
Figure A-12: Mouse Configuration
Figure A-13: Choosing Install or Upgrade
Figure A-14: Disk Partitioning Setup
Figure A-15: Automatic Partitioning
Figure A-16: Partitioning with Disk Druid
Figure A-17: Creating a new partition
Figure A-18: Boot Loader Configuration
Figure A-19: Boot Loader Installation
Figure A-20: Network Configuration
Figure A-21: Editing a Network Device
Figure A-22: Firewall Configuration
Figure A-23: Language Support Selection
Figure A-24: Configuring the Time Zone
Figure A-25: Account Creation
Figure A-26: Creating a User Account
Figure A-27: Authentication Configuration
Figure A-28: Package Group Selection
Figure A-29: Package Group Details
Figure A-30: Selecting individual packages
Figure A-31: Unresolved Dependencies
Figure A-32: Installing packages
Figure A-33: Creating your boot disk
Figure A-34: Video card setup
Figure A-35: Monitor selection
Figure A-36: X Customization
Figure A-37: Choosing Install or Upgrade
Figure A-38: Upgrade Customization


List of Listings

Chapter 12: Kernel Management

Listing 12-1: Sample lsmod output

Chapter 15: Dynamic Host Configuration Protocol (DHCP)

Listing 15-1: Subnet declaration
Listing 15-2: shared-network declaration
Listing 15-3: group declaration
Listing 15-4: Range parameter
Listing 15-5: Static IP address using DHCP

Team LiB
Previous Section