Red Hat Linux Networking and System Administration

Red Hat Linux Networking and System Administration

$ r

;

I

Red and

Hat'

Linux’ Networking

System

Administration

3rd Edition

Terry Codings and Kurt Wall

*

*

C ms.

53

:' v mz

,

o"VaVÿ

(K

01_599496 ffirs.qxd 8/30/05 6:38 PM Page iii

Red Hat

®

Linux

®

Networking and System

Administration

Third Edition

Terry Collings and Kurt Wall

WILEY

Wiley Publishing,

Inc.

01_599496 ffirs.qxd 8/30/05 6:38 PM Page i

Red Hat

®

Linux

®

Networking and System Administration

Third Edition

01_599496 ffirs.qxd 8/30/05 6:38 PM Page iii

Red Hat

®

Linux

®

Networking and System

Administration

Third Edition

Terry Collings and Kurt Wall

WILEY

Wiley Publishing,

Inc.

01_599496 ffirs.qxd 8/30/05 6:38 PM Page iv

Red Hat

®

Linux

®

Networking and System Administration, Third Edition

Published by

Wiley Publishing, Inc.

10475 Crosspoint Boulevard

Indianapolis, IN 46256 www.wiley.com

Copyright © 2005 by Wiley Publishing, Inc., Indianapolis, Indiana

Published simultaneously in Canada

ISBN-13: 978-0-7645-9949-1

ISBN-10: 0-7645-9949-6

Manufactured in the United States of America

10 9 8 7 6 5 4 3 2 1

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) 646-8600. 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-4355, or online at http://www.wiley.com/go/permissions

.

Limit of Liability/Disclaimer of Warranty:

The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought.

Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Website is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Website may provide or recommendations it may make.

Further, readers should be aware that Internet Websites listed in this work may have changed or disappeared between when this work was written and when it is read.

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 John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be used without written permission. Red Hat is a registered trademark of Red Hat, Inc. Linux is a 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.

01_599496 ffirs.qxd 8/30/05 6:38 PM Page v

About the Authors

Terry Collings

is the owner of TAC Technology, located in eastern Pennsylvania. He provides Linux consulting and training services to a variety of clients.

Terry has been an adjunct faculty member at several colleges in his area where he has taught A + and Network + certification courses. He also has taught courses on Unix, Linux, TCP/IP, and Novell Netware.

Terry is the author of Red Hat Enterprise Linux 4 For Dummies and has co-authored and contributed to several other Linux books. He has been a technical editor for the following books: KDE Bible, The Samba Book, Unix Weekend

Crash Course, Red Hat Linux 9 For Dummies, Solaris 9 For Dummies, Fedora Linux

2 For Dummies, and Linux Timesaving Techniques For Dummies.

Kurt Wall

first touched a computer in 1980 when he learned FORTRAN on an

IBM mainframe of forgotten vintage; things have improved since then. A professional technical writer by trade, a historian by training, and an all-around

Linux guy by avocation, Kurt’s work history is diverse. These days, Kurt works in the Customer Engineering group at TimeSys Corporation in Pittsburgh,

Pennsylvania. His primary responsibilities include building and maintaining TimeSys’s Developer Exchange and working with portal customers and users. He also fixes broken servers, writes documentation, and builds TimeSys software.

Kurt, who dislikes writing about himself in the third person, receives entirely too much e-mail at [email protected]

v

01_599496 ffirs.qxd 8/30/05 6:38 PM Page vi

Credits

Acquisitions Editor

Debra Williams Cauley

Development Editor

Sydney Jones

Technical Editor

William von Hagen

Production Editor

Angela Smith

Copy Editor

Foxxe Editorial Services

Editorial Manager

Mary Beth Wakefield

Production Manager

Tim Tate

Vice President & Executive Group

Publisher

Richard Swadley

Vice President and Publisher

Joseph B. Wikert

Graphics and Production Specialists

Carrie Foster

Denny Hager

Jennifer Heleine

Stephanie D. Jumper

Ron Terry

Quality Control Technicians

Amanda Briggs

John Greenough

Susan Moritz

Joe Niesen

Proofreading and Indexing

TECHBOOKS Production Services

02_599496 fpref.qxd 8/30/05 6:17 PM Page ix

Preface

Red Hat produces the most popular distribution of Linux currently in use. It is a robust, reliable operating system that can run on a variety of hardware, from personal computers to large mainframes. Linux in general, Fedora Core 4 and

Red Hat Enterprise Linux in particular, are very powerful operating systems that can be used at the enterprise level as a full-fledged server. Linux functions equally well at the enterprise-workstation level for typical user applications, as well as on home PCs. For those of us dissatisfied with the reliability and security of other commercially available operating systems, Fedora Core 4 and

Red Hat Enterprise Linux are a pleasant alternative.

How This Book Is Organized

This book is divided into five parts and one appendix, each covering a specific area of functionality in a typical Fedora Core 4 and Red Hat Enterprise Linux system. In this book, the third edition, we have added more chapters that cover areas we discussed in the first and second editions in more detail or that explore material not covered in the first or second editions. With this edition, the book now contains 35 chapters and a rather large appendix, a considerable increase in content since the first edition was released three years ago. We want to emphasize that this book is useful for users of Fedora Core, the open source community–based Linux project supported by Red Hat, as well as users of Red Hat Enterprise Linux.

ix

02_599496 fpref.qxd 8/30/05 6:17 PM Page x

x Preface

Part I: System and Network Administration Defined

This part sets the stage and defines the role of a system administrator, beginning with an explanation of the duties of a system administrator and continuing through installing your system and finishing with descriptions of the file system and system configuration files. Chapter 1 explains some of the common tasks an administrator may perform, such as installing servers and application software, managing user accounts, and backing up and restoring files.

Chapter 2 details the steps involved in planning and implementing a network, including security and disaster-recovery considerations. Chapter 3 covers all the steps required to install Fedora Core or Red Hat Enterprise Linux on a local system using the most typical installation method. Chapter 4 gives you instructions on using Kickstart to perform system installations on remote systems. Chapter 5 gives you an introduction to the GNOME and KDE graphical user environments and helps you find your way around the desktop. Chapter 6 teaches you about the startup and shutdown process of your system, including the GRUB boot loader and the init process. In Chapter 7, you explore the details of the file system hierarchy and learn about other supported file systems. Part I ends with Chapter 8, which lists the system and network configuration files and explains the purpose of each file.

Part II: Network Services

This part of the book is where you learn about the networking services available in Fedora Core and Red Hat Enterprise Linux. Beginning with Chapter 9, you learn about the X Window system used to provide a graphical working environment as well as font management. Chapter 10 tells you how to configure your printers to use the Common Unix Printing System (CUPS), the default printing system used by Fedora Core and Red Hat Enterprise Linux. In

Chapter 11, you learn about the TCP/IP protocol suite and how to configure it on your system. Chapter 12 explains the configuration of the Network File

System (NFS) used to share files with other Linux or UNIX computers on your network. Chapter 13 gives you the details about the Network Information System (NIS) and configuration instructions. If you have computers running

Microsoft Windows NT, 2000, or XP, you will want to read Chapter 14 to learn how to share files with them using Samba. Chapter 14 also provides instructions on connecting a client to Novell networks so you can share files with these systems as well. Chapter 15 gives you the details of installing and configuring an Oracle database on your server. In Chapter 16 you learn about setting up a VNC server to provide remote access with a graphical interface.

Chapter 17 is all about convenience and some of the convenience services you

02_599496 fpref.qxd 8/30/05 6:17 PM Page xi

Preface

can provide with your system. The last chapter in this part, Chapter 18, gives you some helpful tips for optimizing the services discussed in Part II.

Part III: Internet Services

Internet services are somewhat different from network services on an internal network, and Chapter 19 begins this part by explaining what we mean by

Internet services. Included in this chapter is an explanation of the Xinetd and

TCP wrappers configuration files. The ability to convert domain names to IP addresses is a fundamental part of providing Internet services. Chapter 20 explains how to configure BIND on your system to provide this service. The next three chapters provide installation and configuration instructions for three commonly used Internet services. Chapter 21 describes the process of sending e-mail and how to configure Sendmail, the most commonly used mail transfer agent, as well as Postfix, which is quickly gaining popularity. Chapter

22 explains setting up an FTP server on your system. Chapter 23 covers the most widely used Web server, Apache, and explains the configuration process.

In Chapter 24 you learn about other common Web services that you can provide. The last chapter in Part III, Chapter 25, provides some optimization information for the services covered in this part of the book.

Part IV: System Administration

The goal of this part of the book is to provide enough information so you have a fundamental understanding of the tasks required to maintain your system and ensure that it runs well. Chapter 26 explains the up2date program that is included with Fedora Core and Enterprise Linux that you can use to keep your system updated. Also covered is the Red Hat Network, a subscription service available with Red Hat Enterprise Linux that you can use to keep your system current. You can register your systems with Red Hat and then receive automatic notifications of updated or new software that can be installed. Sometimes it is advantageous to upgrade or recompile your kernel for your specific needs. Chapter 27 discusses the pros and cons of making changes and provides instructions to recompile your kernel. If you would rather do your system configuration from a command prompt instead of using many of the available GUI tools, Chapter 28 is for you. This chapter provides command prompt configuration instructions, as well as instructions to create scripts to automate many routine administration tasks. Chapter 29 tells you all you need to know to effectively manage the users and groups on your system. In Chapter 30, you learn how to install and upgrade software packages on your system. And in the last chapter in this part, Chapter 31, you explore the process of backing up the files on your system and how to restore them.

xi

02_599496 fpref.qxd 8/30/05 6:17 PM Page xii

xii Preface

Part V: System Security and Problem Solving

Most of the last part of the book deals with performance monitoring and tuning, and securing your system, with a final chapter on general system troubleshooting. Maintaining a secure system is a critical area of concern for system administrators. Chapter 32 explains the basic steps involved in monitoring your system’s performance to keep it running as quickly as it should.

Chapter 33 addresses a new topic in this edition, SELinux, the access-based security system developed by the National Security Agency. Continuing the discussion of security, Chapter 34 gives you an explanation of firewalls and

Internet security and the risks involved with connections from outside your network. You also learn about LDAP and Kerberos and their role in network security. The last chapter in this part, Chapter 35, provides some general troubleshooting tips and techniques and lists some problems you may encounter during normal operation of your system and the steps to take to solve the problems discussed.

Appendix A

This appendix is new to this edition. We had a lot of information about shell scripting and couldn’t find a good place for it in the parts, so we put it here. If you want to become a shell-scripting pro, read this section.

How to Use This Book

Our intention in this book is to cover the Fedora Core and Red Hat Enterprise

Linux operating system in enough detail to provide the answers you need. The book is divided into the parts previously discussed to make it easy for you to go to the specific part for the topic you need to learn about. You can use the book as a reference for whatever you need to know about a particular topic.

Using This Book’s Icons

Look for the following margin icons to help you get the most out of this book:

T I P

Tips provide special information or advice.

C A U T I O N

Caution icons warn you of a potential problem or error.

02_599496 fpref.qxd 8/30/05 6:17 PM Page xiii

Preface xiii

C R O S S - R E F E R E N C E

Cross-references direct you to related information in another section or chapter.

N OT E

Notes highlight areas of interest or special concern related to a topic.

Conventions

This book uses the following conventions for explanations of how to do things on your computer:

■■

■■

■■

■■

■■

Italic type introduces new technical terms. It also indicates replaceable arguments that you should substitute with actual values — the context makes clear the distinction between new terms and replaceable arguments.

Bold

shows a command you type.

Monospaced text distinguishes commands, options, and arguments from surrounding explanatory content.

Keys to press in combination are shown as in this example:

Ctrl+Alt+Delete means to press all three keys at the same time.

The term click means to press the left mouse button once. Double-click means to press the left button twice in quick succession. Right-click means to press the right mouse button once. Drag means to hold down the left mouse button and move the mouse while holding down the button.

03_599496 fbetw.qxd 8/30/05 6:37 PM Page xv

Acknowledgments

Terry Collings:

My first thought when I was asked to write the third edition of this book was Wow! Now we are doing a third edition, so what can I say now?

It appears that we did a good-enough job on the first and second editions that many people bought the book and found it useful. So to everyone who bought the first and second editions of the book and made it possible for us to do yet another edition, here’s a big thank you!

Thanks to Kurt Wall, my co-author, for again doing a great job in our collaboration on this new edition. Kurt is very easy to work with, and I hope I’ll have a chance to work with him again. Thanks, Kurt, and I wish you all the best in your recent marriage!

This book would not have been possible without the hard work of everyone at John Wiley & Sons, especially our acquisitions editor, Debra Williams Cauley, and our development editor, Sydney Jones. Debra and Sydney are both consummate professionals who were always there to answer our questions or concerns and make sure we kept on track. Thanks go to our copy editor, technical editor, and production staff at Wiley for ensuring that our book is technically accurate and grammatically correct.

Finally, I would like to thank my wife, Nancy, for all the hours she spent keeping our daughter Sabrina entertained so I could work undisturbed completing this new edition.

Kurt Wall:

I agree with Terry: thanks to everyone who bought the previous editions of this book, which made it possible for us to write this one. Unlike

Terry, though, I knew what I’d say because many of you contacted me to let me know what we’d missed. Thank you. It is a privilege and an honor to write for you; I hope this book is worthy of that trust.

xv

03_599496 fbetw.qxd 8/30/05 6:37 PM Page xvi

xvi Acknowledgments

I’m grateful to Terry for again allowing me to work on this book with him.

Let’s do this again, eh? As usual, the staff at Wiley has been terrific, despite the fact that they drove us to meet an insane deadline. Debra Williams Cauley, our

Acquisitions Editor and Voice of Deadlines Missed, is just a doll; Sydney Jones worked hard to mash the text into something presentable. Thank you Debra and Sydney. Kudos to the unsung, unnamed others who converted the manuscript into printable copy and who never get enough credit.

Our technical editor and my friend and colleague from TimeSys, Bill von

Hagen, helped us write a tighter, more relevant book. Bill also gets an award for keeping me sane during YAB (Yet Another Book) and for keeping me entertained during YADATO (Yet Another Day At The Office). Thanks, Bill! Thanks also to Christopher Faylor, another TimeSys colleague, for reviewing the chapter on RPM and to Tim Wunder, who suggested improvements in the Web services chapter. Any remaining mistakes are either figments of your imagination or my responsibility.

Tim Wunder and the other residents of the Linux Step-by-Step mailing list

(http://mail.linux-sxs.org/cgi-bin/mailman//listinfo/linuxusers

) were quite forthcoming with ideas and input when I asked for it.

They’ve been a great group of people with whom to converse these last 12 years and are a big part of the reason I keep getting to write books about Linux.

Thanks guys. Hats off to Red Hat Software and the Fedora Core Project earn mention here for providing our subject matter.

My agent, Marta Justak, is happy to see me finally nail a deadline but wants to know what Debra does that she couldn’t. Beats me! Thanks to Kevin Bartlett for miscellaneous corrections and to Krischan Jodies for his excellent ipcalc tool. Above all, if I have any talent as a writer, credit goes to God who gave me the talent, provided me the opportunities to develop and use it, and kept me sober long enough to do so. Thanks and Amen.

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xvii

Contents

Preface

Acknowledgments

Part One

System and Network Administration Defined

Chapter 1 Duties of the System Administrator

The Linux System Administrator

Installing and Configuring Servers

Installing and Configuring Application Software

Creating and Maintaining User Accounts

Backing Up and Restoring Files

Monitoring and Tuning Performance

Configuring a Secure System

Using Tools to Monitor Security 12

Summary 12

5

6

3

3

9

10

7

7

Chapter 2 Planning the Network

Deciding How Your Network Will Be Used

Understanding Topologies

Star Topology

Bus Topology

Ring Topology

Tree Topology

Client-Server or Peer-to-Peer?

What’s in the Mix?

Determining System Requirements

Planning and Implementing Security

Addressing External and Internal Threats

Formulating a Security Policy

13

13

15

18

19

20

15

16

16

17

21

21

22

ix xv

1

xvii

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xviii

xviii Contents

An Effective Password Policy

General Security Rules

Security Updates

An Appropriate Firewall System

Planning for Recovery from Disasters

Clustering Solutions

Disaster Recovery

Writing It Down: Good Records Can Save Your Job

25

26

Summary 28

22

22

23

23

23

24

Chapter 3 Standard Installation

Exploring Your PC’s Components

29

30

Processor 30

Bus 30

Memory 31

Video Card and Monitor 31

Hard Drive

Floppy Disk Drive

Keyboard and Mouse

SCSI Controller

CD/DVD-R/RW Drive

Sound Card

33

33

32

32

33

33

Network Card

Checking for Supported Hardware

Creating the Red Hat Boot Disk

Starting the Installation

Partitioning the Hard Disk

Using Disk Druid to Partition Your Disks

Naming Disks and Devices

Mounting a File System

Understanding the Swap Partition

Preparing Disk Partitions

Setting Up the Partitions

Configuring the Installation

Installing the Boot Loader

Configuring the Network

Configuring the Firewall

Choosing Additional Languages

Setting the Time Zone

Setting the Root Password

Selecting the Package Groups to Install

61

62

Running Firstboot 65

Summary 70

51

54

56

58

59

45

46

47

47

34

34

35

36

42

45

49

51

Chapter 4 Kickstart Installation

Using the Kickstart Configurator

Installing the Kickstart Configurator

71

71

72

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xix

Contents xix

Boot Loader Options Screen

Partition Information Screen

77

78

Network Configuration 83

Authentication 84

Firewall Configuration

Display Configuration

Package Selection

Pre-Installation Script

86

87

90

91

Post-Installation Script

Starting the Kickstart Installation

Creating a Bootable Floppy

Creating a Bootable CD-ROM

92

93

93

94

Starting a Kickstart Installation 95

Summary 96

Chapter 5 Exploring the Desktops

Examining the Graphical Login Screen

Logging In and Using the GNOME Desktop

97

97

99

Playing with the Panel

Managing Applets on the Panel

Choosing Items from the Applications Menu in Fedora Core

Choosing Items from the Places Menu in Fedora Core

Choosing Items from the Desktop Menu in Fedora Core

Choosing Items from the Applications Menu on Enterprise Linux 107

Choosing Actions from the Actions Menu in Enterprise Linux 109

Using the Nautilus File Manager 110

101

102

103

105

106

Displaying Your Home Folder

Displaying the Contents of a Folder

Opening Files

Accessing FTP Sites

Using Bookmarks

Adding a Bookmark

Editing Bookmarks

Deleting Bookmarks

Managing Your Files and Folders

Customizing the Nautilus File Manager

114

115

Editing File Manager Preferences 115

Changing the File Manager Background and Icon Emblems 117

112

112

112

113

113

113

113

114

Showing and Hiding Views

Configuring GNOME

Logging Out

Taking a Look at KDE

Managing Applets

118

118

119

119

121

Choosing Applications from the Applications Menu

Using the Konqueror File Manager

122

124

Logging Out of KDE 126

Summary 126

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xx

xx Contents

Chapter 6 System Startup and Shutdown

Examining the Boot Process

The Boot Loader

Using GRUB during Boot

The Kernel

The /sbin/init Program

Exploring Runlevels

133

136

Changing the System Runlevel

Starting Programs at System Boot

Shutting Down the System

GRUB Configuration File

136

137

138

139

Summary 140

127

128

128

130

132

Chapter 7 The File System Explained

Understanding the File System Structure

The / Directory

Working with Linux-Supported File Systems

141

141

143

144 ext3 145 ext2 146 reiserfs 146

SystemV 147 ufs 147

FAT 147

NTFS 147

IBM JFS 147

SGI XFS

Nonstandard Linux File Systems

148

148

FREEVxFS 148

GFS 148

Memory and Virtual File Systems 149 cramfs 149 tmpfs 149 ramfs 150 romfs 150 proc 150

Proc Software Information 150

Proc Hardware Information 152

/dev/pts 154 devfs 154 sysfs 155

Linux Disk Management 155

Disk Partitioning on an x86 Machine

Mounting Other OS Partitions/Slices

155

155

Metadevices 156

Logical Volumes 156

RAID 160

Summary 161

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xxi

Contents xxi

Chapter 8 Examining the System Configuration Files

Examining the System Configuration Files

163

164

Systemwide Shell Configuration Scripts

Shell Config Scripts: bashrc, csh.cshrc, zshrc bash, tcsh, zsh, and Their Config File Read Orders

System Environmental Settings

164

165

167

168

/etc/motd 168 issue 168 issue.net 168 aliases 169 fstab 169 grub.conf 170 cron files 171 syslog.conf 172 ld.so.conf 174 logrotate.conf 174

Examining the /etc/sysconfig/ Directory 175

/etc/sysconfig/apmd 176

/etc/sysconfig/authconfig 177

/etc/sysconfig/clock 177

/etc/sysconfig/crond 178

/etc/sysconfig/desktop 178

/etc/sysconfig/firstboot 178

/etc/sysconfig/grub 178

/etc/sysconfig/harddisks 178

/etc/sysconfig/hwconf 179

/etc/sysconfig/i18n 179

/etc/sysconfig/init 179

/etc/sysconfig/iptables 180

/etc/sysconfig/irda 181

/etc/sysconfig/kernel 181

/etc/sysconfig/keyboard 181

/etc/sysconfig/kudzu 182

/etc/sysconfig/mouse 182

/etc/sysconfig/named 183

/etc/sysconfig/netdump 183

/etc/sysconfig/network 184

/etc/sysconfig/ntpd 184

/etc/sysconfig/pcmcia 184

/etc/sysconfig/selinux 185

/etc/sysconfig/system-config-users 185

/etc/sysconfig/system-logviewer 185

/etc/sysconfig/samba 186

/etc/sysconfig/sendmail 186

/etc/sysconfig/vncservers 186

/etc/sysconfig/xinetd 187

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xxii

xxii Contents

Directories in the /etc/sysconfig/ Directory 187 apm-scripts 187 daemons 187 networking 187 network-scripts 188 rhn 188

Examining the Network Configuration Files 188

Files to Change When Setting Up a System or Moving the System

Setting Up the IP Address

Setting Up the Hostname

Setting Up the DNS Name Resolution

188

189

190

190

Making a Local File of Hostname to IP Address Mappings 191

Setting Up Name Service Resolution Order

Starting Up Network Services from xinetd

192

193

Starting Up Network Services from the rc Scripts

Other Important Network Configuration Files

194 in the /etc/sysconfig Directory 195 static-routes 195

Iptables 195

Network Configuration Files in

/etc/sysconfig/network-scripts 196 ifcfg-networkinterfacename 196 ifup and ifdown

Managing the init Scripts

Managing rc Scripts by Hand

196

196

198

Managing rc Scripts Using chkconfig 200

Summary 202

Part Two Network Services 203

Chapter 9 Managing the X Window System

Configuring the X Server with the X Configuration Tool

Changing the Display Resolution

Changing the Display Color Depth

Changing Monitor Type Settings

Changing Your Video Card Type

Configuring Dual Monitors

Manually Configuring Your X Server

209

210

The X Server Configuration File 210

Summary 215

205

205

206

207

207

208

Chapter 10 Configuring Printers

Configuring Printers with the Printer Configuration Tool

Configuring the Print Queue

Selecting the Print Driver

217

217

219

224

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xxiii

Contents xxiii

Editing the Printer Configuration

Deleting a Printer

225

227

Setting the Default Printer

Managing Print Jobs

227

227

Summary 228

Chapter 11 TCP/IP Networking 229

TCP/IP Explained 229

Understanding Network Classes

Setting Up a Network Interface Card (NIC)

231

233

Configuring the Network Card

Configuring an Internal Network

Understanding Subnetting

Interpreting IP Numbers

Before You Subnet Your Network

234

235

238

Classless InterDomain Routing

Working with Gateways and Routers

Configuring Dynamic Host Configuration Protocol

Setting Up the Server

240

241

244

246

247

248

250 Configuring the DHCP Client

Configuring the Network Using the Network

Configuration Tool

Adding an Ethernet Device

Adding a Wireless NIC

Adding a Modem Connection

Editing Your Network Configuration

250

251

254

256

259

Removing a NIC

Changing the NIC Configuration

Managing DNS Settings

Managing Hosts

Working with Profiles

Configuring IP Masquerading 263

Summary 263

259

260

261

261

262

Chapter 12 The Network File System

NFS Overview

Understanding NFS

What’s New with NFSv4?

NFS Advantages and Disadvantages

Planning an NFS Installation

Configuring an NFS Server

NFS Server Configuration and Status Files

NFS Server Daemons

NFS Server Scripts and Commands

Using Secure NFS

Example NFS Server

Using the NFS Server Configuration Tool

265

265

266

268

269

271

273

274

283

285

290

290

292

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xxiv

xxiv Contents

Configuring an NFS Client

Configuring an NFSv4 Client

296

299

Example NFS Client

Using Automount Services

Examining NFS Security

General NFS Security Issues

Server Security Considerations

300

301

305

305

306

Client Security Considerations 307

Summary 308

Chapter 13 The Network Information System

Understanding NIS

Planning an NIS Installation

Configuring an NIS Server

Key Files and Commands

Starting the NIS Password Daemon

Starting the Server Transfer Daemon

Starting the NIS Servers at Boot Time

Configuring an Example NIS Server

Configuring an NIS Client

Setting the NIS Domain Name

Configuring and Starting the Client Daemon

Configuring the Client Startup Files

NIS Client Commands

326

326

331

331

Configuring an Example NIS Client

Using NIS and NFS Together

333

334

Summary 337

309

309

311

315

315

321

321

322

324

326

Chapter 14 Connecting to Microsoft and Novell Networks

Installing Samba

Configuring the Samba Server

339

340

341

[global] 342

[homes] 343

[printers] 344

Creating Samba Users 344

Starting the Samba Server

Connecting to a Samba Client

345

345

Connecting from a Windows PC to the Samba Server

Connecting to Novell Networks

347

348

Summary 350

Chapter 15 Configuring a Database Server

Linux Database Servers

Using MySQL

Securing the MySQL Installation

Using the MySQL Client Programs

351

351

353

355

359

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xxv

Contents xxv

Using PostgreSQL

Verifying the PostgreSQL Installation

Finalizing the PostgreSQL Installation

Initializing the Installation

Modifying Access Privileges

Creating a Test Database

Testing Connectivity to the Test Database

362

Using the PostgreSQL Client Programs 375

Summary 379

365

366

366

368

372

374

Chapter 16 Creating a VNC Server

What Is VNC?

Setting Up a VNC Server

Configuring Your Firewall for VNC

381

381

383

384

Customizing the VNC Server

Testing the VNC

386

388

Summary 392

Chapter 17 Providing Additional Network Services

Configuring a Time Server

Selecting a Time Server Solution

Configuring the Time Server

Selecting Reference Clocks

Configuring an NTP Client

Playing Nicely and Wisely with NTP

Providing a Caching Proxy Server

Verifying the Kernel Configuration

Configuring Squid

Modifying Netfilter

Starting Squid

408

409

411

412

Testing the Configuration 412

Summary 414

393

394

395

396

397

401

405

406

Chapter 18 Optimizing Network Services

Optimizing the X Window System

Optimizing NFS

Optimizing NIS

415

416

418

423

Optimizing Samba Networking

Getting More from a Database Server

423

424

Summary 425

Part Three Internet Services 427

Chapter 19 What Are Internet Services?

Learning about Secure Services

429

430

SSH 430 scp 431 sftp 433

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xxvi

xxvi Contents

Less Secure Services 434

Telnet 434

FTP 434 rsync 435 rsh 435 rlogin 435 finger 435 talk and ntalk

Using Your Linux Machine as a Server

435

436

HTTP 436 sshd 436 ftpd 436

DNS 437

Configuring the xinetd Server 437

Comparing xinetd and Standalone 439 xinetd-Started Services 439

Standalone Services

Configuring Linux Firewall Packages

440

441

Summary 441

Chapter 20 Configuring BIND: The Domain Name System

Understanding DNS

Installing the Software

Understanding Types of Domain Servers

Examining Server Configuration Files

The named.conf file 450

Options 451

Include 454

Acl 455

Logging 455 server 457 zones 457

Zone Files 458

SOA — Start of Authority 459

The Reverse Zone File

Configuring a Caching DNS Server

Configuring a Secondary Master DNS Server

Configuring a Primary Master Server

Checking Your Configuration

443

443

446

447

449

460

461

462

462

464

The Host Program 464

The dig Program 465

Summary 466

Chapter 21 Configuring Mail Services

Email Explained

Tracing the Email Delivery Process

Mail User Agent (MUA)

467

467

468

468

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xxvii

Contents xxvii

Mail Transfer Agent (MTA)

Mail Delivery Agent (MDA)

Introducing SMTP

Understanding POP3

Understanding IMAP4

Configuring Sendmail

Configuring Sendmail

The m4 Macro Processor

Understanding and Managing the Mail Queue

Setting Up Aliases to Make Life Easier

Using Other Sendmail Files and Commands

Using the Postfix Mail Server

Switching to Postfix

Configuring Postfix

Running Postfix behind a Firewall or Gateway

Running Postfix on a Mail Host

Serving Email with POP3 and IMAP

Setting up an IMAP Server

Configuring Dovecot

Testing Cyrus

Maintaining Email Security

Protecting against Eavesdropping

Using Encryption

Using a Firewall

Don’t Get Bombed, Spammed, or Spoofed

487

487

487

488

Be Careful with SMTP 488

Summary 489

479

480

482

483

484

485

485

486

486

469

469

470

471

471

472

474

475

476

476

478

479

Chapter 22 Configuring FTP Services

Introducing vsftpd

Configuring vsftpd

Configuring User Level FTP Access

Configuring vsftpd Features

Disabling Anonymous FTP

Advanced FTP Server Configuration

Running vsftpd from xinetd

Enabling Anonymous Uploads

Enabling Guest User FTP Accounts

502

503

504

Running vsftpd over SSL

Using SFTP

507

509

Summary 510

491

492

493

496

497

501

502

Chapter 23 Configuring a Web Server

Introducing Apache

Apache Features

Changes in Apache 2

How Web Servers Work

511

511

512

516

517

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xxviii

xxviii Contents

Configuring Apache

Apache’s Startup Process

Configuring Global Behavior

Configuring the Default Server

Configuring Virtual Servers

Starting and Stopping Apache

Implementing SSI

Enabling CGI

Enabling PHP

Creating a Secure Server with SSL

Understanding SSL and Server Certificates

Creating a Self-Signed Certificate

Obtaining a Certificate from a Certification Authority 554

Summary 554

539

540

543

545

546

547

549

519

520

521

524

537

Chapter 24 Providing Web Services

Creating Mailing Lists

Completing the Initial Mailman Configuration

Creating a Mailing List

Modifying a Mailing List’s Configuration

Performing Common Mailman Administrative Tasks

Adding Multiple List Members

Hiding a Mailing List

Restricting Archives Access

Setting Up Web-Based Email

Connecting to SquirrelMail

Reconfiguring SquirrelMail

Configuring an RSS Feed

Selecting Content for an RSS Feed

Creating the Feed File

563

563

563

565

567

570

570

Turning on an RSS Feed

Adding Search Functionality

572

574

Getting Started with ht://Dig 574

Summary 579

555

555

556

559

560

561

562

562

Chapter 25 Optimizing Internet Services

Optimizing LDAP Services

Optimizing DNS Services

Improving the Performance of DNS Clients

Tweaking DNS Servers

Logging 586

Optimizing Mail Services 587

Getting More from Sendmail 587

Getting More from Postfix

Optimizing FTP Services

588

590

Optimizing Web Services 590

Summary 593

581

582

583

583

585

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xxix

Contents xxix

Part Four System Administration 595

Chapter 26 Keeping Your System Updated with up2date and the Red Hat Network

Using the Red Hat up2date Agent

Configuring the up2date Agent

597

598

599

Updating Your System

Registering Your System

602

605

Accessing the Red Hat Network with a Web Browser 608

Summary 614

Chapter 27 Upgrading and Customizing the Kernel

Determining Whether to Upgrade to a New Kernel

Upgrading versus Customizing

Preparing to Upgrade

Installing a Kernel RPM

Getting the Kernel Source

Using the Kernel Source RPM

Using Pristine Kernel Source

Verifying and Unpacking the Archive

Patching the Kernel

Configuring the Kernel

Selecting a Kernel Configuration File

Configuring the Kernel with xconfig

Configuring the Kernel with menuconfig

Reviewing the Configuration Options

Code Maturity Level Options

General Setup

Loadable Module Support

Processor Type and Features

Power Management Options

Bus Options

Executable File Formats

Device Drivers

Generic Driver Options

Memory Technology Devices

Parallel Port Support

Plug and Play Support

645

645

645

646

Block Devices 646

ATA/ATAPI/MFM/RLL Support 647

SCSI Device Support

Old CD-ROM Drivers

648

648

637

637

640

640

643

643

644

645

Multidevice Support

Fusion MPT Device Support

IEEE 1394/FireWire Support

I2O Device Support

Networking Support

ISDN and Telephony

649

649

649

649

649

653

627

629

630

633

634

637

615

616

618

618

619

620

621

623

626

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xxx

xxx Contents

Input Device Support

Character Devices

I2C Support

Multimedia Devices

653

654

654

655

Graphics Support 655

Sound 656

USB Support

MMC/SD Card Support

656

660

InfiniBand Support

File Systems

CD-ROM/DVD File Systems

DOS/FAT/NT File Systems

660

660

661

661

Pseudo-File-Systems 662

Miscellaneous File Systems 662

Network File Systems

Partition Types

662

662

Native Language Support

Profiling Support

Kernel Hacking

Security Options

Cryptography Options

Library Routines

663

663

664

664

664

665

Saving the Kernel Configuration

Compiling the Kernel

Installing the Kernel

Updating GRUB

665

666

669

670

Summary 671

Chapter 28 Configuring the System at the Command Line

Administrating Your System from the Command Line

Managing Processes

Obtaining Process Information

Signaling Processes

Modifying Process Priorities

Maintaining the File System

Working with File Systems

Creating and Manipulating Partitions

Creating and Manipulating File Systems

Working with Files and Directories

683

683

685

691

Managing Disk Space Usage 695

Timekeeping 696

Single-Use Commands 697

673

673

675

676

680

682

683

Using the Network Time Protocol

Automating Scripts

Running One-Shot Jobs with at

702

702

702

Running Regularly Scheduled Jobs with cron 704

Summary 705

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xxxi

Contents xxxi

Chapter 29 Administering Users and Groups

Administering User Accounts

Working with User Accounts

The User Database Files

Modifying Multiple Accounts Simultaneously

Viewing Login and Process Information

Working with Group Accounts

Creating Groups

Modifying and Deleting Groups

Using a Shadowed Group File

Using User Private Groups

Administering Users and Groups with User Manager

Creating User Accounts

Modifying and Deleting User Accounts

Creating Group Accounts

Modifying and Deleting Group Accounts

Understanding the Root Account

Implementing Sudo

Deciphering Sudo’s Configuration File

Sudo Configuration and Usage Tips

Using File System Quotas

733

737

737

Enabling Quotas

Creating the Quota Files

Turning on Quotas

Setting and Modifying Quotas

738

739

740

740

Viewing Quota Utilization 742

Summary 744

707

707

708

708

715

717

718

719

720

722

723

725

726

727

728

729

730

731

Chapter 30 Installing and Upgrading Software Packages

Using the Red Hat Package Manager

745

745

General Options

Query Mode

Querying Package Dependencies

What’s in That RPM?

Formatting Query Output

Package Installation and Removal

Installing RPMs

Upgrading RPMs

746

748

750

751

754

755

756

757

Removing RPMs 758

Verifying RPMs 758

Building Packages Using Source RPMs

Checking Software Versions

Obtaining Newer Software

Using Third-Party Sites to Find RPMs

Using Ibiblio.org

761

764

767

768

770

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xxxii

xxxii Contents

Installing Software from Source

Configuring the Build Environment

Unpacking the Source Code

Configuring the Source Code

Building the Software Package

Testing the Build

771

Installing the Software 777

Summary 778

772

772

773

775

776

Chapter 31 Backing Up and Restoring the File System

Creating a Backup Plan

Choosing Media for Backups

Understanding Backup Methods

Tape Rotation

Using Backup Tools

Command Line Tools

Using mt-st

Using the cdrecord Package

Using dump

Using restore

Using tar

Advanced Tools

Using AMANDA 795

Summary 804

779

779

781

781

783

784

784

784

787

789

790

793

795

Chapter 32 Performance Monitoring

System-Performance-Monitoring Tools

Measuring Memory Usage

Memory Usage as Seen by Users and Processes

Examining Kernel Memory Usage

Viewing Running Tasks

Getting Started with ps

Using top

Monitoring I/O Activity

Using sar

Monitoring Memory with sar 827

Monitoring CPU Usage with sar 829

Summary 831

805

805

806

806

810

812

813

817

822

826

Part Five System Security and Problem Solving 833

Chapter 33 Exploring SELinux Security

Understanding SELinux

Mandatory and Role-Based Access Control

SELinux Policies

Using SELinux

Enabling SELinux Manually

Modifying the Targeted Policy

835

835

836

838

838

842

843

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xxxiii

Contents xxxiii

Finding More Information about SELinux 845

Summary 846

Chapter 34 Implementing Network Security

Creating a Firewall

Installing, Configuring, and Using LDAP

Overview of LDAP Directory Organization

OpenLDAP Packages for Linux

Core OpenLDAP Server Files, Daemons, and Utilities

Configuring and Starting an OpenLDAP Server

Using OpenLDAP for System Authentication

Adding User, Password, and Group

Entries to an LDAP Server

Updating Client Systems to Use LDAP Authentication

Installing, Configuring, and Using Kerberos

Kerberos Terminology, Machine Roles, and Reliability

Kerberos Packages for Linux

Core Kerberos Utilities

Installing and Configuring a Kerberos Server

Enabling Kerberos Clients and Applications

860

861

864

865

865

866

867

870

Using Kerberos for Login Authentication 871

Summary 874

847

847

851

852

855

856

857

860

Chapter 35 Troubleshooting and Problem Solving

Troubleshooting Techniques

Step 1: Identify the Problem

Step 2: Reproduce the Problem

Step 3: Look for Changes

Step 4: Determine the Most Likely Cause

Step 5: Implement a Solution

Step 6: Keep Documentation

Troubleshooting Resources

The Internet

System Log Files

README Files

Solving Common Problems

Unable to Log In

Resetting a User’s Password

Creating a User Account

Lost or Forgotten Root Password

CD-ROM Drive Not Detected during Installation

CD-ROM Drive Does Not Mount after Installation

Sound Does Not Work after Installation

Unable to Unmount a Drive

Shell Commands Don’t Work

Solving File System Problems

Cannot Delete a File

Commands with Multiword Arguments

878

878

878

879

882

883

883

883

883

884

884

885

885

887

875

876

876

876

877

877

878

888

888

889

889

04_599496 ftoc.qxd 8/30/05 7:08 PM Page xxxiv

xxxiv Contents

Accessing Windows File Systems

Working with Floppy Disks

Cannot Mount a Partition

Avoiding File System Checks at Each System Reboot

Solving Networking Problems

Getting Online with a Modem

The Boot Process Hangs

Using Two Ethernet Cards

Solving NFS Problems

Exploring Miscellaneous Problems

Solving Boot Problems ht://Dig Won’t Run

Starting cyrus-imapd

Solving Laptop Video Problems

The Signal 7 and Signal 11 Problems

Using Screensavers and Power Management

Starting the X Window System

Making an Emergency Boot Disk

903

904

Summary 904

899

900

900

901

902

903

890

890

891

891

891

893

895

896

896

898

Appendix A Bash Shell Scripting

Using Wildcards and Special Characters

Using Variables

Using Bash Operators

Comparison Operators

Arithmetic Operators

File Test Operators

Understanding Flow Control

Conditional Execution Using if Statements

Determinate Loops Using the for Statement

Indeterminate Loops Using while and until Statements

Selection Structures Using case and select Statements

The case Statement

The select Statement

Using Shell Functions

Processing Input and Output

Redirecting I/O

String I/O

Working with Command Line Arguments

932

934

Using Processes and Job Control 936

Summary 941

920

922

923

924

925

926

928

929

929

905

906

909

913

913

916

917

919

Index 943

05_599496 pt01.qxd 8/30/05 6:38 PM Page 1

PA R T

One

System and Network

Administration Defined

Chapter 1:

Duties of the System Administrator

Chapter 2:

Planning the Network

Chapter 3:

Standard Installation

Chapter 4:

Kickstart Installation

Chapter 5:

Exploring the Desktops

Chapter 6:

System Startup and Shutdown

Chapter 7:

The File System Explained

Chapter 8:

Examining the System Configuration Files

05_599496 pt01.qxd 8/30/05 6:38 PM Page 2

06_599496 ch01.qxd 8/30/05 6:18 PM Page 3

C H A P T E R

1

Duties of the System

Administrator

IN THIS CHAPTER

■■

■■

■■

■■

■■

■■

■■

■■

The Linux System Administrator

Installing and Configuring Servers

Installing and Configuring Application Software

Creating and Maintaining User Accounts

Backing Up and Restoring Files

Monitoring and Tuning Performance

Configuring a Secure System

Using Tools to Monitor Security

Linux is a multiuser, multitasking operating system from the ground up. In this regard the system administrator has flexibility — and responsibility — far beyond those of other operating systems. Red Hat has employed innovations that extend these duties even for the experienced Linux user. This chapter briefly looks at those responsibilities, which are covered in more detail in later chapters.

The Linux System Administrator

Using Linux involves much more than merely sitting down and turning on the machine. Often you hear talk of a “steep learning curve” but that discouraging phrase can be misleading. Linux is quite different from the most popular commercial operating systems in a number of ways. While it is no more difficult to learn than other operating systems are, it is likely to seem very strange even to the experienced administrator of other systems. In addition, the sophistication of a number of parts of the Red Hat distribution has increased by an order of

3

06_599496 ch01.qxd 8/30/05 6:18 PM Page 4

4 Chapter 1

magnitude, so even an experienced Linux administrator is likely to find much that is new and unfamiliar. Fortunately, there are new tools designed to make system administration easier than ever before.

Make no mistake: Every computer in the world has a system administrator.

It may be — and probably is — true that the majority of system administrators are those who decided what software and peripherals were bundled with the machine when it was shipped. That status quo remains because the majority of users who acquire computers for use as appliances probably do little to change the default values. But the minute a user decides on a different wallpaper image or adds an application that was acquired apart from the machine itself, he or she has taken on the role of system administration.

The highfalutin’ title of system administrator brings with it some responsibilities. No one whose computer is connected to the Internet, for instance, has been immune to the effects of poorly administered systems, as demonstrated by the distributed denial of service (DDoS) and email macro virus attacks that have shaken the online world in recent years. The scope of these acts of computer vandalism (in some cases, computer larceny) would have been greatly reduced if system administrators had a better understanding of their duties.

Linux system administrators are likely to understand the necessity of active system administration more than those who run whatever came on the computer, assuming that things came properly configured from the factory. The user or enterprise that decides on Linux has decided, also, to assume the control that Linux offers, and the responsibilities that this entails.

By its very nature as a modern, multiuser operating system, Linux requires a degree of administration greater than that of less robust, home-market systems. This means that even if you use just a single machine connected to the

Internet by a dial-up modem — or not even connected at all — you have the benefits of the same system employed by some of the largest businesses in the world, and will do many of the same things that IT professionals employed by those companies are paid to do. Administering your system does involve a degree of learning, but it also means that in setting up and configuring your own system you gain skills and understanding that raise you above mere

“computer user” status. The Linux system administrator does not achieve that mantle by purchasing a computer but by taking full control of what the computer does and how it does it.

You may end up configuring a small home or small office network of two or more machines, perhaps including ones that are not running Linux. You may be responsible for a business network of dozens of machines. The nature of system administration in Linux is surprisingly constant, no matter how large or small your installation. It merely involves enabling and configuring features you already have available.

By definition, the Linux system administrator is the person who has “root” access, which is to say the one who is the system’s “superuser” (or root user). A standard Linux user is limited to whatever he or she can do with the underlying

06_599496 ch01.qxd 8/30/05 6:18 PM Page 5

Duties of the System Administrator

engine of the system. But the root user has unfettered access to everything — all user accounts, their home directories, and the files therein; all system configurations; and all files on the system. A certain body of thought says that no one should ever log in as “root,” because system administration tasks can be performed more easily and safely through other, more specific means, which we discuss in due course. Because the system administrator has full system privileges, your first duty is to know what you’re doing, lest you break something.

N OT E

By definition, the Linux system administrator can be anyone who has

“root” access — anyone who has root access is the system’s “superuser.”

The word duty implies a degree of drudgery; in fact, it’s a manifestation of the tremendous flexibility of the system measured against the responsibility to run a tight organization. These duties do not so much constrain you, the system administrator, as free you to match the job to the task. Let’s take a brief look at them.

Installing and Configuring Servers

When you hear the word server to describe a computer, you probably think of a computer that offers some type of service to clients. The server may provide file or printer sharing, File Transfer Protocol (FTP) or Web access, or emailprocessing tasks. Don’t think of a server as a standalone workstation; think of it as a computer that specifically performs these services for many users.

In the Linux world, the word server has a broader meaning than what you might be used to. For instance, the standard Red Hat graphical user interface

(GUI) requires a graphical layer called XFree86. This is a server. It runs even on a standalone machine with one user account. It must be configured. (Fortunately, Red Hat has made this a simple and painless part of installation on all but the most obscure combinations of video card and monitor; gone are the days of anguish as you configure a graphical desktop.)

Likewise, printing in Linux takes place only after you configure a print server. Again, this has become so easy as to be nearly trivial.

In certain areas the client-server nomenclature can be confusing, though.

While you cannot have a graphical desktop without an X server, you can have remote Web access without running a local Web server, remote FTP access without running a local FTP server, and email capabilities without ever starting a local mail server. You may well want to use these servers, all of which are included in Red Hat; then again, maybe not. Whenever a server is connected to other machines outside your physical control, there are security implications to consider. You want your users to have easy access to the things they need, but you don’t want to open up the system you’re administering to the whole wide world.

5

06_599496 ch01.qxd 8/30/05 6:18 PM Page 6

6 Chapter 1

N OT E

Whenever a server is connected to machines outside your physical control, security issues arise. You want users to have easy access to the things they need but you don’t want to open up the system you’re administering to the whole wide world.

Linux distributions used to ship with all imaginable servers turned on by default. Just installing the operating system on the computer would install and configure — with default parameters — all the services available with the distribution. This was a reflection of an earlier, more innocent era in computing when people did not consider vandalizing other people’s machines to be good sportsmanship. Unfortunately, the realities of this modern, more dangerous world dictate that all but the most essential servers remain turned off unless specifically enabled and configured. This duty falls to the system administrator. You need to know exactly which servers you need and how to employ them, and to be aware that it is bad practice and a potential security nightmare to enable services that the system isn’t using and doesn’t need. Fortunately, the following pages show you how to carry out this aspect of system administration easily and efficiently.

Installing and Configuring Application Software

Although it is possible for individual users to install some applications in their home directories — drive space set aside for their own files and customizations — these applications may not be available to other users without the intervention of the user who installed the program or the system administrator. Besides, if an application is to be used by more than one user, it probably needs to be installed higher up in the Linux file hierarchy, which is a job that only the system administrator can perform. (The administrator can even decide which users may use which applications by creating a “group” for that application and enrolling individual users in that group.)

New software packages might be installed in /opt if they are likely to be upgraded separately from the Red Hat distribution itself. Doing this makes it simple to retain the old version until you are certain that the new version works and meets your expectations. Some packages may need to go in

/usr/src or even /usr if they are upgrades of packages installed as part of

Red Hat. (For instance, there are sometimes security upgrades of existing packages.) The location of the installation usually matters only if you compile the application from source code; if you use a Red Hat Package Manager

(RPM) application package, it automatically goes where it should.

Configuration and customization of applications is to some extent at the user’s discretion, but not entirely. “Skeleton” configurations — administratordetermined default configurations — set the baseline for user employment of

06_599496 ch01.qxd 8/30/05 6:18 PM Page 7

Duties of the System Administrator

applications. If there are particular forms, for example, that are used throughout an enterprise, the system administrator would set them up or at least make them available by adding them to the skeleton configuration. The same applies to configuring user desktops and in even deciding what applications should appear on user desktop menus. For instance, your company may not want to grant users access to the games that ship with modern Linux desktops.

You may also want to add menu items for newly installed or custom applications. The system administrator brings all this to pass.

Creating and Maintaining User Accounts

Not just anyone can show up and log on to a Linux machine. An account must be created for each user and — you guessed it — no one but the system administrator can do this. That’s simple enough.

But there’s more. It involves decisions that either you or your company must make. You might want to let users select their own passwords, which would no doubt make them easier to remember but which probably would be easier for a malefactor to crack. You might want to assign passwords, which is more secure in theory but increases the likelihood that users will write them down on a conveniently located scrap of paper — a risk if many people have access to the area where the machine(s) is located. You might decide that users must change their passwords periodically — something you can configure

Red Hat Enterprise Linux to prompt users about.

What happens to old accounts? Suppose that someone leaves the company.

You probably don’t want that person to gain access to the company’s network, but you also don’t want to delete the account wholesale, only to discover later that essential data resided nowhere else.

To what may specific users have access? It might be that there are aspects of your business that make Web access desirable, but you don’t want everyone spending their working hours surfing the Web. If your system is at home, you may wish to limit your children’s access to certain Web sites.

These and other issues are part of the system administrator’s duties in managing user accounts. Whether the administrator or his or her employer establishes policies governing accounts, these policies should be delineated — preferably in writing for a company — for the protection of all concerned.

Backing Up and Restoring Files

Until computer equipment becomes infallible, until people lose the desire to harm others’ property, and — truth be told — until system administrators become perfect, there is considerable need to back up important files so that

7

06_599496 ch01.qxd 8/30/05 6:18 PM Page 8

8 Chapter 1

the system can be up and running again with minimal disruption in the event of hardware, security, or administration failure. Only the system administrator may do this. (Because of its built-in security features, Linux doesn’t allow even users to back up their own files to removable disks.)

It’s not enough to know that performing backups is your job. You need to formulate a strategy for making sure your system is not vulnerable to catastrophic disruption. This is not always obvious. If you have a high-capacity tape drive and several good sets of restore disks, you might make a full system backup every few days. If you are managing a system with scores of users, you might find it more sensible to back up user accounts and system configuration files, figuring that reinstallation from the distribution CDs would be quicker and easier than getting the basics off a tape archive. (Don’t forget about applications you install separately from your Red Hat distribution, especially those involving heavy customization.)

Once you decide what to back up, you need to decide how frequently to perform backups, whether to maintain a series of incremental backups — adding only files that have changed since the last backup — or multiple full backups, and when these backups should be performed. Do you trust an automated, unattended process? If you help determine which equipment to use, do you go with a redundant array of independent disks (RAID), which is to say multiple hard drives all containing the same data as insurance against the failure of any one of them, in addition to other backup systems? (A RAID is not enough because hard drive failure is not the only means by which a system can be brought to a halt.)

You don’t want to become complacent or foster a lackadaisical attitude among users. Part of your strategy should be to maintain perfect backups without ever needing to resort to them. This means encouraging users to keep multiple copies of their important files in their home directories so that you won’t be asked to mount a backup to restore a file that a user corrupted. (If your system is a standalone one then, as your own system administrator, you should make a habit of backing up your configuration and other important files.)

Restoring files from your backup media is no less important than backing them up in the first place. Be certain you can restore your files if the need arises by testing your restore process at least once during a noncritical time. Periodically testing your backup media is also a good idea.

Chances are good that even if you work for a company, you’ll be the one making these decisions. Your boss just wants a system that runs perfectly, all the time. Backing up is only part of the story, however. You need to formulate a plan for bringing the system back up after a failure. A system failure could be caused by any number of problems, either related to hardware or software

(application, system configuration) trouble, and could range from a minor inconvenience to complete shutdown.

06_599496 ch01.qxd 8/30/05 6:18 PM Page 9

Duties of the System Administrator

Hardware failures caused by improper configuration can be corrected by properly configuring the device. Sometimes hardware failures are caused by the device itself, which typically requires replacing the device. Software failures caused by improperly configured system files are usually corrected by properly configuring those files. An application can cause the system to fail for many reasons, and finding the root of the problem may require a lot of research on the part of the administrator.

If you are the administrator of servers and workstations for a business, you should have a disaster recovery plan in place. Such a plan takes into account the type of data and services provided and how much fault tolerance your systems require — that is, how long your systems could be down and what effect that would have on your company’s ability to conduct business. If you require

100 percent fault tolerance, meaning your systems must be online 24/7, disaster recovery may be unnecessary in some circumstances as your systems never go down and there is no disaster from which to recover. Most organizations, though, cannot afford such a high level of fault tolerance; they are willing to accept less stringent standards. Based on the level of fault tolerance you require, your disaster recovery plan should list as many possible failures as you can anticipate and detail the steps required to restore your systems. In

Chapter 2 we describe fault tolerance and disaster recovery in more detail.

T I P

Backing up is only part of the story. You need to formulate a disaster recovery plan to bring your system back up in the event of a failure.

9

Monitoring and Tuning Performance

The default installation of Red Hat Enterprise Linux goes a long way toward capitalizing on existing system resources. There is no “one size fits all” configuration, however. Linux is infinitely configurable, or close to it.

On a modern standalone system, Linux runs pretty quickly. If it doesn’t, there’s something wrong — something the system administrator can fix. Still, you might want to squeeze one last little bit of performance out of your hardware — or a number of people might be using the same file server, mail server, or other shared machine, in which case seemingly small improvements in system performance add up.

System tuning is an ongoing process aided by a variety of diagnostic and monitoring tools. Some performance decisions are made at installation time, while others are added or tweaked later. A good example is the use of the hdparm utility, which can increase throughput in IDE drives considerably, but for some high-speed modes a check of system logs shows that faulty or inexpensive cables can, in combination with hdparm, produce an enormity of nondestructive but system-slowing errors.

06_599496 ch01.qxd 8/30/05 6:18 PM Page 10

10 Chapter 1

Proper monitoring allows you to detect a misbehaving application that consumes more resources than it should or fails to exit completely upon closing.

Through the use of system performance tools, you can determine when hardware — such as memory, added storage, or even something as elaborate as a hardware RAID — should be upgraded for more cost-effective use of a machine in the enterprise or for complicated computational tasks such as three-dimensional rendering.

Possibly most important, careful system monitoring and diagnostic practices give you a heads-up when a system component is showing early signs of failure, so that you can minimize any potential downtime. Combined with the resources for determining which components are best supported by Fedora

Core and Red Hat Enterprise Linux, performance monitoring can result in replacement components that are far more robust and efficient in some cases.

In any case, careful system monitoring plus wise use of the built-in configurability of Linux allows you to squeeze the best possible performance from your existing equipment, from customizing video drivers to applying special kernel patches or simply turning off unneeded services to free memory and processor cycles.

T I P

To squeeze the best performance from your equipment, monitor your system carefully and use Linux’s built-in configurability wisely.

Configuring a Secure System

If there is a common thread in Linux system administration, it is the security of the computer and data integrity.

What does this mean? Just about everything. The system administrator’s task, first and foremost, is to make certain that no data on the machine or network is likely to become corrupted, whether by hardware or power failure, misconfiguration or user error (to the extent that the latter can be avoided), or malicious or inadvertent intrusion from elsewhere. This means doing all the tasks described throughout this chapter, and doing them well, with a full understanding of their implications.

No one involved in computing has failed to hear of the succession of increasingly serious attacks on machines connected to the Internet. For the most part, these attacks have not targeted Linux systems. That doesn’t mean

Linux systems have been entirely immune, either to direct attack or to the effects of attacks on machines running other operating systems. In one distributed denial of service (DDoS) attack aimed at several major online companies,

06_599496 ch01.qxd 8/30/05 6:18 PM Page 11

Duties of the System Administrator 11

for instance, many “zombie” machines — those that had been exploited so that the vandals could employ thousands of machines instead of just a few — were running Linux that had not been patched to guard against a well-known security flaw. In the various Code Red attacks during the summer of 2001,

Linux machines themselves were invulnerable, but the huge amount of traffic generated by this worm infection nevertheless prevented many Linux machines from accomplishing much Web-based work for several weeks, so fierce was the storm raging across the Internet. And few email users have been immune from receiving at least some SirCam messages — nonsensical messages from strangers with randomly selected files attached from their machines. While this infection did not corrupt Linux machines per se, as it did those running MS Windows, anyone on a dial-up Internet connection who had to endure downloading several megabytes of infected mail each day would scarcely describe himself or herself as unaffected by the attack.

Depending on how a Linux machine is connected, and to what; the sensitivity of the data it contains; and the uses to which it is put, security can be as simple as turning off unneeded services, monitoring the Red Hat security mailing list to make sure that all security advisories are followed, regularly using system utilities to keep the system up to date, and otherwise engaging in good computing practices to make sure that the system runs robustly. It’s almost a full-time job, involving levels of security permissions within the system and systems to which it is connected; elaborate firewalls to protect not just Linux machines but machines that, through their use of non-Linux software, are far more vulnerable; and physical security — making sure that no one steals the machine itself!

For any machine connected to another machine, security means hardening against attacks and making certain that no one else uses your machine as a platform for launching attacks against others. If you run Web, FTP, or mail servers, it means giving access to only those who are entitled to it, while locking out everyone else. It means making sure that passwords are not easily guessed and not made available to unauthorized persons. It means that disgruntled former employees no longer have access to the system and that no unauthorized person may copy files from your machines.

Security is an ongoing process. The only really secure computer is one that contains no data, is unplugged from networks and power supplies, has no keyboard attached, and resides in a locked vault. While this is theoretically true, it implies that security diminishes the usefulness of the machine.

In the chapters that follow, you learn about the many tools that Red Hat provides to help you guard against intrusion, even to help you prevent intrusion into non-Linux machines that may reside on your network. Linux is designed from the beginning with security in mind. In all your tasks you should maintain that same security awareness.

06_599496 ch01.qxd 8/30/05 6:18 PM Page 12

12 Chapter 1

T I P

Your job as system administrator is to strike the right balance between maximum utility and maximum safety, all the while bearing in mind that confidence in a secure machine today means nothing about the machine’s security tomorrow.

Using Tools to Monitor Security

People who, for purposes of larceny or to amuse themselves, like to break into computers — they’re called crackers — are a clever bunch. If there is a vulnerability in a system, they will find it. Fortunately, the Linux development community is quick to find potential exploits and to create ways of slamming the door shut before crackers can enter. Fortunately, too, Red Hat is diligent in making available new, patched versions of packages in which potential exploits have been found. Your first and best security tool, therefore, is making sure that whenever a security advisory is issued, you download and install the repaired package. This line of defense can be annoying but it is nothing compared to rebuilding a compromised system.

As good as the bug trackers are, sometimes their job is reactive. Preventing the use of your machine for nefarious purposes and guarding against intrusion are, in the end, your responsibility alone. Red Hat equips you with tools to detect and deal with unauthorized access of many kinds. As this book unfolds, you’ll learn how to install and configure these tools and how to make sense of the warnings they provide. Pay careful attention to those sections and do what they say. If your machine is connected to the Internet, you will be amazed at the number of attempts made to break into your machine. You’ll be struck by how critical the issue of security is.

Summary

As you, the system administrator, read this book, bear in mind that your tasks are ongoing and that there is never a machine that is completely tuned, entirely up to date, and utterly secure for very long. The pace of Linux development is quite rapid, so it’s important to keep current in the latest breakthroughs. This book gives you the very best information as to the Red Hat distribution you’re using and tells you all you need to know about getting the most from it. Even more than that, you should read it with an eye toward developing a Linux system administrator’s point of view, an understanding of how the system works as opposed to the mere performance of tasks. As the best system administrators will tell you, system administration is a state of mind.

07_599496 ch02.qxd 8/30/05 6:20 PM Page 13

C H A P T E R

2

Planning the

Network

IN THIS CHAPTER

■■

■■

■■

■■

Deciding How Your Network Will Be Used

Planning and Implementing Security

Planning for Recovery from Disasters

Writing It Down: Good Records Can Save Your Job

While you can set up a Fedora Core or Red Hat Enterprise Linux network on the fly, your time will be spent most efficiently if you plan your network.

Preparation reduces confusion not just now but also in the future, makes provision for expansion later on, and ensures that you make the best use of your resources, both budgetary and system-related. Although setting up a huge network of hundreds of nodes requires planning beyond the scope of this chapter, we explore here the fundamentals of planning and preparing for your new network installation.

Deciding How Your Network Will Be Used

By definition and right out of the box, Linux is a network operating system. It is also nearly infinitely configurable: You can tailor a network to meet your precise needs. That is a tremendous strength but it can also be daunting when compared with systems that are more limited. As the philosopher James

Burnham said, “Where there is no alternative, there is no problem.”

Before you install Fedora Core or Red Hat Enterprise Linux on anything other than a standalone box just to take a look at it, you would be well advised to consider what kind of network you want to install, what it will be used for, what kinds of connections to the outside world it will have, and whether it is something you’re likely to expand later.

13

07_599496 ch02.qxd 8/30/05 6:21 PM Page 14

14 Chapter 2

Questions to ask include the following:

■■

What services do you wish to provide within your local network?

■■

Will your network be made up entirely of Linux machines or will boxes running other operating systems be connected to it?

■■

What devices (printers, scanners, and DSL, cable modem, or T-1 connections) do you plan to share?

■■

■■

Do you intend to host a Web site or an FTP site?

What security implications do you foresee?

■■

How many machines will make up your network?

It makes sense now to take notes and answer these questions. You can find details about setting up your network elsewhere in this book. But careful planning now lets you chart a clear path to developing a quick and efficient network and, perhaps even more important, helps you make sure that your network is secure from both internal and external mischief.

C R O S S - R E F E R E N C E

To learn more about setting up your network, see

Chapter 11.

For example, many people who now enjoy DSL or cable Internet service wish to set up small networks purely to allow the sharing of that broadband connection. Having a permanent Internet connection demands that you pay more attention to security, which means making sure that you don’t accidentally run any easily exploited services. If the network includes easily exploited operating systems, security becomes even more of a concern. Perhaps you will decide to set up a firewall on your Linux machine (or even set up a Linux box solely for firewall purposes). Or you might decide to employ one of the firewall-gateway-router network appliances that are gaining popularity and simply attach a hub to the appliance and attach each machine on the

“network” to that hub. Such a network may not be big, but it may be all you need or want.

T I P

A good rule of thumb is to provide the services for your network — and

only

those it needs.

Chances are good that you want to do more. Even if your needs are modest at first, adding services is simple in Red Hat Linux. Some features, such as printer sharing, you’ll probably set up at the beginning.

Before you do anything else, decide the physical layout, or topology, of your network — how machines are connected — and whether you want a peer-topeer or client-server network. These details matter because on the one hand you can overbuild your network so that your equipment isn’t used efficiently;

07_599496 ch02.qxd 8/30/05 6:21 PM Page 15

Planning the Network 15

on the other hand you can underestimate the demands on the network and end up slowing down one or more machines to near uselessness.

Understanding Topologies

Your network will probably be one of the first two of the following four commonly used topologies (at least for starters): star, bus, ring, and tree.

Star Topology

Think of this system as resembling a power strip with various devices plugged into it. In this case, instead of a power strip you have a network hub, and instead of devices requiring electricity you have devices needing and providing data. These devices might include computers, network-equipped printers, cable or DSL modems, a local network backbone, or even other hubs. Star topology networks are connected by twisted pair cabling, which looks like the cabling used in modular phone systems. Twisted pair cables and other devices are rated according to category (typically just called cat): Cat 3 uses two pairs of twisted wires as the standard for regular telephone service. Star topology networks usually use cat 5 twisted pair cabling, which has four twisted pairs and terminates in connectors called RJ-45s. (Your phone is connected with RJ-

11s.) You may have up to 1024 nodes — distinct machines or devices — on a star topology network, at speeds of up to 100 MB per second. The newest networking technology provides even faster speeds. Figure 2-1 shows an example of a star topology network.

Hub

Figure 2-1 A typical star topology network.

07_599496 ch02.qxd 8/30/05 6:21 PM Page 16

16 Chapter 2

Bus Topology

If star topology resembles a power strip with many devices plugged into it, bus topology physically resembles strings of old-fashioned Christmas tree lights, hooked together one after another. Of course, on your network there’s a lot more going on than what happens on a string of lights. On a bus topology network one machine is plugged to the next, which is plugged to the next, and so on. Two types of coaxial cable hold bus topology networks together: RG-8, often called Thicknet because of the thickness of the cable, and RG-58, often called Thinnet because it is thinner than RG-8. RG-8 is familiar at least in general form to anyone involved in amateur radio or anyone who has ever hooked up cable television. With this kind of topology, each end of the cable is specifically terminated by use of a “terminating resistor.”

Bus topology networks are limited to 30 machines. They were a very common style in early networks. While considered highly reliable, bus topology networks are not very fault tolerant because the failure of any device on the cable causes the entire network to fail. Also, their potential bandwidth (datahandling capacity) is limited to 10 MB per second. Nearly all modern networks use some type of star topology with cat 5 or better cabling. Figure 2-2 shows a typical bus topology network.

Ring Topology

Imagine those Christmas tree lights again. This time the end of the string plugs into its beginning, creating a loop. Popularized by IBM’s Token Ring system, ring networks are relatively difficult to set up but do offer high-bandwidth capabilities. Figure 2-3 shows a typical ring topology network.

Terminator

Coax Cable

Figure 2-2 A typical bus topology network.

Terminator

07_599496 ch02.qxd 8/30/05 6:21 PM Page 17

Planning the Network 17

Figure 2-3 A typical ring topology network.

Tree Topology

Although you almost certainly won’t undertake this system at the outset, you should know about it anyway. A tree network involves a high-speed “backbone” that is connected in the fashion of bus topology. However, instead of connecting individual machines, it connects groups of star topology subnetworks.

Many network backbones use fiber-optic cabling to achieve high throughput.

Figure 2-4 shows a typical tree topology.

Ultimately, your choice of network is determined by the equipment you already own and the amount of money you have to spend. If you are setting up a new network, speed, ease of configuration, and relatively low cost all argue in favor of establishing a star topology network.

07_599496 ch02.qxd 8/30/05 6:21 PM Page 18

18 Chapter 2

Network Subnet

Hub

Network

Backbone

Hub Hub

Figure 2-4 A typical tree topology network.

Client-Server or Peer-to-Peer?

In a client-server network, machines are dedicated to performing a variety of functions, in some ways like the old mainframe/dumb terminal days. You might, for instance, have a print server that handles print jobs for every computer on the network — a highly useful arrangement if, for example, yours is an enterprise that prepares many invoices, contracts, or other documents. Or you might have a file server, whose sole purpose is to serve up “boilerplate” documents or the contents of a huge database, or to serve as the repository of a big project on which many people collaborate. If your enterprise has an online presence, you may wish to dedicate one machine (or more) as a Web server, and perhaps one or more machines as a File Transfer Protocol (FTP) server, so that people can download (and upload) files. You’ll probably need some kind of mail server to handle both external email and messages sent within the network. Clients are machines connected to such a network. They are not servers; instead, they rely on network services provided by the server machines. Clients are usually full, freestanding workstations, although it is possible to connect dumb terminals — monitor, keyboard, pointing device — to such a network in some circumstances. To use the services provided by the server(s), clients need to have accounts on the desired server(s) and must log in to those accounts.

07_599496 ch02.qxd 8/30/05 6:21 PM Page 19

Planning the Network 19

A peer-to-peer network resembles a client-server network in that the machines are wired to each other and some services are shared. But in a peer network, those shared items — a CD reader, perhaps, or a printer — reside on machines that are also used for other purposes. If you have a very small, low-traffic network, a peer-to-peer system might be right for you because it requires no dedicated server machine(s). Peer networking can prove impractical for highvolume operations because, for instance, multiple big print jobs will keep the poor soul who shares his printer from getting much else done.

What’s in the Mix?

If you are only a little bit familiar with Red Hat Enterprise Linux, your exposure to it has probably relied on industry press reports extolling its suitability as a server operating system. There is no doubt that it is indeed superb for this purpose. Don’t make the mistake, though, of thinking that this is all it is good for. Red Hat Enterprise Linux comes with a full range of powerful and secure server applications. (Secure by industry standards, although security is a process, not a state of being.) It also comes with powerful, attractive, and easyto-use graphical desktops and a wide range of productivity applications, communications tools, and yes, even amusements, which make it an ideal client or peer operating system as well.

Your network may be a mixed marriage of machines of different architectures and operating systems. For instance, your graphics design department would probably rather paint with their fingers on a cave wall than use anything other than a Macintosh. Meanwhile your legacy applications, boilerplate documents, and relations with paying customers dictate that you maintain one or more Windows machines. In these cases, choose a client-server arrangement with a secure Red Hat box serving as a firewall between your network and the outside world, a mail server (it is now easy with Linux to filter out email attachments of the sort that have caused so much disruption of Windows networks in recent years), a Web server if you have a presence in that milieu, and even perhaps a print server.

Although many peer functions can be performed on a mixed network, your job as system administrator is much easier if you undertake the more straightforward client-server approach with a mixed installation. Additionally, if your network includes machines running Windows and is connected to the Internet, you would be irresponsible not to set up a firewall and let Linux handle

Web, FTP, and mail services. History has shown that Linux is more secure in its fundamental architecture. Beyond that, however, there are thousands of eyes constantly searching for and fixing potential security exploits. Red Hat is often first to make these fixes available, usually before the exploits are known to the cracker crowd.

07_599496 ch02.qxd 8/30/05 6:21 PM Page 20

20 Chapter 2

T I P

If your network includes machines running Windows and is connected to the Internet, set up a firewall and let Linux handle your Web, FTP, and mail services.

A client-server network acts very much like a small Internet: just about any machine can connect to it and make use of its services, irrespective of its architecture or operating system.

Determining System Requirements

Depending on the kind of network you choose, you need, of course, computers and any devices you intend to connect to the hub (if you’re using a star topology network). Don’t forget an appropriate and supported Ethernet card for each machine — two for your firewall machine because it has one line in from the outside world and one line out to the rest of your network. You also need the appropriate cabling and, if you go the recommended star topology route, one or more hubs to support the network.

Fedora Core and Red Hat Enterprise Linux have excellent support for a broad range of Ethernet cards. Still, there are some factors to take into consideration. If you have old, 8-bit Ethernet adapters, now is the time to replace them. They are slow and often difficult to configure. Now that 100-Mbps cards are quite inexpensive, it’s probably not a good idea to invest in a slower card that’s slightly cheaper. Be sure to check the Red Hat hardware database at www.redhat.com/support/hardware before buying new cards; in fact, it’s a good idea to go here to make sure that the ones you do have are fully supported if you’re upgrading to Red Hat Linux. (You don’t need to do this for

Windows machines connected to an existing network because as long as they’re properly configured for use with Windows, and as long as you continue to use Windows with them, they will work on your network, even though it’s served by Red Hat machines. Of course, if you use 8-bit or older, slow peer network cards and you’re going to star architecture, you need to replace them too.)

T I P

If you have old, non-PCI Ethernet adapters, now is the time to replace them.

At this stage, you need to decide which headaches you’re willing to accept and which ones might more sensibly be placed elsewhere. An example of this is Web and FTP hosting. For a few dollars per month, you can arrange for your

Web site (and FTP site, if you have one) to be hosted by a large and secure commercial enterprise. Although it’s fun to host your own site, it may be much more cost-effective to outsource those duties. The best ones have strict security

07_599496 ch02.qxd 8/30/05 6:21 PM Page 21

Planning the Network 21

rules — assigned passwords and administrator access by SSH or other highly secure methods only — and offer very high bandwidth and professional administration. With such an arrangement, you can still have your own domain and still use your own local mail server, with mail downloaded from your hosting company. (Your own SMTP mail server for outgoing mail remains on a local machine.) For many smaller companies, the cost of outsourcing is more than covered by the ability to use a low-cost cable or DSL service whose terms of use prohibit Web and FTP servers, meaning that you gain an extra level of professional service at no cost — quite a bargain. Of course, if your enterprise is of sufficient size that you have a T-1 line and a huge server farm, there’s little to gain by not hosting your site yourself.

Planning and Implementing Security

We cannot overstate the importance of computer security. Practically every day there are new stories of large and small systems’ being cracked by vandals and other criminals. Enterprises have been held hostage as criminals threatened to release the credit card numbers of thousands or hundreds of thousands of customers. Not long ago, the entire Internet was slowed drastically because hundreds of thousands of machines, many of whose owners weren’t even aware they were running Web server software, were hijacked by a series of increasingly vicious and efficient “worm” programs that tried to corrupt other machines. The attack grew to the point where there were so many machines at work scanning the Internet for potential victims that much of the

Internet’s bandwidth — practically all of it in some places — was consumed.

System administrators who allow machines under their control to be vulnerable to this kind of attack, when there is an alternative, are certainly not doing their jobs as completely as they should be.

Addressing External and Internal Threats

The threats from the outside world are very real and very frightening. The extent to which data on your network is safe from prying eyes or random acts of destruction is entirely up to you. But your concerns cannot stop there. While cracker attacks get all the press, there are security concerns just as real that you can find within your own network, whether it’s a 500-node affair in an enterprise or a 3-node setup at home.

Imagine the damage that a disgruntled employee could do or, for that matter, a child disappointed at being grounded. Imagine what harm a dishonest employee could bring about, upon gaining access to company accounts or company secrets, or a troubled teenager who finds your credit card number, which you should never put on your computer.

07_599496 ch02.qxd 8/30/05 6:21 PM Page 22

22 Chapter 2

There is also the security issue of a user who simply makes a mistake that could have destroyed crucial data or brought down the entire system had certain security safeguards not been in place.

Take advantage of all the multiple lines of defense available, no matter the size of your network, even if you have a single standalone system that is physically accessible to others or that is connected to the Internet. Otherwise, assume that anything on your network (or the machines on it) is accessible to anyone else in the world who is a little bit determined to get it. Part V deals with security issues in great detail, but much of your security policy needs to be established before you install the network.

C R O S S - R E F E R E N C E

To learn more about security, see Chapters 33 and 34.

Formulating a Security Policy

What should your security policy consist of? It should encompass an effective password policy, general security rules, security updates, and an appropriate firewall system.

An Effective Password Policy

Although the method brings grumbles from users, assigned, random passwords made up of a combination of numbers and uppercase and lowercase letters, all with no discernable meaning, are safest. (This procedure includes, most especially, the root account password.)

Who has access to what? Red Hat Enterprise Linux enables you to create special groups and assign users to them. This means that some users might have access to devices such as CD burners and modems, while others would not. You may have sensitive situations in which you do not want users to send files or even carry them from the building on a floppy disk. You can provide increased security by using groups. Although you don’t necessarily have to set this up first thing, it’s important to plan for and good to keep in mind.

General Security Rules

A server that isn’t running cannot be used to crack your system. If you’re not using a server application, don’t run it. Change all passwords periodically. Be prompt in removing network access of any employee who is discharged.

Employ intrusion detection software and check your logs regularly for anything unusual.

07_599496 ch02.qxd 8/30/05 6:21 PM Page 23

Planning the Network 23

Security Updates

Do you subscribe to the Red Hat Linux security mailing list? (Find it at www.redhat.com/mailing-lists/linux-security/index.html

.)

Have you established a procedure that makes sure that every security update is downloaded and installed? Luckily for you, Red Hat has created the Red

Hat Network, a program intended to help keep your system updated with the latest security updates.

C R O S S - R E F E R E N C E

Learn how to use the Red Hat Network in Chapter 26.

An Appropriate Firewall System

If yours is a standalone box on a broadband connection, the bare minimum is an Internet firewall-gateway-router appliance plus iptables. If you run a Web site, set up a separate firewall machine. (The more experienced administrator could go so far as to create a custom firewall on a bootable CD and then boot the firewall machine from that CD. It is impossible to install a root kit on a CD, and the machine can have a hard drive for logging purposes.)

Security is a process — a matter of constantly outwitting people who wish your network ill. Red Hat Enterprise Linux goes a long way toward helping you beat crackers to the punch. It’s up to you to make sure that your machine is not just buttoned up tightly today but continues to be secure tomorrow and the day after.

Planning for Recovery from Disasters

Rare is the professional system administrator who hasn’t been awakened in the middle of the night or who had to work an entire weekend to recover from some tremendous mishap. Likewise, rare is the owner of a standalone machine who hasn’t spent frantic hours trying with varying degrees of success to recover from a catastrophic failure of hardware, software, or execution.

When you plan your systems, it is critical to keep in mind two important terms: fault tolerance and disaster recovery. Fault tolerance is the system’s ability to respond automatically to various conditions that can affect system operation and resolve the condition. By responding automatically to a problem, fault tolerance reduces the effect of the problem on the system. Properly implemented fault tolerance is transparent to users of the system. They will continue to work, totally unaware that any problem has occurred.

Disaster recovery is the ability to restore functionality to the system after a failure has occurred. The system administrator must implement this process; it

07_599496 ch02.qxd 8/30/05 6:21 PM Page 24

24 Chapter 2

does not occur automatically. The goal of disaster recovery is to restore full functionality as quickly as possible. Depending on the degree of fault tolerance your systems have, disaster recovery may not be necessary at all.

Planning for fault tolerance and disaster recovery requires that you assess the needs of your systems. The following two questions are the most important ones you should ask:

■■

■■

How critical are the systems to daily operation?

Could the systems be down and not affect operations?

Obviously, if your systems are used for business, they could not be down for long, if at all. You must determine how vital a given system is to your operation. Vital systems require greater fault tolerance than nonvital systems do. Be sure to keep in mind that greater fault tolerance costs more than less fault tolerance does. Another important consideration is the amount of money available for building fault tolerance into your system. Balance your need for fault tolerance with the amount of money you can spend on it.

Clustering Solutions

If your systems must be up 24/7, you have to rely on a clustering solution for your fault tolerance. You basically have two choices for clustering: failover clustering and true clustering. Both of these solutions are costly to implement and require a great deal of configuration. Configuring these types of systems is well beyond the scope of this book, but a brief description of the two types of clustering is useful.

Failover clustering typically requires two systems. The first system is the active system that responds to service requests. The second, failover system is an exact copy of the first system that is connected to the first system by a dedicated link. The second system uses the dedicated link to listen for a signal — called a heartbeat — from the first system at a specified interval. The second system does nothing but listen to the heartbeat signal from the first system. If the second system does not receive the signal, it assumes that the first system has gone offline and immediately begins accepting requests for services. When the first system comes back online, the second system returns to monitoring the heartbeat signal.

True clustering uses multiple systems, usually more than two, often in different locations, that act as a single system. Network services run on each system and requests for services are distributed between the systems. Each system is connected to every other system by a dedicated link. Unlike the second system in failover clustering that only listens for the heartbeat, the systems in true clustering handle requests for services. If a system does go down, the requests for service are just sent to the other systems, which take up the slack. Neither clustering solution employs disaster recovery. Because they

07_599496 ch02.qxd 8/30/05 6:21 PM Page 25

Planning the Network 25

must be up 100 percent of the time, there is no disaster from which to recover, except perhaps the disaster to your budget because the cost of implementing such a system is quite high.

Disaster Recovery

For systems that do not require 100 percent uptime, disaster recovery is the method used. A typical solution is to configure an identical system and keep it ready for service. Placing the other system into service requires intervention by the administrator and no services will be possible during this time. Service can usually be restored fairly quickly using this method, and the cost is less than the cost of a clustering solution.

The least costly method (in hardware) of dealing with system problems is to fix them after they have occurred. Here, you shut down the system until it is fixed; no services are available during the repair. For example, if the hard drive in your system crashes, you simply replace the hard drive.

System administrators who plan their network well may not be able to prevent disasters entirely, but they greatly reduce the likelihood of such events taking place and make complete or near-complete recovery a quick and orderly process.

Planning for recovery ideally involves considering everything bad that can possibly happen and figuring out a way around it. However, that which is ideal often does not square with what’s practical, especially when it involves spending money to guard against an infinitesimal likelihood. Fortunately, the things that save you from likely disasters save you from the most unlikely ones, too.

Just as security planning requires attention to threats from outside and inside the network, there are two parts to disaster planning. The first is doing everything you can to prevent a catastrophe from taking place.

Only you, or other administrators at your organization, know how important your system is and how much money is budgeted to keep it running.

Chances are good that an uninterruptible power supply (UPS) that keeps the network up long enough to save and close files and shut down the system in an orderly fashion fits within the available budget. A good UPS system is especially useful if your enterprise has a generator backup that kicks on in the event of power failure because generators do not always start instantly and, when they do, the electricity provided is not always clean enough for computer use. A battery backup can protect you from both of these potential problems. If your enterprise is important enough to have an emergency generator, it’s probably important enough to keep the network running.

Renegade electricity is one of the worst enemies of system reliability. Small power strips with surge suppression are better than nothing, but more robust power conditioning is needed if really important equipment and data are to be protected. In fact, be sure to protect all lines from the outside world that attach

07_599496 ch02.qxd 8/30/05 6:21 PM Page 26

26 Chapter 2

to your computer or its peripherals, be they phone lines or cable or DSL connections. Likewise, put the peripherals themselves on protected circuits.

Second, formulate a regular (daily or better) backup scheme, with one set of backups stored in a safe place off-site as protection against loss of data in the event of fire, flood, tornado, or other physical disaster. One way of making this process relatively painless, albeit an expensive one, is to rent storage from a commercial operation whose business is storing other people’s data. The best firms are very responsive and secure.

Redundancy is also important. Make sure that your plans don’t put critical data on only one machine. That way, in the event of a machine failure, a replacement machine with a copy of your critical data can be put online very quickly. This is some, but not all, of the theory behind redundant array of independent disks (RAID) systems, in which multiple hard drives in the same machine contain the same data. RAID is good protection in case any one drive fails. (The best RAIDs allow the hot-swapping of drives so that a replacement can be added without bringing the system down.) But RAID also allows for much faster data access, making it especially useful for file server machines.

Don’t be lulled into complacency by a RAID, though; there are computer failure modes that can render an entire system useless. In keeping with Murphy’s

Law, the worst failures and calamities occur at the worst possible time — just before the rollout of a new product, just as the monthly billing is scheduled to go out, in the middle of the worst blizzard in 10 years, or when most of the computer staff is on vacation or out sick. You need to establish an emergency response policy that takes these examples, and there are many others, into account. This involves convincing your employer of the necessity of having sufficient staff to guard against such horrors, or even the employment of an outside firm to augment your own staff in the event of an especially ill-timed disaster. If your company follows the latter route, it’s well worth the investment of time and money to make sure that the outside firm’s representatives tour and learn your network on a day when everything is working smoothly.

Some of this planning is far more elaborate than anything you’re likely to undertake if you have only a small household network or a very small office; on the other hand, if you’re in a very large enterprise, data security and system integrity involve issues and procedures far beyond the scope of this book.

Everything mentioned in this section, however, can be scaled to fit any network.

Writing It Down: Good Records Can Save Your Job

A very important part of network planning is to put it all down on paper and to save that piece of paper. Working out your network’s design is best done by actually diagramming the network, making multiple diagrams to explore different strategies. Once you settle on a design, draw a more formal diagram.

07_599496 ch02.qxd 8/30/05 6:21 PM Page 27

Planning the Network 27

Sometimes it’s a good idea to save your discarded designs as well, with a note on each version explaining why it wasn’t chosen. Formalizing the network design and saving the discarded ideas is useful for several reasons. It bolsters your decisions in case you’re second-guessed, it demonstrates that you considered all the possibilities, and the formal diagram is a valuable tool should someone need to administer the system in your absence.

A written security policy is essential in the enterprise and not a bad idea even for a home network. An additional security file you should always keep is a full security log. Such a record might begin by detailing what security measures you have designed into the system. It should include copies of any security notices you have received, as well as an initialed notation of when the recommended security patch was applied. If log files show an attempted crack of your network, hard copies of the relevant portions should be kept there, too.

When users or management complain about how you have the system so tight that it seems inconvenient even for them to log in, there’s nothing like proving that the system is regularly under attack — and it will be, by port scanners and others — to demonstrate the wisdom of tight security. One very big company has made huge amounts of money by putting user convenience over security, and many companies have paid a high price for adopting their products. Your Red Hat system costs a very small amount in user inconvenience in exchange for greatly enhanced system security. It’s useful to be able to prove that the threat is real.

A security log is also the place to keep copies of any security-related email messages from within the company, from log listings of employees who have decided to “go exploring” (which is sometimes but not always a sign of bad intent) to exchanges with management over the implementation of new security features. This file is not something for general consumption, but it’s very important. Keep a copy locked away at work, and it won’t hurt to keep a copy safely off-site, too.

C R O S S - R E F E R E N C E

To learn more about writing a security policy, see

Chapter 34.

While your security log should detail actions you have taken to prevent disaster and actions you have recommended in that regard, your plan of action in the event of a catastrophe should also be committed to paper and should be well known and easily available. If you are the sole administrator, it is far better to work out your plan of action calmly and ahead of time, which of course you will have done. But under the stress of an actual emergency, it is easy to forget important details. Having a specific plan on paper right in front of you is a big help and a great stress reliever. Your action plan should be sufficiently detailed so that if the disaster takes place while you are away, any competent

07_599496 ch02.qxd 8/30/05 6:21 PM Page 28

28 Chapter 2

system administrator can use it to bring the system back up. If you are part of a larger department, include the assignments of others in restoring the system.

In either case, someone who is completely trusted and who is never on vacation at the same time you are should know the root’s password. Alternately, the password can be placed in a sealed envelope inside the company safe — the one time it is allowable to put a password on paper.

T I P

Keep a hard copy of your security log in a safe place!

We’re all happy with the idea of the paperless office, but until computers become perfectly reliable, paper — as a roadmap, indicating where you are and how you arrived there — will remain necessary.

Summary

In this chapter you learned the importance of planning your network before you begin to construct it, discovered some of the options available to you, and found out some of the reasons why you might choose one over another. You learned that network security is a never-ending task made easier by careful planning and that threats can come both from outside the network and from among its users. Working to prevent catastrophic failures and having a plan to recover from them is something you’ve learned to do. You now know the importance of putting it all on paper as you proceed, too.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 29

C H A P T E R

3

Standard

Installation

IN THIS CHAPTER

■■

■■

■■

■■

■■

■■

■■

■■

■■

Exploring Your PC’s Components

Checking for Supported Hardware

Creating the Red Hat Boot Disk

Starting the Installation

Partitioning the Hard Disk

Using Disk Druid to Partition Your Disks

Configuring the Installation

Selecting the Package Groups to Install

Running Firstboot

This chapter explains the steps necessary to install Red Hat Enterprise Linux and

Fedora Core on a single system. You begin by making a list of your PC’s hardware. You use this hardware inventory later when you begin the installation.

N OT E

When you purchase Red Hat Enterprise Linux, you are eligible for installation support from Red Hat. Also, an online installation manual is

available on the Red Hat Web site at www.redhat.com/docs. There is no

official support for Fedora Core from Red Hat.

N OT E

The installation processes for Red Hat Enterprise Linux and Fedora

Core are nearly identical. Throughout the remainder of this chapter, we will refer to both Red Hat Enterprise Linux and Fedora Core as Red Hat Linux except in the instances where it is necessary to make a distinction between them. The figures in the chapter show the Fedora installation screens, but with the exception of the name on the screen (Fedora or Enterprise Linux), the content of the installation screens is identical.

29

08_599496 ch03.qxd 8/30/05 6:20 PM Page 30

30 Chapter 3

Exploring Your PC’s Components

Before installing Red Hat Linux, you should compile a list of the hardware components in your computer. Linux supports different types of hardware through software components called device drivers, similarly to other operating systems. A driver is required for each type of peripheral device; depending on the age of your hardware, a driver may not be available. If your hardware is current, meaning less than two years old, the drivers you need are probably available and included with the distribution. If you need a driver that is not included with the distribution, searching the Internet usually provides you with a solution.

You can install and run Red Hat Linux even if no Linux drivers are available for certain devices. Of course, those devices won’t function, but this may not be a problem for you, depending on the device. To be able to install Red Hat

Linux, you must have a compatible processor, bus type, floppy disk, hard disk, video card, monitor, keyboard, mouse, and CD-ROM drive. If you are planning to use a graphical user interface (GUI), such as GNOME or KDE, you must ensure that XFree86 (the X Window System for Linux) supports the mouse, video card, and monitor. Nearly all devices made within the past two years are supported.

The following sections briefly describe the supported PC hardware. Your hardware list should contain information about the hardware described here before you begin to install Red Hat Linux on your PC.

Processor

The central processing unit (CPU) — or just the processor — is an integrated circuit chip that performs nearly all control and processing functions in the PC.

Both Red Hat Enterprise Linux and Fedora Core run on an Intel 80386 processor or newer, as well as compatibles made by AMD or Cyrix. However, you probably don’t want to use any processor older than a Pentium-class processor. Red Hat Linux also supports motherboards with multiple processors that use the symmetric multiprocessing (SMP) Linux kernel.

Bus

The bus provides the electrical connection between the processor and its peripherals. Several types of PC buses exist on the motherboard with slots to accept peripheral components. Each of the slots is colored to help in its identification.

The most recent is the Peripheral Component Interconnect (PCI) bus, and it is found on all current production motherboards. The PCI slot is white and is available in 32- and 64-bit form as well as 33 and 64 MHz. The new PCI-X standard will

08_599496 ch03.qxd 8/30/05 6:20 PM Page 31

Standard Installation 31

support speeds up to 533 MHz. Another type of slot is also based on the PCI bus specifications, but offers significant advantages over the PCI bus. The Accelerated

Graphics Port (AGP) is a special slot on the motherboard designed to accept an

AGP graphics card. The AGP slot is brown. Another is the Industry Standard

Architecture (ISA) bus, formerly called the AT bus because IBM introduced it in the IBM PC-AT computer in 1984. The ISA bus is black. Other, less frequently encountered, buses because of their aging status include Extended Industry Stan-

dard Architecture (EISA); VESA local (VL-bus); and Micro Channel Architecture

(MCA). Red Hat Enterprise Linux supports all of these buses.

Memory

Referred to as random access memory, or RAM, is not a consideration in determining compatibility. This means that Linux does not care what kind of memory it is or how fast it is, it just uses whatever is there. For good performance though, you need at least 64 MB of RAM for a text install and 192 MB for a graphical install. If you are planning to run the X Window system to use a graphical user interface (GUI) on the PC, you need even more memory because the X Window System manages the graphical interface through an X server, which is a large program that needs a lot of memory to run efficiently.

Red Hat recommends a minimum of 256 MB RAM to run a graphical system.

T I P

If you are buying a new PC, it probably comes with 128 MB or more RAM.

If you can afford it, buy as much RAM as you can. The more RAM a system has, the more efficiently it runs multiple programs (because the programs can all fit in memory). Red Hat Linux can use a part of the hard disk as virtual memory.

Such disk-based memory, called swap space, is much slower than physical memory.

Video Card and Monitor

If you are not planning to use the X Window system, any video card works.

Red Hat Linux supports all video cards in text mode. If you are planning to use the X Window system, be sure to find a video card that is supported by

XFree86, which is the version of the X Window System used in Red Hat Linux.

It is pretty unlikely that you would find a video card that doesn’t work with X, but you can save yourself a lot of aggravation if your video card is supported by XFree86.

Your choice of monitors depends on your use of the X Window system. For text mode displays, typically used on servers, any monitor will do. If you are setting up a workstation, or using the X Window system on your server, choose

08_599496 ch03.qxd 8/30/05 6:20 PM Page 32

32 Chapter 3

a monitor that supports the display resolution you use. Resolution is expressed in terms of the number of picture elements, or pixels, horizontally and vertically

(such as 1024

×

768).

XFree86’s support for a video card depends on the video chipset — the integrated circuit that controls the monitor and causes the monitor to display output. You can find out the name of the video chipset used in a video card from the card’s documentation.

Your video card’s name may not be in the list at the Red Hat site. The important thing to note is the name of the video chipset. Many popular video cards made by different manufacturers use the same video chipsets. Look for the name of the video chipsets listed at the Red Hat site. In nearly all cases, the Red

Hat installation program automatically detects the video chipset as it sets up the X Window System.

Hard Drive

Red Hat Linux supports any IDE hard drive that your PC’s basic input/output

system (BIOS) supports, as long as the system BIOS supports the hard drive without any additional drivers. This would include EIDE- and ATA-compatible drives as well.

For hard drives connected to your PC through a Small Computer System

Interface (SCSI) controller card, Red Hat Linux must have a driver that enables the SCSI controller to access and use the hard drive. If you have a recent SCSI controller card, there is most likely a driver for it already included with the distribution.

Also supported are Serial Advanced Technology Attachment (SATA) drives, which use serial technology instead of the parallel ATA technology currently used by IDE drives. SATA provides a significant speed increase over IDE.

As for the size (storage capacity) of the drive, most new systems seem to have drives 20 GB or larger. You should buy the highest capacity drive you can afford.

Floppy Disk Drive

Linux drivers use the PC BIOS to access the floppy disk drive, so any floppy disk drive is compatible with Red Hat Linux. The Red Hat installation program can be started from the CD-ROM if your PC has one and is able to boot from it.

If not, you have to boot Red Hat Linux from a floppy disk drive during the installation, so you need a high-density 3.5-inch (1.44-MB capacity) floppy disk drive. You can also avoid booting from a floppy if you can boot your PC under

MS-DOS (not an MS-DOS window under Windows 95/98/2000), and you can access the CD-ROM from the DOS command prompt.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 33

Standard Installation 33

Keyboard and Mouse

Red Hat Linux supports any keyboard that already works with your PC. The mouse, however, needs explicit support in Red Hat Linux. You need a mouse if you want to configure and run XFree86, the X Window System for Linux. Red

Hat Linux supports most popular mice, including the commonly found PS/2 and USB mouse. Red Hat Linux also supports touch pad devices, such as ALPS

GlidePoint, as long as they are compatible with one of the supported mice.

SCSI Controller

The Small Computer System Interface, commonly called SCSI (and pronounced

“skuzzy”), is a standard way of connecting many types of peripheral devices to a computer. SCSI is used in many kinds of computers, from servers to high-end

UNIX workstations to PCs. Typically, you connect hard drives and CD-ROM drives through a SCSI controller. To use a SCSI device on your PC, you need a SCSI controller card that plugs into one of the bus connector slots on your

PC’s bus.

If you want to access and use a SCSI device under Linux, you have to make sure that Red Hat Linux supports your SCSI controller card.

CD/DVD-R/RW Drive

CD-R (compact disc read-only) drives are popular because each CD-ROM can hold up to 650 MB of data, a relatively large amount of storage compared with a floppy disk. CD-ROMs are reliable and inexpensive to manufacture. Vendors can use a CD-ROM to distribute a large amount of information at a reasonable cost.

DVD-ROM drives are found already installed on many new systems. DVD-

ROM discs are capable of storing up to 4.7 GB and are most frequently used to record digital video, but can be used to hold any data.

CD-RW and DVD-R/RW and DVD+R/RW drives are used to create CDs and DVDs, respectively. Either of these types of drives can be used in your Red

Hat system. Any IDE/ATAPI-compatible drive, as well as SCSI drives, will work with Red Hat Enterprise Linux.

Sound Card

If you are configuring a server, you probably aren’t too interested in playing sounds. But with Red Hat Linux you can play sound on a sound card to enjoy multimedia programs and games. If you have a sound card, you can also play audio CDs. Nearly all sound cards available today, whether built into the motherboard or a separate card that plugs into a bus socket, are supported.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 34

34 Chapter 3

Network Card

A network interface card (NIC) is necessary if you connect your Red Hat Linux

PC to a local area network (LAN), which is usually an Ethernet network. If you are configuring a server, you certainly want to configure at least one network card. Red Hat Enterprise Linux supports a variety of Ethernet network cards.

ARCnet and IBM’s Token Ring network are also supported. Check the hardware list on the Red Hat site to see if your NIC is supported. Nearly all NICs currently in use are supported.

For any Red Hat Linux PC connected to a network, you need the following information:

■■

Hostname of the PC

■■

■■

Domain name of the network

Internet Protocol (IP) address of the PC

■■

■■

Address of the gateway

IP address of name servers

N OT E

If you plan to use DHCP to obtain your IP information, you do not need to specify the IP information in the above list.

Checking for Supported Hardware

To check if Red Hat Linux supports the hardware in your PC, follow these steps:

1. Make a list of the make, model, and other technical details of all hardware installed in your PC. Most of this information is in the manuals that came with your hardware. If you don’t have the manuals, and you already have an operating system (MS Windows for example) on the

PC, you may be able to obtain this information from that operating system. Refer to that operating system’s instructions for obtaining hardware information.

2. Go to the Red Hat Web site at redhat.com/hardware. Compare your hardware list to the list of hardware that the latest version of Red Hat

Linux supports. If the components listed earlier are supported, you can prepare to install Red Hat.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 35

Standard Installation 35

N OT E

You do not need a boot disk if you can start your PC from your CD-ROM drive. The first installation disk is a bootable CD-ROM and can be used to start the installation process. If you can boot from your CD-ROM, skip to the “Starting the Red Hat Linux Installation” section. If you are unable to boot from your

CD-ROM drive, continue to the next section, “Creating the Red Hat Boot Disk,” and then go to the installation section.

Creating the Red Hat Boot Disk

To boot Red Hat Linux for the first time and start the Red Hat Linux installation program, you need a Red Hat boot disk. For this step, you should turn on your PC without any disk in the A drive and run Windows as usual.

N OT E

You do not need a boot disk if you can start your PC under MS-DOS

(not an MS-DOS window in Windows) and access the CD-ROM from the DOS command prompt. If you run Windows, restart the PC in MS-DOS mode.

However, you may not be able to access the CD-ROM in MS-DOS mode because

the startup files (AUTOEXEC.BAT and CONFIG.SYS) may not be configured

correctly. To access the CD-ROM from DOS, you typically must add a CD-ROM

driver in CONFIG.SYS and add a line in AUTOEXEC.BAT that runs the MSCDEX

program. Try restarting your PC in MS-DOS mode and see whether the CD-ROM can be accessed.

The Red Hat boot disk starts your PC and the Red Hat Linux installation program. After you install Red Hat Linux, you no longer need the Red Hat boot disk (except when you want to reinstall Red Hat Linux from the

CD-ROMs).

The Red Hat boot disk contains an initial version of the Red Hat Linux installation program that you use to start Red Hat Enterprise Linux, prepare the hard disk, and load the rest of the installation program. Creating the Red

Hat boot disk involves using a utility program called RAWRITE.EXE to copy a special file called the Red Hat Linux boot image to a disk.

To create the Red Hat boot disk under Windows, follow these steps:

1. In Windows 95/98/ME open an MS-DOS window (select Start ➪ Programs ➪ MS-DOS Prompt). In Windows 2000 or XP, select Start ➪ Run and enter cmd in the dialog box.

2. In the MS-DOS window, enter the following commands at the MS-DOS prompt. (Our comments are in parentheses and your input is in boldface.)

08_599496 ch03.qxd 8/30/05 6:20 PM Page 36

36 Chapter 3

a. d: (use the drive letter for the CD-ROM drive) b. cd \dosutils c. rawrite d. Enter disk image source filename: \images\boot.img e. Enter target disk drive: a f. Insert a formatted disk into drive A and press ENTER.

3. As instructed, you should put a formatted disk into your PC’s A drive and press Enter. RAWRITE.EXE copies the boot-image file to the disk.

When the DOS prompt returns, remove the Red Hat boot disk from the floppy drive and label it as a Red Hat boot disk.

Starting the Installation

To start the Red Hat Linux installation, power up the PC and put the Red Hat

Installation CD-ROM 1 (and the boot disk if you created one) into your PC’s

CD-ROM drive (and floppy drive if applicable). The PC boots Red Hat Linux and begins running the Red Hat installation program. The Red Hat installation program controls the installation of the operating system.

N OT E

If you are using a boot disk that you created, be sure to place the first installation CD-ROM in the CD-ROM drive after you start the PC. The installation program looks for the Red Hat Linux CD-ROMs to start the installation in graphical mode. If the installation program can’t find the CD-ROM, the installation program starts in text mode and prompts for it.

A few moments after you start the boot process, an initial screen appears.

The screen displays a welcome message and ends with a boot: prompt. The welcome message tells you that more information is available by pressing one of the function keys F1 through F5.

If you want to read the help screens, press the function key corresponding to the help you want. If you don’t press any keys after a short delay, the boot process proceeds with the loading of the Linux kernel into the PC’s memory.

To start booting Red Hat Linux immediately, press Enter.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 37

Standard Installation 37

N OT E

On CDs that you made from downloaded ISO files (Fedora Core) you are prompted to check the CD media for errors. The disk-checking process takes a few minutes but is time well spent to be sure there are no errors on your installation CDs. To begin disk checking, press Enter. You will be prompted to change the disks as required. You can also choose to skip disk checking by using the Tab key to highlight Skip and then pressing Enter. If you purchased

Red Hat Enterprise Linux, you are not prompted to check the disks.

After the Linux kernel loads, it automatically starts the Red Hat Linux installation program. This, in turn, starts the X Window System, which provides a graphical user interface for the installation.

You should compile all the configuration information explained earlier in this chapter before you begin. If the installation program detects your hardware, installing Red Hat Linux from the CD-ROM on a 200-MHz or better Pentium PC should take 30 to 40 minutes.

N OT E

During installation, the Red Hat installation program tries to determine the hardware in your PC and alters the installation steps as required. For example, if the installation program detects a network card, the program displays the appropriate network configuration screens. If a network card is not detected, the network configuration screens are not displayed. So, depending on your specific hardware, the screens you see during installation may differ from those shown in this section.

C R O S S - R E F E R E N C E

If you run into any problems during the installation, refer to Chapter 35 to learn how to troubleshoot common installation problems.

You go through the following steps before moving on to disk setup and installation:

1. The installation program starts the X Window System and displays a welcome message that provides some explanatory information on the left side of the screen. Take a look at this information and be sure to click the Release Notes button. When you are finished reading, click the Next button to proceed.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 38

38 Chapter 3

2. After clicking Next, a list of languages to use during the installation is displayed, as shown in Figure 3-1. Use your mouse to select the language you want to use for installation, and then click the Next button to proceed to the next step.

Figure 3-1 Choosing the installation language.

N OT E

In the graphical installation, each screen has online help available on the left side of the screen. You can read the help message to learn more about what you are supposed to select in a specific screen.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 39

Standard Installation 39

3. The installation program displays a list of keyboard language layouts, as shown in Figure 3-2. Select a keyboard language layout appropriate to the language you desire.

Figure 3-2 Selecting a keyboard configuration during Red Hat Linux installation.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 40

40 Chapter 3

4. The installation program searches for previous installations of Enterprise Linux or Fedora Core and displays a screen, shown in Figure 3-3, asking if you want to install a new system or upgrade an older Red Hat installation if one is detected. Select the choice that is appropriate for your system, and click Next to continue.

Figure 3-3 Choosing to install a new system or upgrade an existing one.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 41

Standard Installation 41

5. If you select new installation, the installation program displays a screen, shown in Figure 3-4, that requires you to select the installation type: Personal Desktop, Workstation, Server, or Custom.

Figure 3-4 Choosing the installation type for your system.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 42

42 Chapter 3

6. There is a brief description of each installation type, and you should choose the appropriate type for your system, depending on how you plan to use the system. After making your selection, click Next to go on to the Disk Partitioning Setup screen shown in Figure 3-5.

The next major phase of installation involves partitioning the hard disk.

Figure 3-5 Choosing to use automatic partitioning or manual partitioning.

Partitioning the Hard Disk

Red Hat Linux requires you to partition and prepare a hard disk before you can begin installation. With a new PC that you purchase from a vendor, you usually do not perform this step because the vendor normally takes care of preparing the hard disk and installing the operating system and other applications on the hard disk. Because you are installing Red Hat Linux from scratch, however, you have to perform this crucial step yourself. As you see in the following sections, this task is just a matter of following instructions.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 43

Standard Installation 43

The Red Hat Linux installation program offers you two choices for partitioning your hard drive. You can choose to have the installation program automatically partition your disk or you can choose to use Disk Druid to manually partition your drives. If you select automatic partitioning, the installation program does all the hard work for you and creates the partitions and allocates space for your file system. If you want to manually partition your disks, go to the section “Using Disk Druid to Partition Your Disks.”

1. To use automatic partitioning be sure the radio button in front of this choice is checked, and click Next on the Disk Partitioning Setup screen.

2. The Automatic Partitioning screen, shown in Figure 3-6, appears. Here you decide how automatic partitioning should handle existing partitions. You can choose to remove Linux partitions, remove all partitions, or keep all partitions and use free space. If you are installing a new system, you should choose to remove all partitions. A warning screen will appear asking if you are sure you want to remove all partitions. Click

Yes to continue.

Figure 3-6 Choosing how to use automatic partitioning on your disk partitions.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 44

44 Chapter 3

3. The Disk Setup screen shown in Figure 3-7 appears. The Disk Setup screen shows the partition setup that automatic partitioning has selected for your system. Click Next to accept the settings and go the section titled “Configuring the Installation.”

T I P

If you want to change any of the settings here you still can, but then you will be doing manual partitioning. Continue to the next section to learn how to manually partition your disks.

Figure 3-7 Reviewing the disk partitioning settings selected by automatic partitioning.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 45

Standard Installation 45

Using Disk Druid to Partition Your Disks

Before you begin to use Disk Druid to partition your disk, you need to know how to refer to the disk drives and partitions in Linux. Also, you should understand the terms mount points and swap partition. In the next three sections, you learn these terms and concepts and then proceed to use Disk Druid.

Naming Disks and Devices

If you are experienced with UNIX or Linux, this section and the two following are quite basic to you. If you are already familiar with UNIX and Linux file systems and naming conventions, skip to the section titled “Preparing Disk Partition.”

The first step is to understand how Red Hat Linux refers to the various disks.

Linux treats all devices as files and has actual files that represent each device. In

Red Hat Linux, these device files are located in the /dev directory. If you are new to UNIX, you may not yet know about UNIX filenames. But you’ll learn more as you continue to use Red Hat Linux. If you know how MS-DOS filenames work, you find that Linux filenames are similar. However, they have two exceptions: they do not use drive letters (such as A and C), and they substitute the slash (/) for the MS-DOS backslash (\) as the separator between directory names.

Because Linux treats a device as a file in the /dev directory, the hard disk names start with /dev. Table 3-1 lists the hard disk and floppy drive names that you may have to use.

Table 3-1 Hard Disk and Floppy Drive Names

NAME DESCRIPTION

/dev/hda

First Integrated Drive Electronics (IDE) hard drive (the C drive in

DOS and Windows) connected to the first IDE controller as the master drive

/dev/hdb

/dev/hdc

Second (IDE) hard drive connected to the first IDE controller as the slave drive

First (IDE) hard drive connected to the second IDE controller as the master drive

/dev/hdd

/dev/sda

/dev/sdb

/dev/fd0

/dev/fd1

Second (IDE) hard drive connected to the second IDE controller as the slave drive

First Small Computer System Interface (SCSI) drive or first SATA drive

Second SCSI drive or second SATA drive

First floppy drive (the A drive in DOS)

Second floppy drive (the B drive in DOS)

08_599496 ch03.qxd 8/30/05 6:20 PM Page 46

46 Chapter 3

T I P

When Disk Druid displays the list of partitions, the partition names take

the form hda1, hda2, and so on. Linux constructs each partition name by

appending the partition number (1 through 4 for the four primary partitions on a hard disk) to the disk’s name. Therefore, if your PC’s single IDE hard drive has

two partitions, notice that the installation program uses hda1 and hda2 as the

names of these partitions.

Mounting a File System

In Red Hat Linux, you use a physical disk partition by associating it with a specific part of the file system. This arrangement is a hierarchical directory — a directory tree. If you have more than one disk partition (you may have other disks with Linux partitions), you can use all of them in Red Hat Linux under a single directory tree. All you have to do is decide which part of the Linux directory tree should be located on each partition — a process known in Linux as mounting a file system on a device. (The disk partition is a device.)

N OT E

The term mount point refers to the directory you associate with a disk partition or any other device.

Suppose you have two disks on your PC and you have created Linux partitions on both disks. Figure 3-8 illustrates how you can mount partitions on different parts of the Linux directory tree (the file system).

Disk 1 Disk 2

/(root)

Linux File System

/bin /boot /dev /etc ...

/sbin /usr

/usr/X11R6 /usr/doc /usr/local ...

/usr/share ...

/usr/src ...

Figure 3-8 Mounting the Red Hat Linux file system on two disk partitions.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 47

Standard Installation 47

Understanding the Swap Partition

Most advanced operating systems support the concept of virtual memory, in which part of your system’s hard disk functions as an extension of the physical memory (RAM). When the operating system runs out of physical memory, it can move (or swap out) the contents of currently unneeded parts of RAM to make room for a program that needs more memory. When the operating system needs to access anything in the swapped-out data, it has to find something else to swap out and then it swaps in the required data from disk. This process of swapping data back and forth between the RAM and the disk is also known as paging.

Because the disk is much slower than RAM, the system’s performance is slower when the operating system has to perform a lot of paging. However, virtual memory enables you to run programs that you otherwise couldn’t run by using the swap partition.

Red Hat Enterprise Linux supports virtual memory and can make use of a swap partition. When you create the Linux partitions, you also create a swap partition. With the Disk Druid utility program, described in the next section, creating a swap partition is easy. Simply mark a partition type as a swap device, choose the size, and let Disk Druid perform the necessary tasks.

Preparing Disk Partitions

After you select Disk Druid to manually partition your disks, the Disk Setup screen, shown in Figure 3-7, reappears.

Before beginning to partition the drive, consider exactly how you want to create the partitions. You must create one partition on the drive to be used as the root (/) partition. This works well in most cases, but it can cause some problems. If the root partition should become full, the system could crash. Many times the partition fills up because of system logging, email, and print queue files. These files are all written to the /var directory by default, so it may be a good idea to create a separate partition for /var to prevent the root partition from filling up with system logs, email, and print files. You might also want to create a separate partition for your user’s home directories (/home) if you have a large number of users.

You also need to create a swap partition. A swap partition is used for virtual memory to hold data that is too large to fit into system RAM. Your swap partition should be at least 32 MB or two times your system’s RAM, whichever is larger.

Disk Druid gathers information about the hard drives on your system and displays a list of disk drives in the lower part of the screen and the current partition information for one of the drives in the Partitions area in the upper part.

For each partition, Disk Druid shows seven fields:

08_599496 ch03.qxd 8/30/05 6:20 PM Page 48

48 Chapter 3

■■

■■

■■

Device refers to the partition’s device name. For example, hda1 is the first partition on the first IDE drive.

Mount Point/RAID/Volume indicates the directory where the partition will be mounted. For example, if you have only one partition for the entire Linux file system, the mount point is the root directory (/). For the swap partition, this field shows <Swap>. If this field appears as

<not set>, you have to specify a mount point. To do so, select the partition and click the Edit button.

The Type field shows the partition’s file type, such as ext3, swap, or DOS.

■■

The Format field shows a check mark if the partition will be formatted and is blank if the partition will not be formatted.

■■

■■

The Size field shows the amount of disk space the partition is using.

Start and End are the beginning and ending cylinders on the hard drive used by the partition.

If there are no partitions defined, the table in the Partitions list is empty. You have to add new partitions by clicking the Add button.

You perform specific disk setup tasks in Disk Druid through the six buttons that run across the middle of the screen. The buttons perform the following actions:

■■

■■

New enables you to create a new partition, assuming that there is enough free disk space available. When you click this button, another dialog box appears in which you can fill in information necessary to create a partition.

Edit enables you to alter the attributes of the partition currently highlighted in the Partitions list. You make changes to the current attribute in another dialog box that appears when you click the Edit button.

■■

■■

Delete removes the partition currently highlighted in the Partitions list.

Reset causes Disk Druid to ignore any changes that you may have made.

■■

RAID sets up a redundant array of independent disks (RAID) device — a technique that combines multiple disks to improve reliability and data transfer rates. There are several types of RAID configurations. This button is active only if your system has the hardware necessary to support a RAID device.

N OT E

The reference to RAID in this section is for a software RAID configuration.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 49

Standard Installation 49

■■

LVM sets up a logical volume. Before you can use this feature, you need to set up your partition’s type as a physical volume. Then choosing this option lets you create a logical volume to make managing the physical disks easier.

Exactly what you do in Disk Druid depends on the hard drives in your PC and the partitions they already have. For this discussion, we assume that you are using the entire hard drive space for the Red Hat installation.

Setting Up the Partitions

To prepare a new hard drive to install Red Hat Linux, you have to perform the following steps in Disk Druid.

Create at least two partitions, one for the Linux file system and a swap partition. To do this, click the New button on the Disk Druid screen. You will see a dialog box (see Figure 3-9) containing the following fields, which you need to fill in:

Figure 3-9 The Add Partition dialog box where you set the attributes for the new partition.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 50

50 Chapter 3

■■

Mount Point shows the place in the file system where the partition will be mounted. You can enter a mount point or click the down arrow to open the drop-down menu and choose a mount point from the list.

■■

File System Type is the type of file system you want the partition to be.

Click the down arrow to open the drop-down menu and choose the file system type. The most common choices here are ext2, ext3, and swap.

If you decide to use logical volumes you can choose Physical Volume

(LVM) here. Then you will need to further configure the logical volumes by clicking the LVM button.

■■

■■

■■

■■

Allowable Drives shows the installed hard drives. A check mark in the box means that the drive is available for creating partitions. Click to highlight the drive you want to use for the partitions.

Size (MB) is the field where you can set the size of the partition. The default size is 100 MB, but you can set the size to whatever you desire.

Additional Size Options lets you set other size restrictions by clicking the radio button. Fixed Size is the default. If you choose Fill All Space

Up To, you need to enter a number in the field provided. Fill to Maximum Allowable Size will use all remaining space on the drive.

Force to Be a Primary Partition lets you set the drive as either a primary or logical partition. Primary partitions are the first four partitions on the hard drive.

■■

Check for Bad Blocks, if checked, will cause the installation program to do a physical scan of the drive to find and mark any blocks that may be bad. This prevents the system from attempting to write data to such areas of the disk. Keep in mind that checking this box will slow down the installation process, depending on the size of your hard drive.

After you have filled in the field with your choices, click OK to return to the

Disk Setup screen.

Create another new partition and set it as a Linux swap space. To do this, click the New button in the Disk Setup screen (refer to Figure 3-7). In the dialog box shown in Figure 3-9, enter the size of the partition. Click the list of partition types and select Linux Swap as the type. When you do so, <Swap

Partition> appears in the Mount Point field. Enter the size of the swap partition and any other parameters you desire. Next, click OK to define the new partition and return to the Disk Druid screen.

After you finish specifying the partitions in Disk Druid, the Disk Setup screen will display the details: partition number, file type, size, and starting and ending cylinders. A check mark in the Format column indicates that the partition will be formatted. If you wish to change the mount point of the partition, highlight it and click the Edit button. If you want to make any other

08_599496 ch03.qxd 8/30/05 6:20 PM Page 51

Standard Installation 51

changes to the partition, you will have to delete it and create a new one. If you are satisfied with your selections, click Next.

N OT E

If you have multiple disk partitions mounted on different directories of the Linux file system and you are upgrading an existing installation, you do not have to format any partitions in which you want to preserve existing data. For example, if you have all user directories on a separate disk partition mounted

on the /home directory, you do not have to format that partition.

You have now completed the disk preparation phase of the installation. The installation program performs the actual formatting of the partitions after it asks for some more configuration information, including the packages you want to install.

Configuring the Installation

After you prepare the disk partitions with Disk Druid and specify which partitions to format, the installation program moves on to some configuration steps. The typical configuration steps are as follows:

■■

Install GRUB

■■

Configure the network

■■

Set the time zone

■■

Set the root password and add user accounts

■■

Configure password authentication

The following sections guide you through each of these configuration steps.

Installing the Boot Loader

The Red Hat installation program displays the Boot Loader Configuration screen (see Figure 3-10), which asks you where you want to install the boot loader. A boot loader is a program that resides on your disk and starts Red Hat

Enterprise Linux or Fedora Core from the hard disk. Red Hat provides GRUB

(Grand Unified Bootloader) as the default boot loader.

The GRUB boot loader is selected as the default choice on this screen. Clicking the Change Boot Loader button lets you choose not to install any boot loader.

C A U T I O N

If you choose not to install the boot loader, you will need to create a boot disk. Otherwise you can’t start Red Hat Linux.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 52

52 Chapter 3

Figure 3-10 The Boot Loader Configuration screen enables you to specify which operating systems to boot.

In the center of the Boot Loader screen is a box that shows any operating systems, if there are any, that were detected on your system. The Red Hat

Linux system will be shown as the default system. If you want to boot another system as the default, click the box in front of the other operating system’s name. There are three options available:

■■

■■

■■

Add

— Use this if an operating system was not detected and you wish to add it manually.

Edit

— Click this option if you want to change the name of the operating system.

Delete

— Use this option to remove an operating system from the list that you’ve highlighted.

The next item on this screen gives you the option to use a boot loader password. Using a boot loader password prevents someone from entering kernel commands, which could affect system security or operation. If your servers are not accessible to anyone except you or other trusted administrators, you may not need a boot loader password, but if you want good security for your system, using a boot loader password is a good idea. To enable this feature,

08_599496 ch03.qxd 8/30/05 6:20 PM Page 53

Standard Installation 53

click the Use a Boot Loader Password check box, click the Change Password button, and enter the password.

The Configure advanced bootloader options on this page give you the opportunity of choosing the location of the boot loader and passing additional parameters to the kernel. If you want to do either of these, click the option and then click Next. The Advanced Boot Loader Configuration screen, shown in

Figure 3-11, will appear.

The choices for the boot loader location are as follows:

■■

Master Boot Record (MBR), which is located in the first sector of your

PC’s hard disk

■■

First sector of the boot partition where you loaded Red Hat Linux

You should install the boot loader in the MBR unless you are using another operating system loader such as System Commander or OS/2 Boot Manager.

You can also change the drive order by clicking the Change Drive Order button.

This is only necessary if you want your drives to appear in a different order or if they are not listed in the correct order. As shown on the screen following the option Force LBA32, this option is usually not required and is necessary only if you put the boot loader beyond the first 1024 cylinders on your hard drive.

Figure 3-11 The Advanced Boot Loader Configuration screen specifies where you can change the location of the boot loader and enter kernel parameters.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 54

54 Chapter 3

The screen includes a General Kernel Parameters text field that enables you to enter any special options that Red Hat Linux may need as it boots. Your need for special options depends on what hardware you have.

The remainder of the Boot Loader Configuration screen gives you the option to select the disk partition from which you want to boot the PC. A table then lists the Linux partition and any other partitions that may contain another operating system. If your system has a Linux partition and a DOS partition (that actually has Windows 95/98 installed on it), the table shows both of these entries. Each entry in that table is an operating system that the boot loader can boot.

After you install the boot loader, whenever your PC boots from the hard disk, the boot loader runs and displays a screen showing the operating systems that you can boot. The default selection will be highlighted and will boot automatically after a few seconds. You may move the highlight bar to the name of another operating system to boot. (The Boot label column in the table in the center section of Figure 3-10 shows the names you may enter at the boot loader prompt.)

When booting the PC, if you enter nothing at the boot loader screen, the boot loader waits for a few seconds and boots the default operating system. The default operating system is the one with a check mark in the Default column in Figure 3-10. In this case, Red Hat Linux is the default operating system.

All of the instructions in this section are for your information if you choose to change any of the default settings. You can essentially accept the default selections on this screen and click the Next button to proceed to the next configuration step.

Configuring the Network

If the Linux kernel detects a network card, the Red Hat installation program displays the Network Configuration screen (see Figure 3-12), which enables you to configure the LAN parameters for your Linux system.

This step is not for configuring dial-up networking. You need to perform this step if your Linux system is connected to a TCP/IP LAN through an

Ethernet card.

T I P

If the Red Hat installation program does not detect your network card and you have a network card installed on the PC, you should restart the installation and type expert at the boot prompt. Then you can manually select your network card.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 55

Standard Installation 55

Figure 3-12 The Network Configuration screen enables you to configure the local area network.

The Network Configuration screen (see Figure 3-12) displays a list of the network card(s) installed on your system and detected by the Linux kernel.

The network cards are labeled eth0, eth1, and so on. If your system has only one Ethernet card, you see only eth0. Figure 3-12 shows that only one network card has been detected. The default selections for the network card are

Active on Boot and Configure Using DHCP. If you want to enter an IP address manually for your network card or disable the card on boot, click the Edit button to open the Edit Interface dialog box.

To disable DHCP remove the check mark from the box and enter an IP address and net mask into the appropriate boxes. To enable DHCP, click the option to place the check mark there.

To disable the card on boot, remove the check mark from the box. To enable the card on boot, click the option to place the check mark there. Normally, you would want your primary Ethernet interface to be configured on system boot.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 56

56 Chapter 3

The Hostname section of the Network Configuration screen shown in Figure

3-12 lets you choose how your system hostname will be set. The choices are:

■■

■■

Automatically via DHCP

— This is the default setting. Your PC will obtain its IP address and other network information from a DHCP server.

Manually

— If you choose this option, you must provide a hostname.

Select DHCP only if a DHCP server is running on your local area network. If you choose DHCP, your network configuration is set automatically and you can skip the rest of this section. You should leave the Activate on Boot button selected so that the network is configured whenever you boot the system.

If you have disabled DHCP, you will need to enter the IP address and net mask manually for the network card by editing the card. In addition, you have to enter certain parameters for the TCP/IP configuration in the text input fields for hostname and the “Miscellaneous Settings” section shown in Figure 3-12.

The Network Configuration screen asks for the following key parameters:

■■

■■

■■

The hostname of your Linux system (for a private LAN, you can assign your own hostname without worrying about conflicting with any other existing systems on the Internet)

IP address of the gateway (the system through which you might go to any outside network)

IP address of the primary name server

■■

■■

IP address of a secondary name server (if available)

IP address of a ternary name server (if available)

C R O S S - R E F E R E N C E

If you have a private LAN (one that is not directly connected to the Internet), you may use an IP address from a range designated for private use. Common IP addresses for private LANs are the addresses in the range 192.168.1.1 through 192.168.1.254. Chapter 11 provides more in-depth information about TCP/IP networking and IP addresses.

After you enter the requested parameters, click Next to proceed to the next configuration step.

Configuring the Firewall

In this part of the installation process, you can choose the firewall settings for your system security. Look at Figure 3-13 as you go through this section’s configuration steps.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 57

Standard Installation 57

Figure 3-13 The Firewall Configuration screen lets you choose your security level.

C R O S S - R E F E R E N C E

See Chapter 34 for more information about configuring a firewall.

The first choice that you make from this dialog box is whether you want to enable the firewall or to choose no firewall. By default, the installation program selects to enable the firewall for you. If you choose to enable the firewall, only connections that are in response to outbound requests are accepted. You can also select individual services that are allowed through the firewall. You can allow the following services:

■■

Remote Login (SSH)

— If you allow remote access to your server through the SSH protocol, you should enable this option.

■■

Web Server (HTTP, HTTPS)

— If you plan to run a Web server, you should choose this option. You do not need to choose this option to use a browser to view Web sites.

■■

File Transfer (FTP)

— If you plan to run an FTP server, you should enable this option. You do not need to choose this option to retrieve files from FTP sites.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 58

58 Chapter 3

■■

Mail Server (SMTP)

— If you are going to run an email server, you should enable this option. You do not need to enable this option to retrieve mail from an ISP.

If you choose the No Firewall option, all connections are allowed and no security checking is done on your system. Select No Firewall only if you have absolute faith in the security of your network.

T I P

Choosing to enable the firewall is always safest, especially if you will be connecting directly to the Internet.

The final configuration step on the Firewall Configuration dialog box concerns Security-Enhanced Linux (SELinux). SELinux was developed by the

National Security Agency (NSA) to provide enhanced security based on access control specified by a security policy. You can choose one of three states for

SELinux:

■■

■■

Disable

— If you select this option, SELinux is not enabled on your system and there is no enforcement of a security policy.

Warn

— Choosing this option puts a security policy in place, but the policy is not enforced. Only warnings about possible security violations are noted. If you plan to use SELinux, this option provides a good basis for determining how the security policy would affect the operation of your system.

■■

Active

— This state applies full enforcement of the SELinux security policy. You should choose this option only if you are sure that the policy will not affect your system operation.

C R O S S - R E F E R E N C E

See Chapter 33 for more information about SELinux.

T I P

You can read more about SELinux by visiting the NSA Web site at

www.nsa.gov/selinux

.

After you make your configuration choices, click Next to continue.

Choosing Additional Languages

The Additional Language Support screen, shown in Figure 3-14 is where you select the default language to be used on your system.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 59

Standard Installation 59

Figure 3-14 On the Additional Language Support screen you set the default language for your system as well as additional languages you may use.

The language you chose to use for system installation earlier in the installation process will be shown as the default language. If you desire to use other languages as well, you can select them from the list. Select as many other languages as you desire. Note that installing additional languages consumes storage space on your disk, so install only the languages you plan to use. After you make your selections, click Next to continue.

Setting the Time Zone

After completing the default and additional language selection, you have to select the time zone — the difference between your local time and Greenwich

Mean Time (GMT) or UTC (the current time in Greenwich, England), which was selected by the International Telecommunication Union (ITU) as a standard abbreviation for Coordinated Universal Time. If you had systems in many different time zones, you might want to choose UTC for all your locations to keep your time synchronized on all your systems. The installation program shows you the Time Zone Selection screen (see Figure 3-15) from which you can select the time zone, either in terms of a geographic location or as an offset from UTC.

Figure 3-16 shows the selection of a time zone.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 60

60 Chapter 3

Figure 3-15 Select your time zone using the Time Zone Selection screen.

Notice that there are two tabs on the Time Zone Selection screen: Location and UTC Offset. Initially, the screen shows the Location tab, which enables you to pick a time zone by simply clicking your geographic location. As you move the mouse over the map, the currently selected location’s name appears in a text field. If you want, you can also select your location from a long list of countries and regions. If you live on the east coast of the United States, for example, select USA/Eastern. Of course, the easiest way is to simply click the eastern United States on the map.

If the world view of the map is too large for you to select your location, click the View button on top of the map. A drop-down list of views appears with several choices. Click the appropriate view for your location.

The other way to set a time zone is to specify the time difference between your local time and UTC. Click the UTC Offset tab to select the time zone this way.

For example, if you live in the eastern part of the United States, select UTC-

05:00 as the time zone. The -05:00 indicates that the eastern part of the U.S. is five hours behind UTC time. This tab also lets you activate Daylight Savings

Time. After you select your time zone, click the Next button to proceed to the next configuration step.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 61

Standard Installation 61

Setting the Root Password

After selecting the time zone, the installation program displays the Set Root

Password screen (see Figure 3-16) in which you set the root password.

The root user is the superuser in Linux. Because the superuser can do anything in the system, you should assign a password that only you can remember, and that others cannot guess easily. Typically, make the password at least eight characters long, include a mix of letters and numbers, and (for good measure) throw in some special characters such as + or *. Remember that the password is case-sensitive.

Type the password on the first line, and then reenter the password on the next line. Each character in the password appears as an asterisk (*) on the screen for security reasons. Both entries must match before the installation program accepts the password. The installation program displays a message when it accepts the root password.

N OT E

You must enter the root password before you can proceed with the rest of the installation. After you do so, click Next to continue with the installation.

Figure 3-16 Setting the root password.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 62

62 Chapter 3

Selecting the Package Groups to Install

After you complete the key configuration steps, the installation program displays a screen from which you can select the Red Hat Linux package groups that you want to install. After you select the package groups and click Next, take a coffee break while the Red Hat installation program formats the disk partitions and copies all selected files to those partitions.

N OT E

If you selected custom installation as your install type, you will see the screen shown in Figure 3-18. If you chose any other installation type, you will see a screen listing the most commonly installed packages for the installation type you chose. You can accept the default on that page or you can select

Customize software packages to be installed option to pick your own packages, which will then show you the screen in Figure 3-17.

C R O S S - R E F E R E N C E

Red Hat uses special files called packages to bundle files that make up specific software. For example, all configuration files, documentation, and binary files for the Perl programming language come in a

Red Hat package. You use a special program called Red Hat Package Manager

(RPM)

to install, uninstall, and get information about packages. Chapter 30 shows you how to use RPM. For now, just remember that a package group is made up of several Red Hat packages.

Figure 3-17 shows the Package Group Selection screen with the list of package groups that you can elect to install. An icon, a descriptive label, and a radio button for enabling or disabling identify each package group.

Some of the components are already selected, as indicated by the checked boxes. This is the minimal set of packages that Red Hat recommends for installation for the class of installation (Personal Desktop, Workstation, Server, or

Custom) you have chosen. You can, however, install any or all of the components. Scroll up and down the list and click the mouse on an entry to select or deselect that package group.

T I P

In an actual Red Hat Linux installation, you install exactly those package groups that you need. Each package group requires specific packages to run.

The Red Hat installation program automatically checks for any package dependencies and shows you a list of packages that are required but that you have not selected. In this case, you should install the required packages. Install only those packages that you think you will need immediately after starting the system. Installing too many packages could expose your system to security risks. You can always add packages later.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 63

Standard Installation 63

Figure 3-17 GUI screen from which you select the components to install.

Because each package group is a collection of many different Red Hat packages, the installation program also gives you the option of selecting individual packages. If you click the Customize software packages option, which appears on the Personal Desktop, Workstation, and Server package screens and then click Next, the installation program takes you to other screens where you can select individual packages. If you are installing Red Hat Enterprise Linux for the first time, you really do not need to go down to this level of detail to install specific packages.

Notice to the right of each group name there are two numbers separated by a slash. For instance, next to the X Window System is 37/41. This means that

37 of the 41 packages in this group have been selected for installation. To the right of the numbers is a link labeled Details. Clicking this link opens a new screen that lists the packages that are in the selected group. You can select or deselect packages as desired.

After you select the groups you want, click Next to continue with the rest of the installation. The installation program now presents the About to Install screen, as shown in Figure 3-18. This screen tells you which disks are required for the installation.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 64

64 Chapter 3

Figure 3-18 The About to Install screen gives you one last chance to cancel the installation process.

If you are absolutely sure that everything is correct and you are ready to proceed, click Continue to begin the installation. The time required for installation depends on the number of packages you chose to install. This would be a good time to take a break, but remember to check the installation’s progress occasionally as you will need to change CDs. A screen showing the installation progress is displayed to show you how the installation is proceeding.

C R O S S - R E F E R E N C E

You can always install additional packages later with the RPM utility program, described in Chapter 30.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 65

Standard Installation 65

Running Firstboot

After the installation process completes, you are prompted to remove all disks and to reboot your system. A program called Firstboot runs the first time the system boots after the installation, as shown in Figure 3-19.

Figure 3-19 The Firstboot program runs to let you do additional system configuration.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 66

66 Chapter 3

Shown on the left side of the Firstboot Welcome screen are the steps you must complete to boot into your newly installed system. Proceed as follows:

1. Click Next to continue to the License Agreement screen, as shown in

Figure 3-20.

Figure 3-20 The License Agreement screen.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 67

Standard Installation 67

2. Click the radio button in front of Yes to accept the License Agreement.

3. Click Next to continue to the Date and Time screen, as shown in

Figure 3-21.

Figure 3-21 You can verify or change the system time on this screen.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 68

68 Chapter 3

4. Click Next to continue to the Display screen, as shown in Figure 3-22.

Figure 3-22 The Display screen is where you can configure your screen resolution and color depth.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 69

Standard Installation 69

5. Click the button next to the parameter you wish to change and select the new parameter from the drop-down list. When you are satisfied with the settings, click Next to continue to the System User screen, as shown in Figure 3-23.

On this screen you need to create a system user. The system user is a regular, nonroot user with ordinary, not superuser access rights. After you have filled in the appropriate information into the text boxes, click

Next to continue to the Additional CDs screen, as shown in Figure 3-24.

6. If you have any additional CDs or documentation disks from Red Hat you can install them by clicking Install and selecting what you want to install. Be sure to put the appropriate CD into your CD drive. When you are finished, click Next.

7. When the Finish Setup screen appears click Finish, and your newly installed system will boot to the GNOME desktop.

Figure 3-23 You add a system user on the System User screen.

08_599496 ch03.qxd 8/30/05 6:20 PM Page 70

70 Chapter 3

Figure 3-24 You can install additional programs from Red Hat provided CDs here.

Summary

In this chapter you learned how to install Red Hat Enterprise Linux and

Fedora Core. You began by examining the hardware on your system and making a list of the components. You checked for hardware compatibility by referring to the Red Hat Web site. You learned how to partition your hard drive, and you chose the type of system you wanted to install. You chose the packages you wanted to install, and you began the process of installing them on your system. Finally, you rebooted your system and ran the Firstboot program to finish the installation.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 71

C H A P T E R

4

Kickstart

Installation

IN THIS CHAPTER

■■

■■

Using the Kickstart Configurator

Starting the Kickstart Installation

As a system administrator, one of your jobs is installing and configuring Red

Hat on other computers. This could be time-consuming if you have many servers and clients to administer. To make your job easier, a program is available that automates the Red Hat installation process. This program is called Kickstart. With Kickstart you can create and store configuration files for your server or client installations and then use these files to perform your installations and upgrades. Installations and upgrades can be done from a local CD-ROM or using NFS, FTP, Hypertext Transfer Protocol (HTTP), or a hard drive. If you are installing across the network, you need to have a Dynamic Host Configuration

Protocol (DHCP) server for each network segment.

Using the Kickstart Configurator

Fedora Core has a graphical tool, called Kickstart Configurator, that you can use to configure the Kickstart configuration file. The Kickstart configuration file is used to give the installation program the answers to the configuration steps that usually require user intervention. So by using Kickstart, you can automate the installation process. But before you can use the Kickstart Configurator, you need to install it, since it isn’t installed by default.

71

09_599496 ch04.qxd 8/30/05 6:30 PM Page 72

72 Chapter 4

Installing the Kickstart Configurator

To install the Kickstart Configurator program in GNOME follow these steps.

1. From the desktop, choose Desktop ➪ System Settings ➪ Add/Remove

Applications to open the Package Management tool dialog box, as shown in Figure 4-1.

2. Scroll down to the System section, and click Details to the right of

Administration Tools to open the Administration Tools Package

Details dialog box, as shown in Figure 4-2.

3. Click the check box in front of system-config-kickstart.

4. Click Close and then Update on the Package Management tool.

5. When the Completed System Preparation screen appears, click Continue. When prompted, put installation disk one into the CD drive and

Click OK.

6. When the Update Complete dialog box appears click OK, then click

Quit to close the Package Management tool.

Figure 4-1 The Package Management tool is used to install packages from the installation CDs.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 73

Kickstart Installation 73

Figure 4-2 The Administration Tools Package details dialog box.

You are now ready to start the Kickstart Configurator. Follow these steps:

1. Choose Applications ➪ System Tools ➪ Kickstart. The Kickstart Configurator window shown in Figure 4-3 appears.

When the Kickstart Configurator window opens, the Basic Configuration dialog box is shown on the right side. You will notice that many of the text fields are already filled in. This is because the program has loaded the anaconda-ks.cfg file that was created during your system installation.

N OT E

The anaconda-ks.cfg file you see will be based on the type of

installation you did. You should keep in mind that there may be significant differences between a server configuration file and a workstation or desktop configuration file, although having a file to refer to is always a good place to start.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 74

74 Chapter 4

Figure 4-3 The Kickstart Configurator program opens to the

Basic Configuration dialog box.

On the left side of the window is a list showing the other configuration dialog boxes. Clicking an item in the list will open its respective dialog box on the right side of the Kickstart Configurator window. Beginning with the basic configuration, the fields are:

■■

Language

— Click the down arrow on the right of the field, and click the language you want to use for the installation.

■■

Keyboard

— Click the down arrow on the right of the field, and click the language appropriate for your keyboard.

■■

Mouse

— Click the down arrow on the right of the field, and click the appropriate mouse for your system. If you have a two-button mouse and want to emulate a three-button mouse, check the box to emulate three buttons.

■■

Time zone

— Click the down arrow on the right of the field, and click the appropriate time zone for your location. Click the Use UTC

Coordinated Universal Time clock check box if you want your time to be set to UTC (Coordinated Universal Time). UTC was previously known as GMT, or Greenwich Mean Time.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 75

Kickstart Installation 75

■■

Root password

— Enter the password for the root user. Notice that it will be encrypted by default unless you remove the check from the box.

■■

Language support

— Choose additional languages you want to install on your system by checking the box in front of each language’s name.

■■

Target architecture

— This field lets you choose the type of system on which you are installing. For example, choose x86 for a typical

Intel Pentium system.

■■

Reboot system after installation

— By default, the system reboots unless you remove the check from the box.

■■

Perform installation in text mode

— By default, the installation is performed in graphical mode unless you remove the check from the box.

■■

Perform installation in interactive mode

— Place a check in this box if you want to use interactive mode during the installation. This method still uses the Kickstart configuration file but lets you see the options selected for installation one screen at a time. You need to click Next to continue at each screen.

2. After you have verified or entered the appropriate information into the

Basic Configuration dialog box, click Installation Method to open the

Installation Method dialog box shown in Figure 4-4.

In the Installation Method dialog box you select whether you want to do a new installation or an upgrade of an existing system.

On the Installation Methods screen, you can pick the type of installation you will be performing. You can choose to do a new installation or an upgrade by clicking the radio button in front of your choice. If you choose to upgrade an existing system you won’t have to define partitions or packages for the installation program to use because the existing partitions and packages will be used.

N OT E

You will require a separate disk for each type of installation. You cannot use a disk meant for a new installation to do an upgrade, or use a disk meant to upgrade a system to do a new installation.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 76

76 Chapter 4

Figure 4-4 The Installation Method dialog box is where you choose how to perform the installation.

You can also choose the type of media you will be using for the installation. The default choice is CD-ROM. You also have the following choices:

■■

NFS

— If you choose this method, two additional fields will appear where you need to enter the name of the NFS server and the directory to use.

■■

FTP

— If you choose this method, four additional fields will appear.

You need to enter the name of the FTP server and the directory to use in two of the fields. You are also given the opportunity to show an FTP username and password by clicking the check box and entering the appropriate information.

■■

HTTP

— If you choose this method, two additional fields will appear where you need to enter the name of the HTTP server and the directory to use.

■■

Hard Drive

— If you choose this method, two additional fields will appear where you need to enter the partition of the hard drive and the directory to use.

3. When you are satisfied with your choices, click Boot Loader Options to open the Boot Loader dialog box shown in Figure 4-5.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 77

Kickstart Installation 77

Figure 4-5 The Kickstart Configurator program window, showing the

Boot Loader Options screen.

Boot Loader Options Screen

On this screen, you have several choices related to the system boot loader. You can choose to install a boot loader, not to install the boot loader, or to upgrade an existing boot loader. Just click the button in front of your choice. You can also set a password for the GRUB boot loader as well as encrypt it by clicking the appropriate check box.

You can choose the location of the boot loader by clicking the radio button in front of either Master Boot Record (MBR) or first sector of boot partition.

The final field of this screen allows you to pass additional parameters to the kernel if necessary.

After making your choices, click Partition Information to open the Partition

Information dialog box shown in Figure 4-6.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 78

78 Chapter 4

Figure 4-6 The Kickstart Configurator program window, showing the Partition

Information dialog box.

Partition Information Screen

In this dialog box, you can create your disk partitions and set the mount points for your directories. By default, the master boot record (MBR) is cleared during installation. If you do not want to clear the MBR, click the Do not clear

MBR radio button.

Also by default, all existing partitions are removed during the installation. If you do not want to do this, click the radio button in front of your choice. You can choose to remove only existing Linux partitions, or you can keep the existing partitions.

If you are installing on a new hard drive, you will want to keep the default setting of Initialize the disk label. If you are installing on a previously used drive and want to keep the existing drive label, check the Do not initialize the disk label radio box.

The partition window in this dialog box is currently empty, since you haven’t created any partitions yet. To create a partition, click the Add button at the bottom of the screen. You see a Partition Options dialog box, as shown in

Figure 4-7.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 79

Kickstart Installation 79

Figure 4-7 The Partition Options dialog box is where you add and configure partitions.

N OT E

If you aren’t sure about setting up the partitions on your system, you

can use the setup shown in the anaconda-ks.cfg file as a guide. These

partitions are the defaults selected during the Fedora Core installation and generally work well.

The Partition Options dialog box contains the following fields, which you need to fill in:

■■

Mount Point shows the place in the file system where the partition will be mounted. You can type a mount point or click the down arrow to open the drop-down menu and choose a mount point from the list.

■■

File System Type is the type of file system you want the partition to be.

Click the down arrow to open the drop-down menu, and choose the file system type. The most common choices here are ext2, ext3, and swap.

■■

Allowable Drives shows the installed hard drives. A check mark in the box means that the drive is available for creating partitions. Click to highlight the drive you want to use for the partitions.

■■

Size (MB) is the field where you can set the size of the partition. The default size is 100 MB, but you can set the size to whatever you desire.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 80

80 Chapter 4

■■

■■

Additional size options let you set other size restrictions by clicking the radio button in front of the option. Fixed size is the default. If you choose Grow to maximum of, you need to enter a number in the field to the right of the choice. Fill all unused space on disk will use all remaining space on the drive. Use recommended swap size is grayed out and not selectable unless the file system type selected is Swap.

Force to be a primary partition lets you set the drive as either a primary or logical partition. Primary partitions are the first four partitions on the hard drive.

■■

■■

■■

Make partition on specific drive lets you choose the hard drive on which to create the partition. Just enter the drive identifier; for example, hda would be the first IDE drive.

Use an existing partition lets you specify using an already existing partition.

Format partition is checked as the default. If you do not want to format the partition, remove the check mark from the box.

1. After you have filled in the fields, click OK to return to the partition information screen. You will see the partition information you have chosen displayed in the partition window.

2. You can also create software RAID partitions if you desire. To create a software RAID partition, click the RAID button at the bottom of the partition information screen. You will see the RAID options dialog box, as shown in Figure 4-8.

Figure 4-8 The RAID Options dialog box gives you information about creating RAID partitions.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 81

Kickstart Installation 81

As shown on the RAID Options dialog box, you need to have two software Raid partitions to be able to create a RAID device.

3. The only option you have on this dialog box is to accept the option to create a software RAID partition; click Next to continue. A Partition

Options dialog box like the one shown in Figure 4-7 appears with software RAID already selected as the file system type.

4. Enter the remaining options as you do when creating a partition earlier.

Click OK, and the first RAID partition is shown on the partition window.

Click RAID again, and create another RAID partition.

5. After you have created the second RAID partition and have returned to the partition information window, click RAID again. Now you have the option of creating a RAID device that has already been selected for you.

6. Click OK, and you see the Make RAID Device dialog box shown in

Figure 4-9.

This dialog box contains the following fields:

■■

Mount Point shows the place in the file system where the partition will be mounted. You can type a mount point or click the down arrow to open the drop-down menu and choose a mount point from the list.

■■

File System Type is the type of file system you want the partition to be. Click the down arrow to open the drop-down menu, and choose the file system type. The most common choices here are ext2, ext3, swap, and vfat.

■■

RAID Device shows the identifier for the RAID device. By default, md0 is selected. To change this selection, click the down arrow to the right of the field and select a different identifier.

Figure 4-9 The Make RAID Device dialog box gives you choices about creating RAID devices.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 82

82 Chapter 4

■■

RAID Level is the field where you can choose the RAID level you want to use. The choices here are levels 0, 1, and 5. See Chapter 6 for an explanation of RAID levels.

■■

RAID Members lets you select the partitions that will be a part of the

RAID device. In Figure 4-9, the two partitions created previously are shown. Click the box in front of the partition to select it.

■■

Number of spares lets you specify another partition to use as a spare if you are using RAID level 1 or 5. You need to create an additional software RAID partition for each spare you select.

■■

Format RAID device is checked as the default. If you do not want to format the device, remove the check mark from the box.

7. After you have made your selections, click OK to create the RAID device. You should now see the device listed on the Partition Information window.

8. Click Network Configuration from the list on the left to open the Network Configuration dialog, as shown in Figure 4-10.

Figure 4-10 The Network Configuration dialog box is where you configure your network interface card (NIC).

09_599496 ch04.qxd 8/30/05 6:30 PM Page 83

Kickstart Installation 83

Network Configuration

On this screen, you can configure a network card. Click Add Network Device, and you see the Network Device Information dialog box shown in Figure 4-11.

In this dialog box, the first network interface card is shown as eth0, and the network type is shown as DHCP. DHCP, or Dynamic Host Configuration Protocol, is used to provide an IP address, netmask, gateway address, and a DNS name server address for your system. If you are using DHCP on your network, you can accept the defaults for this device. If you want to use a static IP address, click the down arrow in the network type field and choose static IP.

You need to fill in the appropriate network information in the fields at the bottom of the dialog box. Another choice shown when you click the down arrow for Network Type is BOOTP. BOOTP is a protocol that lets you boot your system across the network. For example, if you are planning to set up a terminal server with attached clients, like the Linux Terminal Server Project, you would want to configure BOOTP.

1. After you create or modify your NIC settings, click OK to return to the

Network Configuration window, and your device is shown in the list. If you want to configure additional network interfaces, click Add Network Device and make your choices. To make changes to an existing device, click Edit and make your changes as described above.

2. Click Authentication from the list on the left to open the Authentication dialog box, as shown in Figure 4-12.

Figure 4-11 The Network Device Information dialog box is where you configure your network interface card.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 84

84 Chapter 4

Figure 4-12 The Kickstart Configurator program window, showing the

Authentication screen.

Authentication

By default, Use shadow passwords and MD5 are selected. Both of these options provide increased system security and should be used unless you have good reason not to use them. If you want to use any of the other services available from this screen, click the tab for the service you want to use. The following services are available.

■■

NIS

— This acronym stands for Network Information Service (or system depending on whom you ask) and was developed by Sun Microsystems to provide a distributed database of system resources and authorized users. If you want to use NIS, click the enable NIS check box and enter the name of your NIS domain and sever information. See Chapter 13 for more details about NIS.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 85

Kickstart Installation 85

■■

LDAP

— LDAP is an acronym for Lightweight Directory Access Protocol and is used to provide single sign-on services for users. LDAP is based on the X.500 directory standard and uses a systemwide database of resources and authorized users. To use LDAP click the Enable check box and enter your LDAP server and base names. You can learn more about LDAP in Chapter 17.

■■

Kerberos 5

— Kerberos is the mythical three-headed dog that guarded the gates to the underworld. It is also the name chosen by the MITbased group for their network authentication system. To use Kerberos click the enable check box and enter your Kerberos realm, domain controller, and master server names. You can learn more about Kerberos in

Chapter 17.

■■

Hesiod

— Hesiod was a poet from ancient Greece and also the name chosen by the MIT group for their network database that was based on

DNS and used to provide information across the network. To use Hesiod click the Enable check box and enter the domain prefix in the LHS field and the Hesiod domain in the RHS field. For more information about Hesiod read the hesiod.conf man page.

■■

SMB

— SMB is an acronym for Server Message Block, which is the protocol used by Microsoft for its networking implementation. If you want to use Samba, you need to install the Samba package on your system to use

SMB. This option only enables SMB authentication. To enable SMB authentication, click the Enable check box and enter the names of the SMB servers and workgroup. You can learn more about SMB in Chapter 14.

■■

Name Switch Cache

— To use this service, click the Enable nscd check box. NSCD is the daemon that handles requests for password and group lookups and caches this information. Caching provides faster response for future lookups. For more information about NSCD, read the nscd main page.

After you have made your choices, click Firewall Configuration on the left to open the Firewall Configuration dialog box, as shown in Figure 4-13.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 86

86 Chapter 4

Figure 4-13 The Kickstart Configurator program window showing the

Firewall Configuration dialog box.

Firewall Configuration

From this dialog box, you can set the level of security you want on your system. You can make your choices from the following fields.

■■

Security Level

— Either enable or disable the firewall for your system by clicking the down arrow in the Security Level field and choosing one or the other. If the firewall is enabled, it will allow only inbound traffic in response to outbound requests. Choosing Disable firewall allows remote systems to access any services on your system that are running.

Unless your system is already protected by another firewall it is probably a good idea not to disable the firewall.

■■

■■

Trusted devices

— If you configured a NIC earlier, this device is listed in this field. Click the check box for the device to allow any connections to the selected device.

Trusted services

— If you check the check box in front of a listed service, requests for that service are accepted by your system.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 87

Kickstart Installation 87

■■

Other ports

— In this field you can enter specific ports to open to allow incoming traffic. The example shows 1029:tcp, which means that incoming TCP traffic on port 1029 is allowed. You can specify whatever ports you need based on the services you plan to provide. For example, if you were going to run a VNC server you would want to open ports 590x.

After you have made your choices, click Display Configuration on the left to open the Display Configuration dialog box shown in Figure 4-14.

Display Configuration

If you plan to use a graphical interface, you need to configure the X window system and your system display.

1. After the Display Configuration dialog box opens, click the Configure the X Window system check box. After you do this, the three tabs become selectable, and you need to enter the appropriate information for each tabbed screen.

Figure 4-14 The Kickstart Configurator program window, showing the

Display Configuration dialog box.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 88

88 Chapter 4

2. On the General tab you can set the color depth, or number of colors your system will display. The screen resolution is the size of the screen you want displayed. Click the down arrow next to the fields and choose the desired values from the drop-down lists. Also choose the default desktop, either Gnome or KDE. Gnome is selected as the default choice.

If you want the X Window system to start at system boot, click the check box. Choosing this option gives the user a graphical login window instead of a console login terminal. Finally, you can choose whether you want to run the Firstboot program the first time the system boots. Make your choice by clicking the down arrow next to the field and clicking what you want.

N OT E

If you are installing the desktop or workstation versions of Fedora Core or Enterprise Linux, it is probably a good idea to start the X Window system and enable the Firstboot option. This will give your users the opportunity to easily fine-tune their displays.

3. When you have finished configuring the General settings, click the

Video Card tab to open the Video Card dialog box shown in Figure 4-15.

Figure 4-15 The Kickstart Configurator program window showing the Video Card dialog box.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 89

Kickstart Installation 89

The default selection here is to have the installation program probe for the video card installed in the system. This is nearly always a good choice for most video cards, especially cards produced within the last two or three years. You can disable this option by removing the check from the check box. If you disable probing for the video card, you will have to select the appropriate card from the list of cards and set the amount of video memory.

4. When you finish configuring your video card, click the Monitor tab to open the Monitor dialog box shown in Figure 4-16.

Figure 4-16 The Kickstart Configurator program window, showing the Monitor dialog box.

The default selection here is to have the installation program probe for the monitor installed in the system. This is nearly always a good choice for most monitors, especially monitors produced within the last two or three years. You can disable this option by removing the check from the check box. If you disable probing for the monitor, you will have to select the appropriate monitor from the list of cards. Rather than selecting a monitor, you may set the vertical and horizontal sync of your monitor if you know it.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 90

90 Chapter 4

5. When you have finished configuring your monitor, click Package Selection from the list on the left to open the Package Selection dialog box shown in Figure 4-17.

Figure 4-17 The Kickstart Configurator program window, showing the

Package Selection dialog box.

Package Selection

From the Page Selection dialog box, you can select the packages you want to install on your system. Click the box in front of the package name to select it.

By default, the installation automatically resolves package dependencies and installs additional packages if required. You can choose to ignore dependencies by selecting this option, and no additional packages will be installed to resolve dependency problems. There is a possibility that your selected packages may not work with unresolved dependencies, so it is best to let the installation program automatically resolve the dependency.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 91

Kickstart Installation 91

N OT E

If you aren’t sure about which packages to select to install, you can

refer to the acaconda-ks.cfg file to see which packages were selected for

installation. Remember that the packages installed are based on the type of installation you chose when you installed. For example, if you chose a

workstation install, then the anaconda-ks.cfg file would show the packages

installed for that type.

When you have finished selecting your packages, click Pre-Installation

Script from the list on the left to open the Pre-Installation Script dialog box shown in Figure 4-18.

Figure 4-18 The Kickstart Configurator program window, showing the

Pre-Installation Script dialog box.

Pre-Installation Script

If you want to have commands run on your system before the installation starts, you can enter them in the area indicated on the screen. The system parses the Kickstart file and then runs your commands before beginning the

09_599496 ch04.qxd 8/30/05 6:30 PM Page 92

92 Chapter 4

installation. You can have your script interpreted by the scripting language of your choice by selecting the Use an Interpreter option and entering the interpreter to use.

After you have entered your information, if any, click Post-Installation

Script from the list on the left to open the Post-Installation Script dialog box shown in Figure 4-19.

Post-Installation Script

If you want to have commands run on your system after the installation ends, you can enter them in the area indicated on the screen. If you desire, you can have the post-installation script run outside of the chroot environment by selecting this option. A chroot environment is basically a minimal root file system created within the actual root file system. The minimal root environment lets your programs run, but prevents anyone from doing any damage to your actual root file system. Also, you can have your script interpreted by the scripting language of your choice by selecting the Use an Interpreter option and entering the interpreter to use.

Figure 4-19 The Kickstart Configurator program window, showing the

Post-Installation Script dialog box.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 93

Kickstart Installation 93

After you have entered your information here, you are finished configuring the Kickstart configuration file. Choose File ➪ Save File to save all your work.

Be sure to name the file ks.cfg if it isn’t already named that in the Save File dialog box.

Starting the Kickstart Installation

After you have completed configuring your ks.cfg file, you are ready to use it to do your installation. But, before you can begin a Kickstart installation, there are a few additional steps that you need to do. These steps are:

■■

You must place a copy of the configuration file in one of three locations.

The file can be placed on a bootable floppy, a bootable CD-ROM, or a network drive.

■■

You need to make the installation tree available. The installation tree is a copy of the Fedora Core or Red Hat Enterprise Linux CD-ROMs with the same directory structure. For a CD-ROM installation, you can put the

Installation CD 1 into the CD-ROM drive. For a hard drive or network installation, you need to have the ISO images of the binary Fedora Core or Red Hat Enterprise Linux CD-ROM accessible from those locations.

■■

If you are planning to use a bootable floppy or CD-ROM to start the Kickstart installation, you will have to make those bootable disks. Also, if you are planning to place the ks.cfg file on a bootable floppy or CD-ROM, you can do it when you create the bootable floppy or CD-ROM.

N OT E

You need to be logged in as the root user (or su to become root) to

create the bootable disks.

Creating a Bootable Floppy

To create a bootable floppy, follow these instructions:

1. Place the Red Hat Linux Installation CD-ROM 1 into your CD-ROM drive.

2. The CD will be automatically mounted and will appear in the

/media/CDROM directory. Change to the images directory on the CD.

3. Place a floppy disk into your floppy drive. At a terminal prompt, enter

dd=didiskboot.img of=/dev/fd0 bs=1440k

09_599496 ch04.qxd 8/30/05 6:30 PM Page 94

94 Chapter 4

4. If you want a copy of your Kickstart configuration file, ks.cfg, on your bootable floppy, mount the floppy by entering the command mount /dev/fd0 /media/floppy

; then copy the ks.cfg file that you created to the /media/floppy directory.

Creating a Bootable CD-ROM

To create a bootable CD-ROM, follow these instructions.

1. Place the Red Hat Linux Installation CD-ROM 1 into your CD-ROM drive.

2. The CD will be automatically mounted and will appear in the /media/

CDROM directory.

3. Copy the isolinux directory from the CD-ROM to a directory on your hard drive. You should create a temporary directory for this purpose.

I created a directory called /root/tempdir on my system to use for an example. Be sure to use the correct path for your system. Use the following command:

cp -r isolinux/ /root/tempdir/

4. If you want a copy of your Kickstart configuration file, ks.cfg, on your bootable CD-ROM, copy the ks.cfg file that you created to the

/isolinux directory on your hard drive at the location where you created it.

cp /root/ks.cfg /tempdir/isolinux/

5. Change to the temporary directory, cd /root/tempdir, that you created.

6. Use the chmod command to be sure the files you copied have the correct permissions.

chmod u+w isolinux/*

7. Create the ISO image file with this command. (The command should be entered on one line.)

mkisofs -o file.iso -b isolinux.bin -c boot.cat -no-emul-boot \-bootload-size 4 -boot-info-table -R -J -v -T isolinux/

8. The last step is writing the image file you created, file.iso, to a

CD-ROM using the process you would normally use to write to a

CD-ROM.

09_599496 ch04.qxd 8/30/05 6:30 PM Page 95

Kickstart Installation 95

Starting a Kickstart Installation

To begin installation, boot the system from a boot disk, and when the boot prompt appears, enter one of the following boot commands.

If the Kickstart file is on the floppy or CD boot disk, enter one of the following boot commands:

■■ linux ks=floppy

■■ linux ks=cdrom:/ks.cfg

If the Kickstart file is on a server, use the following boot command: linux ks=<file location>

The installation program, Anaconda, looks for a Kickstart file at the location specified in the ks command line argument that is passed to the kernel. You can enter any of the following as file locations for the ks=<file location> command.

■■

ks=hd:<device>:/<file>

— Use this command to have the installation program mount the file system on <device>. (<device> must be VFAT or ext2). Kickstart searches for the configuration file as

<file> in that file system (for example, ks=hd:sda3:/mydir/ks.cfg

).

■■

ks=file:/<file>

— Use this command to have the installation program read the file <file> from the file system without mounting anything. You would use this option if the Kickstart file is already on the initrd image.

■■

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

— Use this command if you want the installation program to look for the Kickstart file on the NFS server

<server>

, as file <path>. The Ethernet card will be configured using

DHCP.

■■

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

Use this command if you want the installation program to look for the Kickstart file on an HTTP server

<server>

, as file <path>. The Ethernet card will be configured using

DHCP.

■■

ks=cdrom:/<path>

:

— Use this to force the installation program to look for the Kickstart file on CD-ROM, as file <path>.

■■

ks

— If you enter ks without any command line options, the installation program will use the boot server field of the configuration file to find a

DHCP server to get information about an NFS server. The Ethernet card

09_599496 ch04.qxd 8/30/05 6:30 PM Page 96

96 Chapter 4

will be configured using this information. Finally, the installation program tries to find the Kickstart configuration file in one of the following places:

■■

If the name of the bootfile begins with a /, Kickstart will search the

NFS server’s root directory.

■■

If the name of the bootfile does not begin with a /, Kickstart will search the NFS server’s /kickstart directory.

■■

If you don’t list a bootfile, the PC receiving the IP address is searched.

N OT E

To use Kickstart for a network installation, you need to configure a

DHCP server. See Chapter 11 for details about configuring a DHCP server.

Summary

In this chapter, you learned about installing Fedora Core and Red Hat Enterprise Linux using the Kickstart program. First, you learned about the Kickstart configuration file and how to configure it using the Kickstart Configurator.

Then you learned how to start the Kickstart installation.

10_599496 ch05.qxd 8/30/05 7:09 PM Page 97

C H A P T E R

5

Exploring the

Desktops

IN THIS CHAPTER

■■

■■

■■

■■

■■

■■

Examining the Graphical Login Screen

Logging in and Using the GNOME Desktop

Using the Nautilus File Manager

Configuring GNOME

Taking a Look at KDE

Using the Konqueror File Manager

The GNU Network Object Model Environment (GNOME) desktop is a graphical user interface (GUI) that is installed as the default user interface during the installation process. Another popular desktop, KDE (K Desktop Environment), can also be selected as an option to be installed during system installation. Each of these user interfaces is similar to that of MS Windows or Mac OS X but with some notable differences. One large difference is the ability of the user to select which desktop to use upon system login. In this chapter, you examine both of these GUIs to discover some of the features that they offer and how to configure them to your liking.

Examining the Graphical Login Screen

Before you can do any exploring of the GNOME or KDE desktops, you must first log in. You log in from the graphical login window that is shown in

Figure 5-1.

97

10_599496 ch05.qxd 8/30/05 7:09 PM Page 98

98 Chapter 5

Figure 5-1 The graphical login window waits for you to log in.

Take a quick look at the options that you can choose from the login window.

At the bottom of the window are four choices that you can click to make additional selections:

■■

Language

— Clicking this opens a box displaying the languages available on your system. If you want to use the system default language, which was installed during system installation, you don’t need to do anything with this choice. In most cases, only one language is listed unless additional languages were installed during the system installation. The default language will typically be the language used at your location. If other languages have been installed, just click the language that you want to use.

■■

Session

— Clicking Session gives you the opportunity to select the desktop that you use after you log in. GNOME is the default desktop, so you need to use this choice only if you want to change to a different desktop, such as KDE.

■■

Reboot

— When you click Reboot a message asks whether you want to reboot the system.

■■

Shut Down

— When you click Shut Down a message asks whether you want to shut down your system.

10_599496 ch05.qxd 8/30/05 7:09 PM Page 99

Exploring the Desktops 99

Directly in the center of the window is the login field. This is where you enter your username and password to login. To login, do the following:

1. Type your username.

2. Press Enter.

3. Type your password.

4. Press Enter again.

Logging In and Using the GNOME Desktop

In this section you log in to the GNOME desktop and do some exploring to help you become familiar with its features. As mentioned earlier, the GNOME desktop is installed as the default desktop, so to enter GNOME, you can just enter your username and password in the graphical login window without having to make any choices from the four options, as explained in the preceding section.

N OT E

The GNOME desktop in Fedora Core 4 is slightly different from the

GNOME desktop in Enterprise Linux 4 because they use different versions of

GNOME. These differences are related to the menus displayed at the top of the desktop and are explained in this chapter.

After entering your username and password, you see the Fedora Core 4

GNOME desktop, as shown in Figure 5-2.

The GNOME desktop has a similar appearance to other well-known desktop environments such as MS Windows or Mac OS X. If you can use either of these desktops, you can easily master GNOME in a short time. Notice that the

GNOME desktop has a rather clean, almost Spartan, appearance.

The three icons in the upper-left corner of the desktop are links to your home directory, the system trash can that holds your deleted files until you empty the trash, and the Computer icon that opens the Nautilus graphical shell. The Nautilus File Manager gives you access to your files and directories so that you can do typical file management tasks such as copying and moving files. In addition to regular file management tasks, the Nautilus File Manager lets you perform desktop management as well. You look more closely at Nautilus later in this chapter. This list provides a closer look at these icons:

■■

Computer

— This icon also opens a Nautilus window the system. Your system devices may be different. The Computer window on my system contains four icons that are links to the following options:

10_599496 ch05.qxd 8/30/05 7:09 PM Page 100

100 Chapter 5

■■

Floppy Drive — The Floppy Drive icon is a link to the folder that contains the system mount point for the floppy drive. Double-clicking this icon displays the contents of the floppy disk that you inserted in the floppy drive.

■■

CD-R Drive — The CD-R Drive icon is a link to the folder that contains the system mount point for the CD-R drive. Double-clicking this icon displays the contents of the CD-ROM disk that you inserted in the CD-R drive.

■■

Filesystem — This icon is a link to the file system. Double-clicking this icon opens a new window displaying the root directory of the file system.

■■

Network — Clicking the Network icon gives you access to the network file systems. Any files or directories that are available across your network are shown here.

Figure 5-2 The Fedora Core 4 GNOME desktop after logging in for the first time.

10_599496 ch05.qxd 8/30/05 7:09 PM Page 101

Exploring the Desktops 101

■■

Home directory

— This icon is a link to the user’s home directory. The name of the user shown on the desktop corresponds to the user who is logged in. For example, Figure 5-2 shows the icon labeled as terry’s

Home because I logged in with that username. You can double-click this icon — or right-click and choose Open from the contextual menu — to open a window that displays the user’s home directory. If you rightclick and choose Browse Folder, a File Browser window opens.

■■

Trash

— This icon is a link to the system trash can. You can drag any icon, file, or directory and drop it here. When you’re ready to empty the trash, just right-click and select Empty Trash from the contextual menu.

Playing with the Panel

At the top and bottom of the desktop is a gray, horizontal bar. This area of the desktop is the panel and is similar to the taskbar in Windows. The left side of the top panel differs slightly between the Fedora Core version and the Enterprise Linux 4 version because Fedora Core and Enterprise Linux use different versions of GNOME. The description here will explain the differences. On the far left of the top panel of both Enterprise Linux and Fedora Core is the Applications icon, indicated by the word Applications and the Red Hat icon. To the right of the Applications icon is an Actions menu on Enterprise Linux that contains some actions you can perform, such as locking the desktop or logging out. To the right of the Applications icon on a Fedora system is the Places menu that gives you access to your file system and other locations such as a remote computer or network connection. To the right of the Places menu is the Desktop menu that gives you access to system settings and preferences and also lets you log out. To the right of the Actions menu on Enterprise Linux and the

Desktop menu on Fedora are icons representing programs that were installed during the system installation. You can start any of these programs by clicking them from the panel. Just move your mouse over any icon, and a pop-up message appears with a description of the program represented by the icon.

At the far right of the top panel is a small speaker icon that you can click to open a slider box to change the system volume setting. To the left of the speaker icon is the date and time display. You can change the system date and time properties by right-clicking on the date and time display and selecting your choice from the pop-up context menu. If you left-click on the date and time display a small calendar windows opens and displays the current month.

Click again to close the calendar. To the left of the date and time display is the system status icon, which shows update status for the system. This icon can be shown as a blue check mark, a red exclamation point, green arrows, or a gray question mark.

10_599496 ch05.qxd 8/30/05 7:09 PM Page 102

102 Chapter 5

C R O S S - R E F E R E N C E

Refer to Chapter 26 for more information about the system status icon and how to update your system.

At the far right of the bottom panel is a square gray area — the Workspace

Switcher — that is divided into four sections. When you first log in to GNOME the leftmost section of Workspace Switcher should be blue, indicating that you are in workspace one. You can switch between four workspaces in GNOME, so you actually get four distinct desktops that you can use. You can open different programs on the different desktops and switch between them by clicking the Workspace Switcher for the desktop that you want to see. Open some programs on the different desktops and then try clicking each of the four squares to see the effect of changing to a different workspace.

On the far left of the bottom panel is a Close Window icon that will hide, if visible, all open windows on the desktop. If the windows are already hidden, clicking this icon displays the windows. The open area on the bottom panel between the Workspace Switcher and the Close Window icon is used to show any programs that you’re running on your desktop. You can switch between programs running on a single desktop by clicking the program name from the bottom panel. Also shown in this area are icons that you can add to the panel as well as applets — applications that provide some type of useful information or entertainment.

Managing Applets on the Panel

The icons on the top and bottom panels are small programs called applets that have a variety of uses. For example, there is a weather applet that you can place on the panel to give you weather forecasts for any area you desire. In addition to the applets that are already on the panel, you can add your own. You also can move applets that are already there or delete them to make more room.

To add applets to the panel, do the following:

1. Right-click an empty area of the panel.

2. Choose Add to Panel from the contextual menu.

3. Choose the applet that you want to add.

4. Click Add to add it to the panel.

To move applets to another location on the panel:

1. Right-click the applet you want to move.

2. Click Move from the contextual menu.

3. Drag the applet to the desired location.

4. Click to release the applet to its new location.

10_599496 ch05.qxd 8/30/05 7:09 PM Page 103

Exploring the Desktops 103

To remove an applet from the panel:

1. Right-click the applet you want to remove.

2. Choose Remove from Panel from the contextual menu.

To modify the properties of an applet (or the panel):

1. Right-click the applet (or an empty area of the panel).

2. Choose Properties from the contextual menu.

3. Change the parameters in the Properties dialog box.

4. Click Close to accept your changes and close the Properties dialog box.

T I P

Right-clicking the panel or any applets on it presents a contextual menu, which gives you access to Help and some useful utilities for panel configuration.

Contextual menus may be different, depending on the type of applet that you’re selecting.

Choosing Items from the Applications Menu in Fedora Core

The Applications menu, represented by the Red Hat icon, is on the far-left corner of the top panel. The Applications menu button gives you access to a large number of applications. Click the Red Hat icon to open the Applications menu, and you see a menu, as shown in Figure 5-3, listing the many categories of applications from which you can choose.

Notice that many of the categories contain a right-pointing arrow. Moving your cursor over categories with a right-pointing arrow opens additional menus from which you can choose even more applications in that category.

There are probably more than 100 applications from which you can choose, many more than we can describe in this chapter. However, we do provide a brief description of the main category of applications here so you can have some idea what they do. Begin by starting at the top of the menu and then work your way toward the bottom.

■■

Accessories

— Here you can find applications that don’t fit well into the other categories, such as the calculator, as well as some text editors.

■■

Graphics

— This menu choice contains graphical programs. Here you find image viewing and editing applications.

■■

Internet

— Here you will find applications related to the Internet. For example, the Web browsers are located here as well as an FTP program.

10_599496 ch05.qxd 8/30/05 7:09 PM Page 104

104 Chapter 5

■■

Office

— This menu choice gives you access to the OpenOffice.org

office suite. The OpenOffice suite contains word processing, spreadsheet, and presentation software, and much more. You can also start several of the OpenOffice applications by clicking the icons on the left side of the panel.

■■

■■

Sound & Video

— Choosing this item gives you access to programs and utilities related to system sound and video. For example, if you want to adjust the system volume, use the utility here.

System Tools

— This menu choice gives you access to many Enterprise

Linux system administration utilities. You explore many of these tools in other chapters of this book.

■■

Run Application

— This menu item opens a dialog box where you can enter the name of a program that you want to run.

Figure 5-3 The Applications menu on the GNOME desktop in Fedora Core.

10_599496 ch05.qxd 8/30/05 7:09 PM Page 105

Exploring the Desktops 105

Choosing Items from the Places Menu in Fedora Core

The Places menu in Fedora Core is where you can choose the locations you want to view or go to. Figure 5-4 shows the Places menu.

Items on this menu include:

■■

Home Folder

— This menu item opens the home folder of the user who is logged in to the system.

■■

Desktop

— This menu item gives you a quick way to get to your desktop. It is really useful when you have several windows open and want to go to the desktop without having to close the open windows.

■■

Computer

— This menu item opens the computer folder of the user who is logged in to the system.

■■

Connect to Server

— Choosing this menu item opens the Nautilus File

Manager and displays any network servers that you can connect to.

■■

Search for Files

— Choosing this menu item opens a file search dialog box.

■■

Recent Documents

— Documents that you have recently opened appear in this list.

Figure 5-4 The Places menu in Fedora Core lets you choose places to go.

10_599496 ch05.qxd 8/30/05 7:09 PM Page 106

106 Chapter 5

Choosing Items from the Desktop Menu in Fedora Core

Items you can choose from the Desktop menu let you make changes to your system preferences and settings. You can also get systemwide help and lock your desktop and log out. Figure 5-5 shows the Desktop menu.

The following items are available on the Desktop menu:

■■

Preferences

— This menu choice opens the System Preferences window. Most of the GNOME settings can be modified with this menu choice. Selecting this from the menu is the same as double-clicking the

Computer icon on the desktop.

■■

System Settings

— This menu item contains Enterprise Linux system administration utilities and some GNOME configuration utilities as well.

■■

Help

— This menu item opens the Help browser. You can get help on using GNOME by choosing this item.

■■

About GNOME

— Choosing this item gives you information about the

GNOME version you are using.

Figure 5-5 The Desktop menu in Fedora Core lets you change system preferences.

10_599496 ch05.qxd 8/30/05 7:09 PM Page 107

Exploring the Desktops 107

■■

Lock Screen

— This menu option starts your system screensaver and locks your desktop. Move your mouse or press a key to open a dialog box that lets you enter your password to unlock the desktop.

■■

Log Out

— Choosing Log Out opens a dialog box giving you the option to log out, shut down, or restart the computer. Select the radio button of your choice, and then click OK.

Choosing Items from the Applications Menu on Enterprise Linux

The Applications menu, represented by the Red Hat icon, is on the far-left corner of the top panel. The Applications menu button gives you access to a large number of applications. Click the Red Hat icon to open the Applications menu, and you see a menu, as shown in Figure 5-6, listing the many categories of applications from which you can choose.

Notice that many of the categories contain a right-pointing arrow. Moving your cursor over categories with a right-pointing arrow opens additional menus from which you can choose even more applications in that category.

There are probably more than 100 applications from which you can choose, many more than we can describe in this chapter. However, we do provide a brief description of the main category of applications here so that you can have some idea what they do. Start at the top of the menu and then work your way toward the bottom.

Figure 5-6 The Applications menu on the GNOME desktop in Enterprise Linux.

10_599496 ch05.qxd 8/30/05 7:09 PM Page 108

108 Chapter 5

T I P

Your Applications menu might not be exactly as described in this section, depending on the type of system (Desktop, Workstation, Server) that you have installed.

■■

■■

■■

■■

Accessories

— Here you can find applications that don’t fit well into the other categories, such as the calculator, as well as some text editors.

Graphics

— This menu choice contains graphical programs. Here you find image viewing and editing applications.

Internet

— Here you will find applications related to the Internet. For example, the Web browsers are located here as well as an FTP program.

Office

— This menu choice gives you access to the OpenOffice.org

office suite. The OpenOffice suite contains word processing, spreadsheet, presentation software, and much more. You can also start several of the OpenOffice applications by clicking the icons on the left side of the panel.

■■

Preferences

— This menu choice opens the System Preferences window. Most of the GNOME settings can be modified with this menu choice. Selecting this from the menu is the same as double-clicking the

Computer icon on the desktop.

■■

Programming

— This menu item gives you access to some programs that can be used for debugging programs.

■■

■■

■■

Sound & Video

— Choosing this item gives you access to programs and utilities related to system sound and video. For example, if you want to adjust the system volume, use the utility here.

System Settings

— This menu item contains Enterprise Linux system administration utilities and some GNOME configuration utilities as well.

System Tools

— This menu choice gives you access to many Enterprise

Linux system administration utilities. You explore many of these tools in other chapters of this book.

■■

File Browser

— This menu item is a link to the Nautilus File Manager and opens in the user’s home directory.

■■

Help

— This menu item opens the Help browser. You can get help on using GNOME by choosing this item.

■■

Network Servers

— Choosing this menu item opens the Nautilus File

Manager and displays any network servers that you might have.

10_599496 ch05.qxd 8/30/05 7:09 PM Page 109

Exploring the Desktops 109

T I P

Fedora Core and Enterprise Linux offer you several ways to start applications. You can click the Applications menu icon in the left corner of the panel. You can also start any executable application by double-clicking its icon from the Nautilus File Manager.

Choosing Actions from the Actions Menu in Enterprise Linux

To the right of the Applications menu is the Actions menu, as shown in

Figure 5-7.

Items on this menu, listed from top to bottom, include the following:

■■

Run Application

— This menu item opens a dialog box where you can enter the name of a program that you want to run.

■■

Search for Files

— Choosing this menu item opens a file search dialog box.

Figure 5-7 The GNOME Actions menu in Enterprise Linux 4.

10_599496 ch05.qxd 8/30/05 7:09 PM Page 110

110 Chapter 5

■■

■■

■■

Recent Documents

— Documents that you have recently opened appear in this list.

Take Screenshot

— You can use this menu choice to capture an image of your current display.

Lock Screen

— This menu option starts your system screensaver and locks your desktop. Move your mouse or press a key to open a dialog box that lets you enter your password to unlock the desktop.

■■

Log Out

— Choosing Log Out opens a dialog box giving you the option to log out, shut down, or restart the computer. Select the radio button of your choice and then click OK.

Using the Nautilus File Manager

The Nautilus File Manager is a graphical shell for GNOME. You can use Nautilus not only to manage the files and directories on your system but also to perform many GNOME and system configurations. With Nautilus, you can even access your system applications.

To start the Nautilus File Manager, use any of the following methods:

■■

■■

In Enterprise Linux select File Browser from the Applications menu.

In Fedora Core choose System Tools ➪ File Browser.

Right-click any folder and choose Browse Folder from the contextual menu.

Using either of these methods will open the Nautilus File Manager, as shown in Figure 5-8.

A brief explanation of the items on the Nautilus File Manager window is in order:

■■

■■

■■

Menu bar

— At the top of the window is the menu bar, which is similar to menu bars from other programs. From the menu bar, you can access choices for performing various actions.

Toolbar

— Below the menu bar is the toolbar. The toolbar holds buttons that you can use to perform the actions such Back, Forward, and Reload.

Location bar

— The location bar contains a text field where you can enter a file, folder, or FTP site to go to. The location bar also has a zoomin and a zoom-out button (magnifying glass icons) with which you can change the size of items. Finally, the View As Icons drop-down list lets you choose how you want to view the items.

10_599496 ch05.qxd 8/30/05 7:09 PM Page 111

Exploring the Desktops 111

Figure 5-8 The Nautilus File Manager window.

■■

Window panes

— Beneath the location bar, the Nautilus window is divided into two panes. The left, smaller pane (Information) shows a drop-down list that lets you choose what is displayed about items appearing in the larger, right pane. If you choose Tree from the list, you can see your entire file system tree in the left pane.

■■

The larger, right pane displays the contents of the files or directories that you’re viewing. Note: All directories appear as folders in Nautilus.

You can view the contents of folders as either a list or as icons by choosing from the View As Icons drop-down list (in the location bar). You can also access FTP sites by entering the URL into the location text area.

Status bar

— At the bottom of the Nautilus window is the status bar, which displays status information about the files or folders that you are viewing.

■■

Resize handle

— In the lower-right corner is a handle that you can use to resize the window. Move your mouse over the handle and then click and drag to resize the window. Release the mouse button when the window is the desired size.

T I P

When using the Nautilus File Manager, all directories are shown as folders. For the remainder of this section, we refer to directories as folders.

10_599496 ch05.qxd 8/30/05 7:09 PM Page 112

112 Chapter 5

Displaying Your Home Folder

If you start Nautilus by using one of the methods explained earlier, Nautilus opens to your home folder. However, if you changed folders while in Nautilus, you might want to return to your home folder. You can do this in one of two ways:

■■

■■

Choosing Go ➪ Home from the Nautilus menu bar

Clicking the Home icon on the Nautilus toolbar

If you want to refresh the display, click Reload on the toolbar.

Displaying the Contents of a Folder

You can easily move from one folder to another in Nautilus. Again, you have more than one way to navigate through your file system.

■■

Double-click the folder

— If the folder that you want to view is visible in the large, right pane of the Nautilus window, you can open it by double-clicking it.

■■

Enter the location

— You can enter the name of the folder that you wish to view by typing it into the location bar text field.

■■

■■

Use the tree view

— Choose Tree from the drop-down list in the small, left pane of the Nautilus window and select the folder that you wish to view.

Use the Search tool

— Click the Actions menu button and choose

Search for Files from the menu.

To move forward and backward through your file system, you can use the

Forward and Back buttons from the toolbar or you can choose Go ➪ Forward/Back from the menu bar. To move up a level, you can use the Up button on the toolbar or you can choose Go ➪ Up from the menu bar.

Opening Files

Whenever you double-click a file, Nautilus is configured by default to perform some type of action on the file, depending on the type of file. Nautilus either opens the file by using a preconfigured viewer or runs the file if it is an executable file.

10_599496 ch05.qxd 8/30/05 7:10 PM Page 113

Exploring the Desktops 113

Nautilus has been configured to open the following types of files in the large, right pane:

■■

Graphic image files

— Nautilus automatically displays a small icon of the graphic image, typically called a thumbnail, in the folder view.

Double-clicking the thumbnail opens the file in the left window. Click the Back button on the toolbar to return to the folder view. Nautilus can display GIF, JPEG, and PNG images.

■■

Text files

— Nautilus opens any text files in the default text editor, which is gedit. With gedit you can edit the text as you desire. When you are finished, close gedit by clicking File ➪ Exit or click the X in the upper-right corner of the gedit window.

Accessing FTP Sites

You can use the Nautilus File Manager to access an FTP site. All you need to do is enter the URL of the site in the location bar text field. If you need to log in to the site, you can use the following syntax.

ftp://username:[email protected]

You can drag and drop files to move them from the FTP site to your desired folder.

Using Bookmarks

With Nautilus, you can use bookmarks to keep track of your favorite locations. You can bookmark files, folders, and FTP sites as desired.

Adding a Bookmark

To add a bookmark, do the following:

1. Click the item that you wish to bookmark.

2. Choose Bookmarks ➪ Add Bookmark from the menu bar.

Editing Bookmarks

To edit a bookmark, do the following:

1. Choose Bookmarks ➪ Edit Bookmarks to open the Edit Bookmarks dialog box, as shown in Figure 5-9.

10_599496 ch05.qxd 8/30/05 7:10 PM Page 114

114 Chapter 5

Figure 5-9 The Edit Bookmarks dialog box.

2. Select the bookmark from the list on the left side of the dialog box.

3. Change the name and location as desired. If you enter a different location, you can click Jump to to immediately go to that location.

4. Click Close to finish editing the bookmark.

Deleting Bookmarks

To delete a bookmark:

1. Choose Bookmarks ➪ Edit Bookmarks from the menu bar. The Edit

Bookmarks dialog box opens.

2. Select the bookmark that you want to remove.

3. Click the Remove button.

4. Click the Close button to close the dialog box.

Managing Your Files and Folders

You can take many actions when managing your file system with Nautilus.

Table 5-1 briefly explains the action that you want to perform and how you should do it.

Table 5-1 Performing Tasks Using Nautilus

ACTION METHOD

Move an item

Copy an item

Link to an item

Click item and drag it to desired location.

Click item and hold Ctrl while dragging item.

Click item and press Ctrl+Shift while dragging.

10_599496 ch05.qxd 8/30/05 7:10 PM Page 115

Exploring the Desktops 115

ACTION

Select single item

Select contiguous items

Select multiple items

Select all items

Create folder

Rename item

Move to trash

Delete item

Change permissions

Display trash

Restore trashed item

Empty trash

Add emblem

Change single icon

Change item size

METHOD

Click item.

In icon view, click and drag box around items. In list view, press Shift; click the first item, and then click the last.

Press Ctrl; click desired items.

Choose Edit ➪ Select All Files from menu bar.

Right-click and choose Create Folder from contextual menu.

Right-click and choose Rename from the contextual menu.

Right-click and choose Move to Trash from the contextual menu.

Right-click and choose Move to Trash.

Right-click, choose Properties, and click the Permissions tab.

Right-click the Trash icon and choose Open from the contextual menu.

Open Trash folder and drag item to desired location.

Right-click the Trash icon and choose Empty Trash.

Right-click, choose Properties, click the Emblems tab, and choose desired emblem.

Right-click, choose Properties, click Select Custom Icon, and choose desired icon.

Choose Zoom In or Zoom Out from toolbar.

Customizing the Nautilus File Manager

A very nice feature of Nautilus is that you can configure it to make it work the way you want it to. You can change many preferences; in this section, I tell you about them and how to change them.

Editing File Manager Preferences

To open the Nautilus File Management Preferences dialog box, choose Edit ➪

Preferences from the menu bar in a Nautilus window. The dialog box shown in

Figure 5-10 appears.

10_599496 ch05.qxd 8/30/05 7:10 PM Page 116

116 Chapter 5

Figure 5-10 The Nautilus Preferences dialog box.

On this dialog box are five tabbed pages:

■■

■■

Views

— Preferences on this tab give you options for setting the default view parameters for Nautilus, such as icon view, sort order, and showing hidden files.

Behavior

— Preferences on this tab are concerned with the way Nautilus handles executable files and trash. You can also choose between single- and double-clicking here.

■■

■■

■■

Display

— This tab lets you decide what information you want displayed with your icons, such as size, date created, date modified, and date format.

List Columns

— The settings on this tab let you choose what information is displayed as well as its order, when you choose list view.

Preview

— The settings on this tab determine how your files are displayed in their folders. For example, you can decide here whether you want thumbnail views of graphic files.

T I P

You can change many preferences to alter the appearance and performance of Nautilus. You have seen only a few of them, so experiment with them to see for yourself what they do.

10_599496 ch05.qxd 8/30/05 7:10 PM Page 117

Exploring the Desktops 117

Changing the File Manager Background and Icon Emblems

Another nice feature of Nautilus is the ability to display colors and patterns in the File Manager window. For example, I like to change the background color for my home directory to light blue. That way, I can tell immediately when I’m in my home directory when I see the blue background. You can also assign emblems to icons. Emblems are small graphics that are used to make your icons more meaningful You can easily change the colors and patterns or add emblems by doing the following:

1. Choose Edit ➪ Backgrounds and Emblems from the Nautilus menu bar to open the Backgrounds and Emblems dialog box, as shown in

Figure 5-11.

2. Click the Patterns, the Colors, or the Emblems button on the left side of the dialog box.

3. Click and drag the pattern, color, or emblem from the right side of the dialog box to where you want to place it. You can drag a color or pattern to the large, right pane of the File Manager window to change the color or pattern. You can drag an emblem to an icon to attach it to the icon. Click close when you are finished.

T I P

You can also drag the patterns or colors directly to the desktop and drop them there. Your desktop will change to reflect your new color or pattern.

Figure 5-11 The Background and Emblems dialog box.

10_599496 ch05.qxd 8/30/05 7:10 PM Page 118

118 Chapter 5

Showing and Hiding Views

You can decide what you want to view and what you don’t in your File Manager. You can view or hide the side pane, the status bar, the toolbar, and the location bar by clicking the appropriate item from the View menu on the menu bar. These items are toggled items. If the item is checked, it is available for viewing; if not checked, it is not available. Clicking the item toggles it on or off.

Configuring GNOME

You can also customize your entire desktop as easily as you configure your

Nautilus File Manager. Quite a few preferences can be modified in GNOME.

We can’t possibly explain all of them here in this chapter, but we can show you how to change one of them. You can play around with the rest and make changes as you desire. Take a look at setting up a screensaver. To set the preferences for the screensaver, do the following:

1. Choose Applications ➪ Preferences ➪ Screensaver in Enterprise Linux or Desktop ➪ Preferences ➪ Screensaver in Fedora Core. The Screensaver Preferences dialog box, as shown in Figure 5-12, opens.

2. Choose the mode for the screensaver by making your choice from the drop-down list.

3. Select the image or images that you want for your screensaver by selecting the check box in front of your choice.

4. Pick the times that you want to use.

Figure 5-12 Configure the screensaver here.

10_599496 ch05.qxd 8/30/05 7:10 PM Page 119

Exploring the Desktops 119

T I P

Also be sure to look at the Advanced tab to see whether you want to change any items there. Items on the Advanced tab include image manipulation, display power managements, color map, and diagnostic settings.

5. When you finish making choices, test your screensaver by clicking the

Preview button.

T I P

Don’t forget to have a look at the settings for the screensavers that you chose. (Click the Settings button to see them.) In many cases, you can create some interesting effects by changing the settings. For example, you can change the speed of the screensaver or the number of colors displayed.

6. Click the Close button when you’re finished. Your new screensaver is enabled.

Logging Out

After you finish working in GNOME, you should log out before leaving the

PC. Logging out is always a good idea to prevent anyone from using your system. You can log out of GNOME as follows:

1. Choose Actions ➪ Log Out in Enterprise Linux or Desktop ➪ Log Out in Fedora Core.

2. From the Log Out dialog box, you can choose to log out, restart the system, or shut down the system by selecting the radio button in front of your choice.

3. After making your choice, click OK to execute it.

Taking a Look at KDE

The default desktop in Fedora Core and Enterprise Linux is GNOME, but another desktop — KDE — is available if you want to give it a try. If you want to use it, you’ll have to make sure that it is installed on your system because the default installation of Fedora Core and Enterprise Linux does not install KDE.

In this section, we give you a brief overview of KDE just to make you aware of it and perhaps tempt you to try it. We will briefly explain the KDE desktop, show you the Applications menu where you can find some applications to try, and tell you about the Konqueror File Manager. After that, you are on your own to explore if you like.

10_599496 ch05.qxd 8/30/05 7:10 PM Page 120

120 Chapter 5

You can check whether KDE is installed from the graphical login screen.

Click Session (refer to Figure 5-1) and select KDE from the choices. If KDE is not a choice, it isn’t installed — but you can easily install it by using the Package Management tool.

After selecting KDE for your session, enter your username and password to login. You will see the KDE desktop, as shown in Figure 5-13.

The KDE desktop has an appearance similar to other well-known desktop environments such as GNOME or MS Windows or Mac OS X. If you can use these desktops, you will easily master KDE in a short time. Notice that the

KDE desktop has a rather clean appearance with little desktop clutter — just one icon at the top and a panel at the bottom. A description of the KDE desktop is in order here.

At the bottom of the desktop is a gray, horizontal bar. This area of the desktop is the panel and is similar to the taskbar in Windows. On the far left of the panel is the Applications icon, indicated by the Red Hat icon. To the right of

Applications are icons representing programs that were installed during the system installation. You can start any of these programs by clicking them from the panel. Just move your mouse over any icon, and a contextual menu appears with a description of the program represented by the icon.

Figure 5-13 The KDE desktop after logging in.

10_599496 ch05.qxd 8/30/05 7:10 PM Page 121

Exploring the Desktops 121

To the right of the program icons on the panel is a square gray area — the

Workspace Switcher — that is divided into four sections. When you first log in to KDE, the leftmost section of Workspace Switcher should be white, indicating that you are in workspace one. You can switch between four workspaces in

KDE, so you actually get four distinct desktops that you can use. You can open different programs on the different desktops and switch between them by clicking the Workspace Switcher for the desktop that you want to see. Open some programs on the various desktops and then try clicking each of the four squares to see the effect of changing to a different workspace.

On the far right of the panel is a display of the current date and time. The open area on the panel between the Workspace Switcher and the date and time display is used to show any programs that you’re running on your desktop.

You can switch between programs running on a single desktop by clicking the program name from the bottom panel. Also shown in this area are icons that you can add to the panel as well as applets. Applets are applications that provide some type of useful information or entertainment.

Managing Applets

The icons on the bottom panel are small programs called applets that have a variety of uses. For example, there is a weather applet that you can place on the panel to give you weather forecasts for any area you desire. In addition to the applets that are already on the panel, you can add your own. You also can move applets that are already there or delete them to make more room.

To add applets to the panel, do the following:

1. Right-click an empty area of the panel.

2. Choose Add to Panel from the contextual menu.

3. Choose the application that you want to add.

4. Click Add to add it to the panel.

To move applets to another location on the panel:

1. Right-click the applet that you want to move.

2. Click Move from the contextual menu.

3. Drag the applet to the desired location.

4. Click to release the applet to its new location.

To remove an applet from the panel:

1. Right-click the applet that you want to remove.

2. Choose Remove from Panel from the contextual menu.

10_599496 ch05.qxd 8/30/05 7:10 PM Page 122

122 Chapter 5

To modify the properties of an applet (or the panel):

1. Right-click the applet (or an empty area of the panel).

2. Choose Properties from the contextual menu.

3. Change the parameters in the Properties dialog box.

T I P

Right-clicking the panel or any applets on it presents a contextual menu, which gives you access to Help and some useful utilities for panel configuration.

Contextual menus are different depending on the type of applet that you’re selecting.

Choosing Applications from the Applications Menu

The Applications menu, represented by the Red Hat icon, is on the far-left corner of the bottom panel. The Applications button gives you access to a large number of applications. Click the Red Hat icon to open the Applications menu, and you see a menu, as shown in Figure 5-14, listing the many categories of applications from which you can choose.

Figure 5-14 The Applications menu on the KDE desktop.

10_599496 ch05.qxd 8/30/05 7:10 PM Page 123

Exploring the Desktops 123

Notice that many of the categories contain a right-pointing arrow. Moving your cursor over categories with a right-pointing arrow opens additional menus from which you can choose even more applications in that category.

There are probably more than 100 applications from which you can choose, many more than I can describe in this book. However, I do provide a brief description of the main category of applications here so you can have some idea what they do. Begin by starting at the bottom of the menu and work your way toward the top.

T I P

Your Applications menu might not be exactly as described in this section, depending on the type of Fedora Core installation or version of Enterprise Linux you have installed.

■■

Logout

— This menu item gives you a quick way to get to your desktop. It is really useful when you have several windows open and want to go to the desktop without having to close the open windows.

Choosing Logout opens a dialog box giving you the option to log out or cancel. Select the radio button of your choice and then click OK.

■■

Lock Session

— This menu option starts your system screensaver and locks your desktop. Move your mouse or press a key to open a dialog box that lets you enter your password to unlock the desktop.

■■

Run Command

— This menu item opens a dialog box where you can enter the name of a program that you want to run.

■■

Home

— This menu item is a link to the user’s home directory.

■■

Help

— This menu item opens the Help browser. You can get help on using KDE by choosing this item.

■■

Control Center

— The Control Center is used for making configuration changes to the KDE desktop.

■■

System Tools

— This menu choice gives you access to many Enterprise

Linux system administration utilities. Tools for configuring your network and printers are located here.

■■

System Settings

— This menu item contains Enterprise Linux system administration utilities and some KDE configuration utilities as well.

Some of the tools here can be used to configure your Web server as well as other servers.

■■

Sound & Video

— Choosing this item gives you access to programs and utilities related to system sound and video. For example, if you want to adjust the system volume, use the utility here.

10_599496 ch05.qxd 8/30/05 7:10 PM Page 124

124 Chapter 5

■■

■■

■■

Programming

— This menu item gives you access to some programs that can be used for debugging programs.

Preferences

— This menu choice opens the System Preferences window. Most of the GNOME settings can be modified with this menu choice. Selecting this from the menu is the same as double-clicking the

Computer icon on the desktop.

Office

— This menu choice gives you access to the OpenOffice.org

office suite. The OpenOffice suite contains word processing, spreadsheet, and presentation software, and much more. You can also start several of the OpenOffice applications by clicking the icons on the left side of the panel.

■■

Internet

— Here you will find applications related to the Internet. For example, the Web browsers and FTP program are located here.

■■

Graphics

— This menu choice contains graphical programs. Here you find image viewing and editing applications.

■■

Accessories

— Here you can find applications that don’t fit well into the other categories, like the calculator, as well as some text editors.

Using the Konqueror File Manager

The Konqueror File Manager is a graphical shell for KDE. You can use Konqueror not only to manage the files and directories on your system but also as a Web browser to access the Internet.

To start the Konqueror File Manager, shown in Figure 5-15, select Home from the Applications menu.

A brief explanation of the items on the Konqueror File Manager window is in order:

■■

■■

Menu bar

— At the top of the window is the menu bar, similar to menu bars from other programs. From the menu bar, you can access tools to perform various actions.

Toolbar

— Below the menu bar is the toolbar. The toolbar holds buttons that you can use to perform the action indicated by the button, such as back, forward, or reload. The toolbar also has a zoom-in and a zoomout button (magnifying glass icons) with which you can change the size of items. Finally, the toolbar contains icons that let you choose how you want to view the items in the folder.

10_599496 ch05.qxd 8/30/05 7:10 PM Page 125

Exploring the Desktops 125

Figure 5-15 The Konqueror File Manager window.

■■

Location bar

— The location bar contains a text field where you can enter a file, folder, or URL to go to.

■■

Window panes

— Beneath the location bar, the Konqueror window is divided into two panes. The left, smaller pane shows information about the icon selected from the far left side of the File Manager window.

Moving your mouse over an icon displays information about the icon.

Clicking an item from the list in the left pane displays items in the larger, right pane. If you choose the Root Folder icon, you can see your entire file system tree in the left pane.

■■

The larger, right pane displays the contents of the files or directories that you’re viewing. Note: All directories appear as folders in Konqueror. You can view the contents of folders as either a list or as icons by choosing from the View As icons (in the toolbar). You can also access Web or FTP sites by entering the URL into the location text field.

Status bar

— At the bottom of the Konqueror window is the status bar, which displays status information about the files or folders that you are viewing.

10_599496 ch05.qxd 8/30/05 7:10 PM Page 126

126 Chapter 5

Logging Out of KDE

After you finish working in KDE, you should log out before leaving the PC.

Logging out is always a good idea to prevent anyone from using your system.

You can log out of KDE as follows:

1. Choose Applications ➪ Log Out.

2. From the Log Out dialog box, you can choose to log out or cancel to return to the desktop.

3. After making your choice, click OK to execute your choice.

Summary

In this chapter you took the express tour of the two most common desktops provided with Fedora Core and Enterprise Linux. The GNOME desktop is the default desktop that is installed when the system is installed. GNOME is very powerful, and you can use it as is or configure it to your liking as you saw in some of the examples in this chapter. The KDE desktop is not installed by default but can be selected to be installed during system installation, or after the system is already installed. KDE is also a very powerful graphical environment as you saw from some of the examples in this chapter.

11_599496 ch06.qxd 8/30/05 6:21 PM Page 127

C H A P T E R

6

IN THIS CHAPTER

■■

■■

■■

■■

■■

Examining the Boot Process

Exploring Runlevels

Starting Programs at System Boot

Shutting Down the System

Changing the GRUB Configuration

System Startup and Shutdown

All Red Hat systems, whether Fedora Core or Enterprise Linux, use a similar procedure for starting up the operating system. As the system boots, the operating system loads programs in an orderly fashion. You are able to make changes to the programs that load and their configurations after the system has booted. The changes you make will then affect the boot process the next time and all subsequent times that your system boots.

The process of shutting down the system also follows a consistent, orderly method that you can customize as you desire. For a clear understanding of how your system works, it is good to know the methodology behind the orderly process of bringing your system up as well as shutting it down. By knowing this process in depth, you can make any desired changes to the configuration files and gain total control over the functionality of your system.

You will also be able to easily find problems that may be keeping your system from booting properly and quickly correct them. This chapter gives you the details about what happens when your start and shut down your system.

127

11_599496 ch06.qxd 8/30/05 6:21 PM Page 128

128 Chapter 6

Examining the Boot Process

There are some basic steps that all systems must perform to boot. When you turn on your PC, it runs a program called the basic input/output system

(BIOS). The BIOS is the only way to communicate with the system components until the operating system is up and running and able to take over system management functions. Unlike the operating system, which is installed on a user-writable disk, such as a floppy, CD-ROM, or hard drive, the system BIOS is typically installed on a read-only memory (ROM) chip physically attached to the system board. This ROM chip is a type of chip usually referred to as an electronically erasable programmable read-only memory (EEPROM) chip, meaning that it is not normally writable by the end user. It is possible to rewrite an EEPROM BIOS chip, but this requires a program from the chip manufacturer and is not a process that should be taken lightly as any errors here could make your system totally unusable.

After the BIOS loads, it performs some diagnostics on the hardware, checks the installed components to be sure they are functioning, and checks the system RAM. Next, the BIOS tries to find a system drive from which it can load the boot program to begin the process of starting the operating system. You can specify the search order for the drives by changing the settings in the system BIOS configuration, which you can typically access by entering some key combination while the system is performing its power-on self test (POST). If you don’t make any changes to the BIOS configuration, most systems by default will look for a bootable floppy disk or CD-ROM before moving on to the system hard drives. Usually the first hard drive that boots is the master

IDE device of the primary IDE bus, but you can also change this setting in the

BIOS if you desire. The first sector of the drive has an area called the Master

Boot Record (MBR), which holds the program that is used to begin the actual loading of the operating system. As soon as the BIOS finds the MBR, it gives up control of the boot process. In the case of Fedora Core and Enterprise Linux, a program called a boot loader begins the loading of the operating system. The boot loader program used is called the Grand Unified Boot loader, or GRUB. In the next section you take a closer look at GRUB and how it works.

The Boot Loader

The GRUB program used by Fedora Core and Enterprise Linux uses a twostep process to begin loading the operating system. These two steps are typically referred to as stages one and two. In stage one, a program on the MBR is used to find the second stage program that will begin the process of loading the operating system into system memory. GRUB uses a configuration file

11_599496 ch06.qxd 8/30/05 6:21 PM Page 129

System Startup and Shutdown 129

called /boot/grub/grub.conf to provide information to the second-stage loader. Later in this chapter you learn how to make changes to the /boot/ grub/grub.conf

configuration file. The first thing the second stage loader does is present you with a nice graphical menu screen, as shown in Figure 6-1.

As you can see from Figure 6-1, there are two versions of the kernel listed with one highlighted. This is the kernel that will be loaded by default. But you can use the GRUB menu to select different Linux kernels, or even different operating systems, to load. In many cases, when someone decides to try Linux for the first time, he or she is already running MS Windows and is planning to set up the system to do a dual boot. So, when the GRUB menu appears there is an additional choice for the other operating system. Most of the time Windows is already installed and Linux is installed later. In this case, the Linux installation would take care of making the changes to the /etc/boot/grub.conf

file to present the other operating system as a choice on the GRUB menu.

N OT E

If you have more than one processor in your system, or you have a

Pentium 4 processor with hyper-threading, you will see two kernels listed even on a freshly installed system. The second kernel will end with the letters smp, which means symmetrical multiprocessor. In this case, you should choose to boot the SMP kernel.

Figure 6-1 The GRUB graphical menu screen shows the kernel(s) available to boot.

11_599496 ch06.qxd 8/30/05 6:21 PM Page 130

130 Chapter 6

If you don’t choose a kernel to load, GRUB will load whichever kernel is specified in the configuration file as the default kernel. If you want to select the kernel to load, you can use your cursor keys to highlight the kernel you want loaded. Regardless of whether you choose the kernel or let GRUB do it for you, the next step in the boot process is the actual loading of the kernel. The kernel is always located in the /boot directory and will have a name similar to vmlinuz-2.6.10-1.737_FC3

. Your kernel version number will most likely be different from the version shown here. GRUB has one more task to do and that is to load a ramdisk image, called initrd that has the same version number as the kernel you are going to load into system memory. initrd loads any special drivers that might be needed by the kernel to load the OS. And that is it for GRUB; its work is done and the kernel is now responsible for continuing the boot process. But before you say good-bye to GRUB, take a look at some of the things you can do with GRUB while the system is booting.

Using GRUB during Boot

In addition to loading a default kernel or operating system when GRUB takes over from the BIOS, GRUB lets you make changes to the parameters it passes to the kernel. You’ll notice that Figure 6-1 shows some instructions for selecting the OS as well as which keys to press to edit the parameters that will be passed by GRUB to the kernel. To edit the boot parameters, highlight the kernel you want to edit and press the e key. A new screen opens, as shown in Figure 6-2.

Figure 6-2 Selecting a kernel to edit boot parameters.

11_599496 ch06.qxd 8/30/05 6:21 PM Page 131

System Startup and Shutdown 131

Figure 6-2 displays the locations of the kernel and initrd files that will be used to begin booting the OS. To edit any of the information displayed here, highlight your choice and again press the e key. For example, if you want to edit kernel parameters, highlight the line beginning with kernel and press e. A new screen appears, as shown in Figure 6-3.

To enter any parameters you want to pass to the kernel, type them in at the end of the line. Be sure to separate them by spaces. For example, to tell the kernel not to use ACPI enter the command acpi=off. Now when the kernel boots it will disable ACPI. After you have finished entering the parameters you desire press Enter to accept your changes and return to the previous screen.

Press the letter b and the kernel will boot and begin the process of loading the operating system.

N OT E

Using this method to pass parameters to the kernel is only applied to this instance. When the system is rebooted, the parameters will not be passed again. If you want the parameters passed at every boot, you need to put them

into the /boot/grub/grub.conf file. You learn how to modify this file later in

the chapter.

It is also possible to open a command line from GRUB that is similar to a

Bash shell except the commands entered are specific to GRUB. To enter the

GRUB command line interface, press the letter c from the GRUB menu. You can then press to get a listing of the commands you can use. Figure 6-4 shows the GRUB command-line interface listing the possible commands.

Figure 6-3 Editing the kernel boot parameters.

11_599496 ch06.qxd 8/30/05 6:21 PM Page 132

132 Chapter 6

Figure 6-4 The GRUB command-line interface showing possible commands.

T I P

You can use the info pages that are already installed on your system to get a complete explanation of all the GRUB commands. Just type info grub at a command prompt.

The next section explains the steps taken by the kernel.

The Kernel

The first thing the kernel does after taking over from GRUB is to prepare the system memory for use. Next all system hardware is probed and configured if possible. The kernel will uncompresses the initrd in RAM, mount it as a ramdisk, and then runs linuxrc in the ramdisk. This can be a command file like a regular rc file or a symlink to init on the initrd. If the former, it runs the commands in there, sets the real root device at the end, and then returns so that init starts. If the latter, it runs the commands in /etc/inittab on the ramdisk like any other Linux boot process. This can end with a pivotroot or chroot to the real root device. Fedora’s initrd files use /Linux as a command script; the initrd and its linuxrc script are very important nowadays because that’s what mounts /proc, /sys, and /dev/shm, starts udev and hotplug

, and insmods special drivers such as SCSI drivers. Most of the time the kernel is able to autodetect and configure hardware devices, but sometimes, especially with new devices, the kernel cannot properly configure them.

Usually, this means that your device won’t function correctly, or at all, but the

11_599496 ch06.qxd 8/30/05 6:21 PM Page 133

System Startup and Shutdown 133

system will still function. If you have set up RAID or Logical Volume Management (LVM) on your system, the kernel will also configure these devices. After the kernel has configured all the system devices and mounted the system drives, it runs the /sbin/init command.

The /sbin/init Program

The /sbin/init program is the first system process that runs after the kernel has configured the system devices and mounted the system drives. The /init program is like the project manager of the system because it manages the remaining steps of booting the system and is the parent or grandparent of all the rest of the automatically started system boot processes. Basically, the init program coordinates the order of the many scripts it will run to complete system setup. The first script /init runs is the /etc/rc.d/rc.sysinit script.

This script starts system swap, checks the file systems, and performs other system initialization. Then the init command refers to the /etc/inittab script to get information about how to start the system, which system initialization script to run and bring the system to the runlevel indicated in the inittab script. After a typical system installation, the default runlevel is set to runlevel 5. The rest of this section describes the steps the system takes to boot to runlevel 5.

After reading the /etc/inittab script, init turns over control to the rc.sysinit

program which reads the /etc/rc.d/init.d/functions file to determine the procedure to use to set the default system path, start and stop programs, find the process ID (PID) of a running process and how to log the success or failure of starting a program. The next script to run is

/etc/rc.d/rc

, which is responsible for starting and stopping services when the runlevel changes and determining the new runlevel.

In the /etc/rc.d directory are additional directories rc0.d, rc1.d, rc2.d

, rc3.d, rc4.d, rc5.d, and rc6.d. The number in the directory name corresponds to the runlevel. Each of these directories contains scripts that are used to stop and start services for the runlevel. In this example, the system is booting to runlevel 5, so the init program looks in the /etc/rc.d/rc5.d/ directory for the processes to start and stop. Listing 6-1 shows the contents of the rc5.d directory for a newly installed Fedora Core 3 system.

K01yum -> ../init.d/yum

K02NetworkManager -> ../init.d/NetworkManager

K05saslauthd -> ../init.d/saslauthd

K10psacct -> ../init.d/psacct

K20nfs -> ../init.d/nfs

K24irda -> ../init.d/irda

Listing 6-1 The scripts used to stop and start services in runlevel 5. (continued)

11_599496 ch06.qxd 8/30/05 6:21 PM Page 134

134 Chapter 6

K30spamassassin -> ../init.d/spamassassin

K35vncserver -> ../init.d/vncserver

K35winbind -> ../init.d/winbind

K36lisa -> ../init.d/lisa

K50netdump -> ../init.d/netdump

K73ypbind -> ../init.d/ypbind

K74nscd -> ../init.d/nscd

K74ntpd -> ../init.d/ntpd

K85mdmpd -> ../init.d/mdmpd

K89netplugd -> ../init.d/netplugd

K90bluetooth -> ../init.d/bluetooth

K94diskdump -> ../init.d/diskdump

K99microcode_ctl -> ../init.d/microcode_ctl

S04readahead_early -> ../init.d/readahead_early

S05kudzu -> ../init.d/kudzu

S06cpuspeed -> ../init.d/cpuspeed

S08iptables -> ../init.d/iptables

S09isdn -> ../init.d/isdn

S09pcmcia -> ../init.d/pcmcia

S10network -> ../init.d/network

S12syslog -> ../init.d/syslog

S13irqbalance -> ../init.d/irqbalance

S13portmap -> ../init.d/portmap

S14nfslock -> ../init.d/nfslock

S15mdmonitor -> ../init.d/mdmonitor

S18rpcgssd -> ../init.d/rpcgssd

S19rpcidmapd -> ../init.d/rpcidmapd

S19rpcsvcgssd -> ../init.d/rpcsvcgssd

S25netfs -> ../init.d/netfs

S26apmd -> ../init.d/apmd

S26lm_sensors -> ../init.d/lm_sensors

S28autofs -> ../init.d/autofs

S33nifd -> ../init.d/nifd

S34mDNSResponder -> ../init.d/mDNSResponder

S40smartd -> ../init.d/smartd

S44acpid -> ../init.d/acpid

S55cups -> ../init.d/cups

S55sshd -> ../init.d/sshd

S56xinetd -> ../init.d/xinetd

S80sendmail -> ../init.d/sendmail

S85gpm -> ../init.d/gpm

S90crond -> ../init.d/crond

S90xfs -> ../init.d/xfs

S95anacron -> ../init.d/anacron

S95atd -> ../init.d/atd

S96readahead -> ../init.d/readahead

S97messagebus -> ../init.d/messagebus

Listing 6-1 (continued)

11_599496 ch06.qxd 8/30/05 6:21 PM Page 135

System Startup and Shutdown 135

S97rhnsd -> ../init.d/rhnsd

S98cups-config-daemon -> ../init.d/cups-config-daemon

S98haldaemon -> ../init.d/haldaemon

S99local -> ../rc.local

Listing 6-1 (continued)

All of the scripts in the rc5.d directory are symbolic links to the actual scripts that are located in the /etc/rc.d/init.d/ directory. The use of symbolic links means that the runlevels can be modified by adding or removing symlinks or changing the order the scripts run in the rc0.d through rc6.d

directories without affecting the scripts to which they are linked.

T I P

A symbolic link is a type of file that points to another file in the file system.

As you can see, each symbolic link begins with a K and a number or an S and a number. The K links are processes that are killed on that runlevel, and those beginning with an S are started. All of the processes beginning with K are stopped first and then all the processes beginning with S are started. The processes are stopped or started in numerical order, beginning with the lowest number and continuing in increasing order. Processes are stopped by the /etc/rc.d/init.d/ process stop command, and started by /etc/rc.d/init.d/ process start. If you desire, you can change the stop and start order by changing the numbers in the symbolic links.

T I P

You can stop, start, or restart processes on your system by running the command for the process and then typing stop, start, or restart after the

command. For example, the command /etc/rc.d/init.d/vstpd stop stops

the vsftp server.

The init program has a few more tasks it needs to do before it is finished.

One of these tasks is running the gettys specified in the /etc/inittab file.

This provides the six terminals you can use to login to your server. These terminals are in addition to the standard login screen that is provided by the runlevel 5 login scripts. The last thing the init program does is run the

/etc/rc.d/rc.local

script. If you want to run any of your own scripts, you can put the calls to them in this file. See the section titled “Starting Programs at System Boot” later in this chapter for more information. Since the system is starting in runlevel 5, you will see a graphical login prompt.

11_599496 ch06.qxd 8/30/05 6:21 PM Page 136

136 Chapter 6

Exploring Runlevels

The term runlevel has been used a few times so far in this chapter and now is a good time to learn more about runlevels and why they are used. There are typically eight runlevels on Linux systems, but we are only interested in the seven used on Fedora Core or Enterprise Linux systems. Each of the runlevels has a set of processes associated with that runlevel that will be started by entering that runlevel. The runlevels on a Fedora Core or Enterprise Linux system and their purpose are:

■■

■■

0

— Halt

1

— Single-user mode

■■

■■

2

— Not used (user-definable)

3

— Full multiuser mode (without a graphical user interface, GUI)

■■

■■

4 — Not used (user-definable)

5

— Full multiuser mode (with a GUI)

■■

6

— Reboot

The /etc/inittab file controls the default runlevel for the system to use when it boots. You can easily change the runlevel for your system by making the following change.

Changing the System Runlevel

Look for the following line in the /etc/inittab file. It will be just below the listing of available runlevels.

id:5:initdefault:

The number 5 in the line means the system will boot into runlevel 5. If you want to boot into runlevel 3, just change the number 5 to a number 3, so the line now looks like this.

id:3:initdefault:

The default runlevel on Fedora Core and Enterprise Linux systems is runlevel 5, which provides a full multiuser environment and starts the X Window system to give the users a graphical environment. Runlevel 3 provides a full multiuser system exactly the same as runlevel 5, with the exception of not providing graphical environment for the users. Runlevel 3 is typically used for server systems that don’t require a GUI, because running a GUI uses a lot of system resources unnecessarily.

11_599496 ch06.qxd 8/30/05 6:21 PM Page 137

System Startup and Shutdown 137

Runlevels 2 and 4 are not used in Fedora Core or Enterprise Linux systems.

These runlevels are there so that the user can use them to configure them as they desire. By doing this, you can make your own custom runlevels for testing or whatever suits your purposes.

Runlevel 1 lets you enter single-user mode. This runlevel is useful for troubleshooting or running diagnostics on your system, but it isn’t usually set as a default runlevel in the /etc/inittab file. If you are having problems with your system, you would usually enter runlevel 1 by entering the command during system boot, as shown here:

1. When the boot screen appears, highlight the kernel you want to change by using the down-arrow key.

2. Press the letter e.

3. Scroll to the second line and press e again.

4. At the end of the line type init 1 and press Enter.

5. Press the letter b to boot the system into single-user mode.

Starting Programs at System Boot

The file /etc/rc.d/rc.local script is the last file run by the init command when the system boots. If you want to run additional scripts to configure other devices, you can place the commands for the script into this file.

Listing 6-2 shows a typical /etc/rc.d/rc.local file with a call to another script called /usr/bin/novellconfig. The novellconfig script is used to load the modules and configure IPX on the server. You can also pass options to your scripts by entering them after the call to the script.

N OT E

The script novellconfig is just used as an example and does not

actually exist on a default installation. You can create your own scripts and call them whatever you want.

#!/bin/sh

#

# This script will be executed *after* all the other init scripts.

# You can put your own initialization stuff in here if you don’t

# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local

/usr/bin/novellconfig

Listing 6-2 An /etc/rc.d/rc.local file calling another program.

11_599496 ch06.qxd 8/30/05 6:21 PM Page 138

138 Chapter 6

Shutting Down the System

If you are running a GUI on your system, shutting down your system is as easy as a few mouse clicks. The shutdown procedure for the GNOME desktop is as follows:

1. Choose Actions ➪ Logout from the top panel menu. A screen appears asking if you want to logout, restart or shutdown.

2. Click the shutdown radio button.

3. Click OK, and your system begins to shut down.

If you are not running a GUI on your system, the command to shut down is shutdown and uses the following syntax:

/sbin/shutdown [-t sec.] [-arkhncfF] time [warning message]

You can refer to the man page for shutdown to get all the details for the shutdown command. To access the man page for shutdown, type the following command: man shutdown

Regardless of the method used to start the shutdown command, the process that follows is the same. Any users who are logged in to the system will receive a notice that the system is going down and anyone trying to log in after the shutdown command has been given will not be allowed to do so. Running processes on the system are sent the SIGTERM signal, which will attempt to cleanly stop the running processes. The shutdown program signals the init program to change to a different runlevel depending on the shutdown command. Runlevel 0 is used to shut down the system, whereas runlevel 6 is used reboot the system. Some examples of commonly used shutdown commands with explanations of their meanings are:

N OT E

In most cases, only the root user can use shutdown to shut down the

system.

The /sbin/shutdown -h now command immediately begins the shutdown process and halts the system. The /sbin/shutdown -r now command immediately begins the shutdown process and reboots the system.

11_599496 ch06.qxd 8/30/05 6:21 PM Page 139

System Startup and Shutdown 139

GRUB Configuration File

When the system boots, GRUB presents a graphical screen showing the operating systems that you can boot. The /boot/grub/grub.conf file controls what information is displayed on the graphical screen. This file even controls whether you see the graphical screen at all. Listing 6-3 shows a typical GRUB configuration file. An explanation of the items in the file follows the listing.

# grub.conf generated by anaconda

#

# Note that you do not have to rerun grub after making changes to this file

# NOTICE:You have a /boot partition. This means that

# all kernel and initrd paths are relative to /boot/, eg.

# root (hd0,0)

# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00

# initrd /initrd-version.img

#boot=/dev/hda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz

hiddenmenu title Fedora Core (2.6.9-1.667) root (hd0,0) kernel /vmlinuz-2.6.9-1.667 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.9-1.667.img

Listing 6-3 The /boot/grub/grub.conf GRUB configuration file.

All lines beginning with a # (hash character) are comments and will be ignored. GRUB also ignores blank lines.

The lines following the lines beginning with the hash character and before the line beginning with title are the menu interface commands that GRUB uses to display the menu. These lines have the following meanings:

■■

default=0

— This command tells GRUB to boot the first listing beginning with title. If you had two entries beginning with title, you could set this number to 1 to boot the second entry.

■■

timeout=5

— This command tells GRUB to boot the default entry after five seconds. To change the time, increase or decrease the number as desired.

■■

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

— This command tells

GRUB where to look for the splash image it displays for the menu. You can create you own images if you desire. Just be sure to follow the same format as shown here.

11_599496 ch06.qxd 8/30/05 6:21 PM Page 140

140 Chapter 6

■■

hiddenmenu

— This command tells GRUB not to display the menu and to boot the default after the timeout expires. You can still see the menu by pressing any key.

■■

title

— This command tells GRUB to list a boot name on the menu using the name following the title command. In this example the title is

Fedora Core (2.6.9-1.667)

, which is the name of the operating system and the kernel version number.

The lines following the title are explained here:

■■

root (hd0,0)

— This line tells GRUB to boot the system from the first partition of the first hard drive.

■■

kernel...

— This line tells GRUB the location of the kernel, as well as passes kernel parameters to the kernel. All locations are relative to the boot partition, so the listing here indicates that the kernel is in the root of the boot partition. If you want to pass kernel parameters to the kernel before it loads, this is the line to add them to. There are already two options shown here. The rhgb on the kernel line tells the system to use a graphical boot. Finally, the quiet option tells the system not to display detailed information about system booting.

■■

initrd...

— This line tells GRUB the location of the initial ramdisk image that is used to load special drivers for the system. All locations are relative to the boot partition, so the listing here indicates that the initial ramdisk image is in the root of the boot partition.

Summary

In this chapter, you learned about the procedure Fedora Core and Red Hat

Enterprise Linux uses to start and stop the system. Each step of the boot process was explained in the order in which it occurs, and the programs that run at each step were listed. In addition, you learned about boot loaders and their significance in starting the system. The GRUB boot loader was explained in detail to give you a better understanding of how it works. The role of the init process and runlevels in the system were also explained. You took a look at the

GRUB configuration file to learn how it works. Finally, you learned how to gracefully bring the system down using the shutdown command.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 141

C H A P T E R

7

The File System

Explained

IN THIS CHAPTER

■■

■■

■■

■■

Understanding the File System Structure

Working with Linux-Supported File Systems

Memory and Virtual File Systems

Linux Disk Management

This chapter begins with a description of the file system structure and an explanation of the directories and the files they contain. Following the look at the file system structure are the file system commands, essential to proper file system management. In addition to the native Linux file system, Fedora Core and Red Hat Enterprise Linux support many other file system types. This chapter explains the other file system types and ends with a discussion of

Linux disk management.

Understanding the File System Structure

Understanding the organization, or layout, of the file system is one of the most important aspects of system administration. For administrators, programmers, users, and installed software, knowing how and where the files are stored on the system is critical for proper system operation. A standard should be in place that specifies locations for specific types of data. Fortunately, Red

Hat has chosen to follow the standards outlined in the Filesystem Hierarchy

Standard (FHS). This section briefly explains the FHS and its relevance to proper system administration. For the complete standard, refer to pathname.

com/fhs

.

141

12_599496 ch07.qxd 8/30/05 6:45 PM Page 142

142 Chapter 7

The FHS provides specific requirements for the placement of files in the directory structure. Placement is based on the type of information contained in the file. Two categories of file information exist: shareable or unshareable, and variable or static. Shareable files are files that can be accessed by other hosts, and unshareable files can be accessed only by the local system. Variable files contain information that can change at any time on their own, without anyone actually changing the file. A log file is an example of such a file. A static file contains information that does not change unless a user changes it. Program documentation and binary files are examples of static files. Figure 7-1 shows the organization of the file system on a typical Fedora Core and Red Hat Enterprise Linux system. Following the figure is an explanation of each directory and the types of files it may contain.

As shown in the illustration, the file system is organized in a flat, hierarchical file system. Linux’s method of mounting its file systems in a flat, logical, hierarchical method has advantages over the file system mounting method used by Windows. Linux references everything relative to the root file system point /, whereas Windows has a different root mount point for every drive.

If you have a / partition that fills up in Linux, you can create another file system called /usr/local and move your data from /usr/local in the original file system to the new file system definition. This practice frees up space on the

/ partition, and is an easy way to bring your system back up to a fully functional state.

Figure 7-1 The file system organization for a typical Fedora and

Red Hat Enterprise Linux system.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 143

The File System Explained 143

This trick wouldn’t work on a Windows machine, because Windows maps its file locations to static device disk definitions. You would have to change programs’ file references from c:\ to d:\, and so forth. Linux’s file system management is another good reason to use Linux on your production servers instead of Windows.

The / Directory

The / directory is called the root directory and is at the top of the file system structure. In many systems, the / directory is the only partition on the system, and all other directories are mounted under it. Figure 7-1 shows a file system with the / directory mounted as the only partition, with all other directories contained within it. The primary purpose of the / directory is booting the system and correcting any problems that might be preventing the system from booting. According to the FHS, the / directory must contain, or have links to, the following directories:

■■

bin

— This directory contains command files for use by the system administrator or other users. The bin directory cannot contain subdirectories.

■■

boot

— On Red Hat systems, this is the directory containing the kernel, the core of the operating system. Also in this directory are files related to booting the system, such as the boot loader and the initial ramdisk.

■■

dev

— This directory contains device nodes through which the operating system can access hardware and software devices on the system.

■■

etc

— This directory and its subdirectories contain most of the system configuration files. If you have the X Window System installed on your system, the X11 subdirectory is located here. Networking and systemrelated files are in the subdirectory sysconfig. Another subdirectory of etc is the skel directory, which holds files used as templates used to create files in users’ home directories when the users are created.

■■

home

— This directory contains the directories of users on the system.

Subdirectories of home will be named for the user to whom they belong.

■■

initrd

— This directory is used as a mount point when the system is booting. It doesn’t contain any data, but it is very important that it be there. This directory is not part of the FHS.

■■

lib

— The shared system files and kernel modules are contained in this directory and its subdirectories.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 144

144 Chapter 7

■■

media

— This directory contains the mount points for removable media such as floppy drives, CD-ROM drives, and USB devices such as flash memory sticks, which are typically automounted by the system.

■■

■■

■■

mnt

— This directory is the location of the mount point for temporary file systems, such as those on floppies or CDs, which traditionally have been manually mounted.

opt

— This directory and its subdirectories are often used to hold applications installed on the system.

proc

— This directory is a mount point for virtual information about currently running system processes. This directory is empty until the proc file system is mounted.

■■

root

— This is the home directory of the root user. Don’t confuse this with the / directory, which has the same name.

■■

sbin

— Contained in this directory are system binaries used by the system administrator or the root user.

■■

■■

■■

■■

selinux

— This directory is similar to the /proc directory in that it contains information about the selinux stored in the memory of the running kernel.

srv

— This directory is intended to hold site-specific data for system provided services.

sys

— This directory is the mount point for a virtual file system of type sysfs that is used to hold information about the system and devices.

tmp

— This directory contains temporary files used by the system.

■■

■■

usr

— This directory is often mounted on its own partition. It contains shareable, read-only data. Subdirectories can be used for applications, typically under /usr/local.

var

— Subdirectories and files under var contain variable information, such as system logs and print queues.

C A U T I O N

Never remove the /initrd/ directory. The system will not boot,

and you will see a kernel panic error message.

Working with Linux-Supported File Systems

Linux is a very flexible operating system that has a long history of interoperability with other systems on a number of different hardware platforms. A

12_599496 ch07.qxd 8/30/05 6:45 PM Page 145

The File System Explained 145

consequence of this friendliness to other operating systems is that Linux can read and write to several different file systems that originated with other operating systems much different from Linux. This section details the different file systems supported and where they originated.

One reason that Linux supports so many file systems is the design of its Virtual File Systems (VFS) layer. The VFS layer is a data abstraction layer between the kernel and the programs in userspace that issue file system commands.

N OT E

Programs that run inside the kernel are in kernelspace. Programs that don’t run inside the kernel are in userspace.

The VFS layer avoids duplication of common code between all file systems.

It provides a fairly universal backward compatible method for programs to access all of the different forms of file support. Only one common, small API set accesses each of the file system types, to simplify programming file system support.

Support for these file systems comes standard in Red Hat Enterprise Linux.

They are compiled into the kernel by default. If for some reason your kernel does not currently support these file systems, a kernel recompile with the proper options turned on should enable you to access all these file systems.

ext3

The extended 3 file system is a new file system introduced in Red Hat 7.2.

ext3 provides all the features of ext2, and also features journaling and backward compatibility with ext2. The backward compatibility enables you to still run kernels that are only ext2-aware with ext3 partitions. You can also use all of the ext2 file system tuning, repair, and recovery tools with ext3.

You can upgrade an ext2 file system to an ext3 file system without losing any of your data. This upgrade can be done during an update to the operating system.

ext3 support comes in kernels provided with the latest Fedora and Red Hat distributions. If you download a kernel from somewhere else, you need to patch the kernel to make it ext3 aware, with the kernel patches that come from the Red Hat FTP site. It is much easier to just stick with kernels from Red Hat.

ext3

’s journaling feature speeds up the amount of time it takes to bring the file system back to a sane state if it’s not been cleanly unmounted (that is, in the event of a power outage or a system crash).

Under ext2, when a file system is uncleanly mounted, the whole file system must be checked. This takes a long time on large file systems. On an ext3 system, the system keeps a record of uncommitted file transactions and applies only those transactions when the system is brought back up. So, a complete file system check is not required, and the system will come back up much faster.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 146

146 Chapter 7

A cleanly unmounted ext3 file system can be mounted and used as an ext2 file system. This capability can come in handy if you need to revert to an older kernel that is not aware of ext3. The kernel sees the ext3 file system as an ext2 file system.

ext3

’s journaling feature involves a small performance hit to maintain the file system transaction journal. Therefore, it’s recommended that you use ext3 mostly for your larger file systems, where the ext3 journaling performance hit is made up for in time saved by not having to run fsck on a huge ext2 file system.

ext2

ext2 was the standard file system for Linux until the introduction of ext3.

The ext2 implementation has not changed much since it was introduced with the 1.0 kernel back in 1993. Since then, a few new features have been added.

One of these was sparse super blocks, which increase file system performance.

ext2 was designed to make it easier for new features to be added, so that it can constantly evolve into a better file system. Users can take advantage of new features without reformatting their old ext2 file systems. ext2 has the added bonus of being designed to be POSIX-compliant. New features that are still in the development phase are access control lists, undelete, and on-the-fly compression.

ext2 is flexible, can handle file systems up to 4 TB, and supports long filenames up to 1012 characters. In case user processes fill up a file system, ext2 normally reserves about 5 percent of disk blocks for exclusive use by root so that root can easily recover from that situation. Modern Red Hat boot and rescue diskettes now use ext2 instead of minix.

reiserfs

The Reiser file system is a journaling file system designed for fast server performance, especially in directories containing thousands of files. It is more space efficient than most other file systems, because it does not take up a minimum of one block per file. If you write a bunch of really small files to disk, reiserfs squeezes them all into one block instead of writing one small file to one block like other file systems do. reiserfs also does not have fixed space allocation for inodes, which saves about 6 percent of your disk space.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 147

The File System Explained 147

SystemV

Linux currently provides read support for SystemV partitions, and write support is experimental. The SystemV file system driver currently supports

AFS/EAFS/EFS, Coherent FS, SystemV/386 FS, Version 7 FS, and Xenix file systems.

ufs

ufs is used in Solaris and early BSD operating systems. Linux provides read support, and write support is experimental.

FAT

FAT is one of a few different file systems used with Windows over the years.

Almost every computer user has used FAT at one time or another, since it was the sparse base operating system at the heart of all Windows operating systems.

FAT was originally created for QDOS and used on 360K (double density, double-sided) floppy disks. Its address space has since been extended from 12 bit to 32 bit, so it can handle very large file systems. There have been four versions of FAT since its beginnings: FAT12, FAT16, VFAT, and FAT32. Nowadays, it’s possible to create FAT32 file systems over a terabyte in size.

N OT E

Do not confuse a FAT file system with a FAT32 file system. They are named similarly but are two different beasts!

NTFS

NTFS is the next generation of HPFS. It comes with all versions of Microsoft operating systems beginning with Windows NT. Unlike FAT, it is a b-tree file system, meaning it has a performance and reliability advantage, including journaling, and support for encryption and compression, over FAT.

IBM JFS

IBM JFS is an easy-to-use journaling file system created by IBM. It is designed for high-throughput server environments. This is the same file system that will be provided in AIX version 5.1. Linux support for JFS was written by IBM. IBM has contributed quite a bit of code to the Linux cause and is a staunch supporter of Linux. It has also decided to make Linux its main server file system in the future.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 148

148 Chapter 7

SGI XFS

SGI’s Extended File System (XFS) is SGI’s newest file system for all Silicon

Graphics systems, from workstations to its supercomputer line (before it sold that line to Terra computers.) It has been available for use on Linux since

May 2001.

XFS is designed for high performance. It rapidly recovers from system crashes and can support extremely large disk farms (it can handle files as large as a million terabytes.) It is one of a few journaling file systems that have had a proven track record in production environments for several years now.

N OT E

Its other features include access control lists, volume management, guaranteed rate I/O, and journaling for faster recovery. XFS can be backed up while still in use, which comes in handy since it reduces system administration time. This is a fast file system, and now you can read and write to and from it with your Red Hat Linux machine.

Nonstandard Linux File Systems

Support for these file systems needs to be explicitly compiled into the Linux kernel, since kernel support for them is not configured by default.

FREEVxFS

VxFS is the Veritas file system developed by the Veritas Corporation. It is used in SCO UnixWare, HP-UX, Solaris, and other systems. Some of its features include access control lists, journaling, online backup, and support for files up to 2 TB.

Three different versions of VxFS are in use. Version 1 is the original VxFS, which is not commonly used anymore. Version 2 includes support for filesets and dynamic inode allocation. Version 4 is the latest version, and it supports quotas and large files.

GNU utilities available for Linux called VxTools can read VxFS versions 2 and 4. The tools included in the VxTools package are vxmount, vxumount, vxls

, vxcat, vxidump, vxcd, and vxpwd. Currently there is only read support in Linux for VxFS file systems.

GFS

GFS is Sistina’s Global File System. It is a clustered journaling file system for

SANs that enables multiple servers to have read/write access to a single file system on shared SAN devices.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 149

The File System Explained 149

GFS is scalable, since storage devices and servers can be added without taking the system down or taking the disks offline. It also makes a single image of all the data in the SAN, so that if a server fails it can be removed and replaced while the load is rebalanced amongst the remaining servers.

In a proper cluster setup, all nodes in the cluster share the same storage devices through a fiber channel, SCSI hookup, or network block device. Each node sees the file system as being local to their machine, and GFS synchronizes files across the cluster. GFS is fully symmetric, so no server is a bottleneck or single point of failure. GFS uses regular UNIX-style file semantics.

Memory and Virtual File Systems

These file systems do not exist on disk in the same way that traditional file systems do. They either exist entirely in system memory or they are virtual, because they are an interface to system devices, for example.

cramfs

cramfs is designed to cram a file system onto a small flash memory device, so it is small, simple, and able to compress things well. The largest file size is 16

MB, and the largest file system size is 256 MB.

Since cramfs is so compressed, it isn’t instantly updateable. The mkcramfs tool needs to be run to create or update a cramfs disk image. The image is created by compressing files one page at a time, so this enables random page access. The metadata is not compressed, but it has been optimized to take up much less space than other file systems. For example, only the low 8 bits of the

GID are stored. This saves space but also presents a potential security issue.

tmpfs

tmpfs is structured around the idea that whatever is put in the /tmp file system is accessed again shortly. tmpfs exists solely in memory, so what you put in /tmp doesn’t persist between reboots.

Mounting a special-purpose file system on /tmp as an in-memory file system is a performance boost but is rarely done in Linux because of the performance available from the traditional Linux file system. But for those who feel that they need the performance gains from storing /tmp in memory, this option is now available in Linux.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 150

150 Chapter 7

ramfs

ramfs is basically cramfs without the compression.

romfs

This is a read-only file system that is mostly used for the initial ramdisks of installation disks. It was designed to take up very little space, so you could fit a kernel and some useful code into a small boot disk, without having the file system overhead taking up too much precious space in memory or on the disk.

The kernel on the disk has only this file system linked into it, and it can load any modules it needs later, after bootup. After the kernel is loaded, it can call other programs to help determine what SCSI drivers are needed, if any, or what IDE or floppy drives should be accessed after bootup. This method is perfect for rescue diskettes or installation diskettes, where only a very bare minimum kernel needs to be loaded into memory, so after the initial boot it can then load from a CD-ROM whatever ext2 modules or other drivers are necessary to mount the system’s regular drives.

The romfs file system is created with a program called genromfs.

proc

proc is a virtual file system that acts as an interface to the kernel’s internal data structures. proc can be used to get detailed information about a system’s hardware and to change kernel parameters at runtime. Even the process listing command, ps, gets its information from the proc file system. The kernel parameters can be changed with the sysctl command.

Proc Software Information

The /proc directory contains a great deal of information about your currently running system software. If you look at the /proc directory on Linux, you see one subdirectory for each process running on the system. The subdirectories are named after the process’s ID (PID) number. Each of those subdirectories has several standard files, and each of them gives you a different set of information.

The status file in those proc directories contains process status in humanreadable format. So, if you want to see the status of your ssh server, you first need to know the ssh server’s PID number. You can find this number in a few different ways. One easy way is to look at a process listing and grep for the string ssh. The output should look like the lines shown in Listing 7-1.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 151

The File System Explained 151

[[email protected] terry]$ ps -elf | grep ssh

140 S root 933 1 0 69 0 - 664 do_sel Oct23 ? 00:00:01

/usr/sbin/sshd

140 S root 14807 933 0 69 0 - 882 do_sel 18:36 ? 00:00:00

/usr/sbin/sshd

000 S vnavrat 14883 14808 0 71 0 - 434 pipe_w 18:52 pts/10 00:00:00 grep ssh

Listing 7-1 Finding the process ID (PID) number.

The process table contains multiple hits for ssh, since there is a master sshd process, and one sshd process is spawned for each ssh session currently open.

The first line is the master sshd server process. You can tell because its parent process ID is 1, also known as the init process that spawns all processes at boot time, and is responsible for respawning important server processes that die during runtime. The second line is an ssh daemon handling an incoming ssh connection, evident because it lists the previous ssh process as its parent. The final line lists the grep process that you just ran, so you can disregard that line.

You should look at the status of the master ssh daemon, which, as you saw previously, is running with a PID of 933. So, cd to the /proc/933 directory, and take a look at the status file in that directory. The output appears in Listing 7-2.

[[email protected] terry]$ less /proc/933/status

Name: sshd

State: S (sleeping)

Pid: 933

PPid: 1

TracerPid: 0

Uid: 0 0 0 0

Gid: 0 0 0 0

FDSize: 32

Groups:

VmSize: 2656 kB

VmLck: 0 kB

VmRSS: 1236 kB

VmData: 116 kB

VmStk: 16 kB

VmExe: 240 kB

VmLib: 2176 kB

SigPnd: 0000000000000000

SigBlk: 0000000000000000

SigIgn: 8000000000001000

SigCgt: 0000000000016005

CapInh: 0000000000000000

CapPrm: 00000000fffffeff

CapEff: 00000000fffffeff

Listing 7-2 Viewing the status information of a running process.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 152

152 Chapter 7

Other useful files in the /proc/PID directory and their contents are:

■■

■■

■■

cmdline

— Contains the process’s command line arguments

cpu

— Contains the current and last CPU on which the process was executed

cwd

— Contains a link to the process’s current working directory

■■

■■

environ

— Contains values of the process’s environmental variables

exe

— Contains a link to the process’s executable

■■

■■

■■

fd

— A directory that contains all the process’s file descriptors

maps

— Contains memory maps to the process’s executables and library files

mem

— Contains the memory held by this process

■■

■■

root

— Contains a link to the root directory of the process

stat

— Contains the process status

■■

■■

statm

— Contains the process memory status information

status

— Contains the process status in human-readable format

Proc Hardware Information

As mentioned previously, the /proc directory also contains some useful hardware information. This information comes in handy when you compile a new kernel. If you’ve forgotten the specific details about your hardware, you can look through the files in the /proc directory to get information about what’s installed and running on your Linux machine.

If you suspect that you’re having hardware problems due to an interrupt request (IRQ) conflict, you can also see your hardware’s interrupts by looking at the /proc/interrupts file.

The interrupts file from my desktop machine at work is shown below. Each number corresponds to an IRQ. The acronyms at the end of the IRQ listing are

NMI (Non-Maskable Interrupt), LOC (local interrupt counter of the internal

APIC of each CPU), and ERR. ERR is a counter that starts out at 0 at boot time and is incremented each time there is an error in the IO-APIC bus. The IO-

APIC bus connects the CPUs in an SMP system. When an error happens, the information is immediately retransmitted, so you shouldn’t worry too much about a moderate number of errors in this field. Listing 7-3 shows the

/proc/interrupts information.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 153

The File System Explained 153

[[email protected] terry]$ less /proc/interrupts

CPU0

0: 9720704 XT-PIC timer

1: 30515 XT-PIC keyboard

2: 0 XT-PIC cascade

5: 9869566 XT-PIC Crystal audio controller

8: 1 XT-PIC rtc

11: 1233943 XT-PIC usb-uhci, eth0

12: 682220 XT-PIC PS/2 Mouse

14: 77739 XT-PIC ide0

15: 2694731 XT-PIC ide1

NMI: 0

LOC: 9720557

ERR: 0

MIS: 0

Listing 7-3 Viewing the /proc/interrupts information.

In the main /proc directory, quite a few files contain detailed information on your system hardware. The kind of details listed are things such as what hardware it is, the model, and the manufacturer.

Listing 7-4 shows the contents of the cpuinfo file in proc. This tells you what kind of processor you have, and most importantly, how fast it is.

[[email protected] terry]$ less /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : AMD Athlon(tm) XP 1800+ stepping : 2 cpu MHz : 1535.822

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 pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 3022.84

Listing 7-4 Viewing the contents of the /proc/cpuinfo file.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 154

154 Chapter 7

Some important /proc files are:

■■

■■

/proc/cpuinfo

— Contains info about the CPU

/proc/interrupts

— Tells you what interrupts are in use

■■

/proc/scsi

— A directory that contains information about SCSI devices

■■

/proc/parport

— Contains info about the parallel ports on your system

■■

/proc/tty

— A directory that contains info about ttys that are available and in use

■■

■■

/proc/acpi

— Contains power management information

/proc/bus

— A directory that contains bus-specific information

■■

■■

/proc/devices

— Lists available character and block devices

/proc/dma

— Lists used DMS channels

■■

■■

/proc/filesystems

— Lists supported file systems

/proc/fs

— A directory that contains file system parameters

■■

/proc/ide

— A directory that contains information about the IDE subsystem

■■

■■

/proc/ioports

— Contains information about system I/O port usage

/proc/modules

— Contains a list of currently loaded modules

■■

■■

/proc/net

— Contains networking information

/proc/uptime

— Contains the system uptime

■■

/proc/version

— Contains the system version

/dev/pts

/dev/pts is a lightweight version of devfs. Instead of having all the device files supported in the virtual file system, it provides support for only virtual pseudoterminal device files. /dev/pts was implemented before devfs.

devfs

The Device File System (devfs) is another way to access “real” character and block special devices on your root file system. The old way used major and minor numbers to register devices. devfs enables device drivers to register devices by name instead. devfs is deprecated in the 2.6 kernel in favor of udev.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 155

The File System Explained 155

sysfs

sysfs is a virtual file system that acts as an interface to the kernel’s internal data structures. Information is stored in the /sys directory and can be used to get details about a system’s hardware and to change kernel parameters at runtime. Information in the /sys directory is similar to the information provided in the /proc directory and can be accessed in a similar fashion.

Linux Disk Management

This section explains some basics about disk partitioning and disk management under Linux. To see how your Linux disks are currently partitioned and what file systems are on them, look at the /etc/fstab file.

In Figure 7-2, you can see what a simple /etc/fstab file looks like.

T I P

To see how your Linux disks are currently partitioned and what file

systems are on them, look at the /etc/fstab file. You could also use the fdisk -l

command to obtain partition information about your disks.

Figure 7-2 The contents of the /etc/fstab file.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 156

156 Chapter 7

Disk Partitioning on an x86 Machine

When disk partitioning on an x86 PC, you need to be mindful of the limitations present in the x86 architecture. You are allowed to create four primary partitions. Primary partitions are the only partitions that are bootable. You can create more partitions if you make extended partitions.

Extended partitions are set into a primary partition. So, if you choose to make extended partitions, you are allowed to make only three primary partitions for operating system use, and the fourth partition is dedicated to hosting the extended partitions.

Mounting Other OS Partitions/Slices

Not only can Linux read other operating systems’ file systems; it can mount disk drives from other systems and work with their partition tables. However, it is necessary to compile two options into the kernel to do this. You must have the file system support and the file partitioning support turned on in the kernel. Usually file system support is compiled as a module by default, but disk partition support usually has to be explicitly compiled.

Some common partitioning schemes that Linux supports are x86 partitions,

BSD disklabel, Solaris x86, Unixware, Alpha, OSF, SGI, and Sun.

Mounting other operating systems’ partitions is helpful if you need to put a

Sun hard disk into a Linux machine, for example. You may need to do this if the original Sun system has gone bad, and you need to recover the information that was on its disk, or if it’s the target of a forensic computer crime investigation, and you need to copy the disk contents to another machine to preserve evidence. This method takes advantage of the fact that copying a large amount of data is much faster across a SCSI connection than across a network.

If you need to copy a large amount of raw disk data across a network, you can use the Network Block Device, which enables other machines to mount a disk on your machine as if it were on their machine.

T I P

When running the Network Block Device, make sure that you have the appropriate partition support compiled into the kernel. For more information

about NBD refer to it.uc3m.es/~ptb/nbd.

Metadevices

Virtual block devices that are made up of other block devices are referred to in this book as a metadevice. An example of a metadevice is a disk array that makes many disks look like one large disk. When a disk that’s mounted as a

12_599496 ch07.qxd 8/30/05 6:45 PM Page 157

The File System Explained 157

regular block device dies, then the data on it becomes unavailable. If a disk dies in a metadevice, the metadevice is still up. As long as the criteria are met for the minimum number of working devices in the metadevice, the metadevice still functions.

Logical Volumes

Logical Volume Manager (LVM) enables you to be much more flexible with your disk usage than you can be with conventional old-style file partitions.

Normally if you create a partition, you have to keep the partition at that size indefinitely.

For example, if your system logs have grown immensely, and you’ve run out of room on your /var partition, increasing a partition size without LVM is a big pain. You would have to get another disk drive, create a /var mount point on there too, and copy all your data from the old /var to the new /var disk location. With LVM in place, you could add another disk, create a physical volume, and then add the physical volume to the volume group that contains the /var partition. Then you’d use the LVM file system resizing tool to increase the file system size to match the new partition size.

Normally, you might think of disk drives as independent entities, each containing some data space. When you use LVMs, you need a new way of thinking about disk space. First, you have to understand that space on any disk can be used by any file system. A Volume Group is the term used to describe various disk spaces (either whole disks or parts of disks) that have been grouped together into one volume.

The way it works is like this. First you need to have a physical volume which is then divided into Volume groups that are then combined to form logical volumes. Logical volumes are akin to the historic idea of partitions. You can then use a file system creation tool such as fdisk to create a file system on the logical volume. The Linux kernel sees a logical volume in the same way it sees a regular partition.

N OT E

When the system is installed, LVM is enabled by default and you will need to use the LVM tools described here to make changes to your logical volumes. You can, if you desire, choose not to use logical volumes during the system installation.

In Fedora Core and Enterprise Linux, LVM has been updated to LVM2. The basic syntax for using the lvm command is: lvm <command> file

12_599496 ch07.qxd 8/30/05 6:45 PM Page 158

158 Chapter 7

There are many commands available when using LVM. You can obtain a complete listing of the commands by entering lvm help at a command prompt. You will see the list shown in Listing 7-5.

dumpconfig Dump active configuration formats List available metadata formats help Display help for commands lvchange Change the attributes of logical volume(s) lvcreate Create a logical volume lvdisplay Display information about a logical volume lvextend Add space to a logical volume lvmdiskscan List devices that may be used as physical volumes lvmsadc Collect activity data lvmsar Create activity report lvreduce Reduce the size of a logical volume lvremove Remove logical volume(s) from the system lvrename Rename a logical volume lvresize Resize a logical volume lvs Display information about logical volumes lvscan List all logical volumes in all volume groups pvchange Change attributes of physical volume(s) pvcreate Initialize physical volume(s) for use by LVM pvdata Display the on-disk metadata for physical volume(s) pvdisplay Display various attributes of physical volume(s) pvmove Move extents from one physical volume to another pvremove Remove LVM label(s) from physical volume(s) pvresize Resize a physical volume in use by a volume group pvs Display information about physical volumes pvscan List all physical volumes segtypes List available segment types vgcfgbackup Backup volume group configuration(s) vgcfgrestore Restore volume group configuration vgchange Change volume group attributes vgck Check the consistency of volume group(s) vgconvert Change volume group metadata format vgcreate Create a volume group vgdisplay Display volume group information vgexport Unregister volume group(s) from the system vgextend Add physical volumes to a volume group vgimport Register exported volume group with system vgmerge Merge volume groups vgmknodes Create special volume group file devices in /dev vgreduce Remove physical volume(s) from a volume group vgremove Remove volume group(s) vgrename Rename a volume group vgs Display information about volume groups vgscan Search for all volume groups vgsplit Move physical volumes into a new volume group version Display software and driver version information

Listing 7-5 Output from the lvm help command.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 159

The File System Explained 159

You can get more detailed help about each command by entering lvm help and the name of the command for which you want help. For example, to find out more about the pvcreate command enter lvm help pvcreate at a terminal prompt to go to the pvcreate help page.

Let’s take a look at using a few of the commands. To get a listing of the physical volumes on the system enter lvm pvdisplay at a terminal prompt. You will see output similar to Listing 7-6.

--- Physical volume ---

PV Name /dev/hda2

VG Name VolGroup00

PV Size 9.41 GB / not usable 0

Allocatable yes

PE Size (KByte) 32768

Total PE 301

Free PE 1

Allocated PE 300

PV UUID mwGHdm-M7no-X118-D8kE-i5YS-btzV-w8Og1f

Listing 7-6 Using the pvdisplay command to get a listing of system physical volumes.

To get a list of the logical volumes on your system, enter lvm lvdisplay at a terminal prompt. You will see a listing similar to Listing 7-7.

--- Logical volume ---

LV Name /dev/VolGroup00/LogVol00

VG Name VolGroup00

LV UUID QAVcFn-Jrjy-7sAs-0zih-vyTk-SWqX-fVC1M6

LV Write Access read/write

LV Status available

# open 1

LV Size 9.00 GB

Current LE 288

Segments 1

Allocation inherit

Read ahead sectors 0

Block device 253:0

Listing 7-7 Using the lvm lvdisplay command to see the logical volumes on the system.

One last example: To get a listing of the volume groups on your system, enter lvm vgdisplay at a terminal prompt. You will see a listing similar to

Listing 7-8.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 160

160 Chapter 7

--- Volume group ---

VG Name VolGroup00

System ID

Format lvm2

Metadata Areas 1

Metadata Sequence No 3

VG Access read/write

VG Status resizable

MAX LV 0

Cur LV 2

Open LV 2

Max PV 0

Cur PV 1

Act PV 1

VG Size 9.41 GB

PE Size 32.00 MB

Total PE 301

Alloc PE / Size 300 / 9.38 GB

Free PE / Size 1 / 32.00 MB

VG UUID KKrG4a-HaUw-7Fpo-DyL5-sU8F-wFcq-nnGClQ

Listing 7-8 Using the vgdisplay command to see the volume groups on the system.

By now you should have a pretty good idea of the syntax to follow and how to use some of the commands when working with logical volumes.

RAID

RAID is an acronym for Redundant Array of Inexpensive, or Independent

(depending on who you ask), Disks. There are two types of RAID that can be used on computer systems. These types are hardware RAID and software

RAID. In addition, there are six different RAID levels commonly used regardless of whether hardware or software RAID is used. A brief explanation of hardware and software RAID is in order. Following this explanation is a description of the six RAID levels.

■■

Hardware Raid

— In hardware RAID the disks have their own RAID controller with built-in software that handles the RAID disk setup, and

I/O. The controller is typically a card in one of the system’s expansion slots, or it may be built onto the system board. The hard RAID interface is transparent to Linux, so the hardware RAID disk array looks like one giant disk. The operating system does not control the RAID level used, it is controlled by the hardware RAID controller. Most dedicated servers use a hardware RAID controller.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 161

The File System Explained 161

■■

Software RAID

— In software RAID there is no RAID controller card.

The operating system is used to set up a logical array, and the operating system controls the RAID level used by the system.

N OT E

Software RAID must be configured during system installation. Refer to

Chapter 3 for more details about configuring RAID on your system.

As mentioned earlier, there are six RAID levels that can be used, but in actual practice usually only three of them are used. And of these three one doesn’t provide redundancy even though it is identified as a RAID level. The three most commonly used RAID levels are:

■■

RAID level 0

— This RAID level requires at least two disks and uses a method called striping that writes data across both drives. There is no redundancy provided by this level of RAID, since the loss of either drive makes it impossible to recover the data. This level of RAID does give a speed increase in writing to the disks.

■■

RAID level 1

— This RAID level requires at least two disks and uses a method called mirroring. With mirroring, the data is written to both of the drives. So, each drive is an exact mirror of the other one, and if one fails the other still holds all the data. There are two variants to level 1 with one variant using a single disk controller that writes to both disks as described above. The other variant uses two disk controllers, one for each disk. This variant of RAID level 1 is known as duplexing.

■■

RAID level 5

— This RAID level, which is the most widely used, requires at least three disks and uses striping to write the data across the two disks similarly to RAID level 1. But unlike RAID level 1, this level of RAID uses the third disk to hold parity information that can be used to reconstruct the data from either, but not both, of the two disks after a single disk failure.

There are some system files that you can use to get information about RAID on your system. You can look in /etc/raidtab to get information about the system’s RAID configuration. RAID devices are identified in Fedora Core and

Enterprise Linux as md devices. The /etc/raidtab file lists which block devices are associated with the md device.

N OT E

The commands discussed here are only useful when using software

RAID. Hardware RAID is invisible to the operating system.

You can also look at the contents of the /proc/mdstat file to get information about the running status of your md devices.

12_599496 ch07.qxd 8/30/05 6:45 PM Page 162

162 Chapter 7

Also available to you are several command-line tools. You can use lsraid to list and query md devices as well. This command is similar to the ls command and more information is available by reading the lsraid man page.

You can also use the man command with the following RAID commands:

■■

raidstart

— This command will start an existing RAID device.

■■

■■

raidstop

— This command will stop an existing RAID device.

raidreconf

— This command is used to add disks to an existing array or to convert an array to a new type.

Summary

In this chapter you learned how Fedora Core and Enterprise Linux provide support for many file systems. Linux supports those from other operating systems, remote file systems, memory file systems, CD-ROM file systems, virtual file systems, and metadevice file systems. This makes Linux very good at managing and accessing any file or file systems that you may ever come across in a multiplatform environment.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 163

C H A P T E R

8

Examining the System

Configuration Files

IN THIS CHAPTER

■■

■■

■■

■■

Examining the System Configuration Files

Examining the /etc/sysconfig/ Directory

Examining the Network Configuration Files

Managing the init Scripts

This chapter describes the file system and configuration files in a typical

Fedora Core and Red Hat Enterprise Linux server.

The system configuration files in the /etc directory are the first places a system administrator goes after installing a system to set it up. The /etc directory is probably the most often visited directory by a system administrator after his or her own home directory and /var/log.

All of the systemwide important configuration files are found either in

/etc or in one of its many subdirectories. An advantage to keeping all system configuration files under /etc is that it’s easier to restore configurations for individual programs, as opposed to having all the system’s configurations rolled up into a monstrous registry hive as some operating systems do.

C A U T I O N

Be vigilant that your files in /etc are modifiable only by

appropriate users. Generally, this means being modifiable only by root.

Because these files are so important and their contents so sensitive (everything from users’ hashed passwords to the host’s SSH key are stored in /etc), it is important to keep the file permissions set properly on everything in /etc.

Almost all files should be owned by root, and nothing should be world-writable.

163

13_599496 ch08.qxd 8/30/05 6:37 PM Page 164

164 Chapter 8

Most files should have their file permissions set to user readable and writable, and group and world readable, like this:

-rw-r--r-- 1 root root 172 Aug 6 02:03 hosts

Some notable exceptions are files such as /etc/shadow, where users’ hashed passwords are stored, and /etc/wvdial.conf, which stores dial-up account names and passwords. These files’ permissions should be set to owned by root, and read by root only, like this:

-rw------- 1 root root 1227 Sep 2 13:52 /etc/shadow

The /etc/sysconfig directory contains configuration scripts written and configured by Red Hat and Red Hat administration tools as well as files containing variable settings used by system startup scripts. /etc/sysconfig contains both system and networking configuration files. Putting these files in

/etc/sysconfig distinguishes them from other /etc configuration files not designed by Red Hat. You should keep these files in a separate directory so that the risk of other developers writing configuration files with the same names and putting them in the same place as existing configuration files is reduced.

Examining the System Configuration Files

The Red Hat system configuration files can fall within a few different functions. Some specify system duties, such as logging and automatically running programs with cron. Some set default configurations for important programs such as Sendmail and Bash. And many other system configuration files are responsible for arranging the appearance of the system, such as setting the colors that show up when a directory listing is shown and the banners that pop up when someone logs in. This section discusses the more important system configuration files on your Red Hat system.

Systemwide Shell Configuration Scripts

These files determine the default environment settings of system shells and what functions are started every time a user launches a new shell.

The files discussed next are located in /etc. These configuration files affect all shells used on the system. An individual user can also set up a default configuration file in his or her home directory that affects only his or her shells.

This ability is useful in case the user wants to add some extra directories to his or her path or some aliases that only he or she can use.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 165

Examining the System Configuration Files 165

When used in the home directory, the names are the same, except they have a . in front of them. So /etc/bashrc affects bash shells systemwide, but

/home/kelly/.bashrc

affects only the shells that the user kelly starts.

Shell Config Scripts: bashrc, csh.cshrc, zshrc

Bashrc is read by bash; csh.cshrc is read by tcsh; and zshrc is read by zsh

. These files are read every time a shell is launched, not just upon login, and they determine the settings and behaviors of the shells on the system. The following are places to put functions and aliases.

■■

profile

This file is read by all shells except tcsh and csh upon login. bash falls back to reading it if there is no bash_profile. Zsh looks for zprofile, but if there is none, it reads profile as well. Listing 8-1 shows a typical /etc/profile file.

# /etc/profile

# System wide environment and startup programs, for login setup

# Functions and aliases go in /etc/bashrc pathmunge () { if ! echo $PATH | /bin/egrep -q “(^|:)$1($|:)” ; then if [ “$2” = “after” ] ; then

PATH=$PATH:$1 else

PATH=$1:$PATH fi fi

}

# Path manipulation if [ `id -u` = 0 ]; then pathmunge /sbin pathmunge /usr/sbin pathmunge /usr/local/sbin fi pathmunge /usr/X11R6/bin after

# No core files by default ulimit -S -c 0 > /dev/null 2>&1

USER=”`id -un`”

LOGNAME=$USER

MAIL=”/var/spool/mail/$USER”

Listing 8-1 A typical /etc/profile file. (continued)

13_599496 ch08.qxd 8/30/05 6:37 PM Page 166

166 Chapter 8

HOSTNAME=`/bin/hostname`

HISTSIZE=1000 if [ -z “$INPUTRC” -a ! -f “$HOME/.inputrc” ]; then

INPUTRC=/etc/inputrc fi export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE INPUTRC for i in /etc/profile.d/*.sh ; do if [ -r “$i” ]; then

. $i done fi unset i unset pathmunge if [ $LD_LIBRARY_PATH ] then if ! set | grep LD_LIBRARY_PATH | grep /usr/X11R6/lib:/usr/X11R6/lib/modules >

/dev/null then

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/X11R6/lib:/usr/X11R6/lib/modules fi export LD_LIBRARY_PATH else

LD_LIBRARY_PATH=/usr/X11R6/lib:/usr/X11R6/lib/modules fi export LD_LIBRARY_PATH

Listing 8-1 (continued)

/etc/profile is a good place to set paths because it is where you set environmental variables that are passed to child processes in the shell. If you want to change the default path of your shells in /etc/profile, you can add another path statement in the path manipulation section of /etc/profile.

For example, suppose that you create a directory called /music on your system and you want this directory to be in the system search path. You could add the following line to the end of the other similar lines: pathmunge /music

Do not add too many paths to this section because users can set their own paths using a .profile in their home directories. Adding more default paths than are necessary can pose a security risk. For example, a user named katie may want to run her own version of pine, which she keeps in her home directory.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 167

Examining the System Configuration Files 167

In that case, she may want to have /home/$USER or /home/katie at the beginning of her path so that when she types pine, the version in her home directory is found by the shell first, before finding the copy of pine in

/usr/bin/pine

. Generally, putting /home/$USER or any other directory whose contents are not controlled by root in /etc/profile is not a good idea.

The reason for this warning is that a rogue user or cracker can compile a backdoor, a way to enter the system unexpectedly, or corrupted version of a program and somehow get it in a user’s home directory, perhaps even by mailing it to the user. If users’ paths are set to check their home directories first, they may think that they are running a system program but instead are unknowingly running an alternate version.

On the other hand, if this path modification is set only in katie’s .profile, only she runs this risk. She should also be aware of this risk since she has to perform the extra step of adding this path modification herself.

Another useful variable to change in the system profile is the number of user commands saved in the .history file in the user’s directory. This command history is especially useful, since you can scroll through your previous commands by using the up and down arrows. To change the number of commands saved in the .history file, modify this line:

HISTSIZE=1000

bash, tcsh, zsh, and Their Config File Read Orders

The shells read a few configuration files when starting up. It is good to know which files are read in what order, so that you know where to set variables that will only apply to certain users.

■■

bash

— bash reads the following files on startup: /etc/profile, all the files in /etc/profile.d ~/.bash_profile, ~/.bash_login, and ~/.profile. Upon logout, bash reads ~/.bash_logout.

■■

tcsh

— tcsh reads the following files when starting up: /etc/csh

.cshrc

, then /etc/csh.login. After these come the config files in the user’s home directory: ~/.tcshrc (or if not present, ~/.cshrc),

~/.history

, ~/.login, ~/.cshdirs.

■■

zsh

— zsh reads the following when starting up: /etc/zshenv,

~/.zshenv

, /etc/zprofile, ~/.zprofile, /etc/zshrc,

~/.zshrc

, and /etc/zlogin. Nonlogin shells also read ~/.bashrc.

Upon logout, zsh reads the ~/.zlogout and /etc zlogout files.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 168

168 Chapter 8

System Environmental Settings

The files discussed in this section deal with system environmental settings.

/etc/motd

This file contains the message that users see every time they log in. It’s a good place to communicate messages about system downtime and other things that users should be aware of. On the other hand, you can put amusing quotes here to entertain your users. Usually, the motd contains a message like:

Welcome to Generic University’s UNIX mail system.

This system is monitored. Unauthorized use prohibited.

System downtime scheduled this Sunday night from 10 pm to 1 am.

N OT E

motd

is a plain-text file, which you can edit with any text editor.You can use it to display any message you want users to see when they login. If you

don’t have this file in your /etc directory you can easily create it.

issue

Whatever is in this file shows up as a prelogin banner on your console. By default, this file tells which version of Red Hat is running on the system and the kernel version.

The default file looks like this:

Red Hat Linux release 7.2 (Enigma)

Kernel \r on an \m

So when you log in, you see this message (or something similar, depending on the kernel running on your system):

Fedora Core release 3 (Heidelberg)

Kernel 2.6.10-1.770_FC3 on an i686

issue.net

This file generally contains the same thing as /etc/issue. It shows up when you attempt to telnet into the system. Because it shows up to people who are connecting to your system over the Internet, you should change this message to include a warning such as “Access is being monitored. Unauthorized access

13_599496 ch08.qxd 8/30/05 6:37 PM Page 169

Examining the System Configuration Files 169

is prohibited.” Displaying this warning is good practice because if you want to prosecute intruders, it helps your case to show that you warned them that unauthorized access was prohibited.

aliases

/etc/aliases is the email aliases file for the Sendmail program, and Postfix uses /etc/postfix/aliases. By default, it contains many system account aliases. The aliases file sends mail for all the basic system accounts such as bin, daemon, and operator to root’s mailbox.

Other common email aliases, for example, send all of root’s mail to the user who commonly acts as root. So if taleen acts as root most of the time, she can alias root’s mailbox to her mailbox. This way, she doesn’t need to log in as root to read important system mail.

To do this, she’d put the following line in the aliases file: root: taleen

Or if she wants to send all root mail to her account on a remote machine, the line will read: root: [email protected]

Whenever you make changes to this file, you need to run the newaliases command to have the changes take affect in Sendmail.

fstab

fstab contains important information about your file systems, such as what file system type the partitions are, where they are located on the hard drive, and what mount point is used to access them.

This information is read by vital programs such as mount, umount, and fsck

. mount runs at start time and mounts all the file systems mentioned in the fstab file, except for those with noauto in their line. If a partition you want to access is not listed in this file, you have to mount it manually. This can get tedious, so it’s better to list all of your file systems in fstab.

When fsck is run at bootup, it also checks all the file systems listed in fstab for consistency. It then fixes corrupted file systems, usually because they were not unmounted properly when the system crashed or suddenly lost power. File systems with an fs_passno value of 0 (the number in the last column) are not checked at boot time. As you can see in Listing 8-2, almost all file systems are checked at startup except for the floppy drive, which is not checked by fsck at bootup.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 170

170 Chapter 8

The fstab line has six fields, and each field represents a different configuration value. The first field describes the file system, which can be a partition name, the label of a disk partition, a logical volume, or a remote file system.

The second field is the mount point used to access the file system. The third field describes the file system type. The fourth field is the place for any mount options you may need. The fifth field is 0 or 1 to determine whether dump backs up this file system. The final field sets the order in which fsck checks these file systems.

# This file is edited by fstab-sync - see ‘man fstab-sync’ for details

/dev/VolGroup00/LogVol00 / ext3 defaults 1 1

LABEL=/boot /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0

/dev/VolGroup00/LogVol01 swap swap defaults 0 0

/dev/hdc /media/cdrecorder auto pamconsole,exec,noauto,fscontext=system_u:object_r:removable_t,managed 0 0

Listing 8-2 A typical fstab file.

grub.conf

GRUB stands for the modest acronym Grand Unified Bootloader. It is the default boot loader used by Fedora Core and Red Hat Enterprise Linux. GRUB offers a nice graphical interface, giving you a basic choice between which installed operating systems or kernels you want to run. The /etc/grub.conf file is a symbolic link to the actual file that is located in /boot/grub/grub.conf.

Listing 8-3 shows a typical grub.conf file.

# grub.conf generated by anaconda

#

# Note that you do not have to rerun grub after making changes to this file

# NOTICE: You have a /boot partition. This means that

# all kernel and initrd paths are relative to /boot/, eg.

# root (hd0,1)

# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00

# initrd /initrd-version.img

#boot=/dev/hda default=0 timeout=5 splashimage=(hd0,1)/grub/splash.xpm.gz

hiddenmenu password --md5 $1$ANJi7kLJ$/NODBfkCTkMAPxZgC8WK10

Listing 8-3 A typical GRUB configuration file. (continued)

13_599496 ch08.qxd 8/30/05 6:37 PM Page 171

Examining the System Configuration Files 171

title Fedora Core (2.6.10-1.770_FC3) root (hd0,1) kernel /vmlinuz-2.6.10-1.770_FC3 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.10-1.770_FC3.img

title Fedora Core (2.6.10-1.766_FC3) root (hd0,1) kernel /vmlinuz-2.6.10-1.766_FC3 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.10-1.766_FC3.img

title Fedora Core (2.6.9-1.724_FC3) root (hd0,1) kernel /vmlinuz-2.6.9-1.724_FC3 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.9-1.724_FC3.img

#title Fedora Core (2.6.9-1.667)

# root (hd0,1)

# kernel /vmlinuz-2.6.9-1.667 ro root=/dev/VolGroup00/LogVol00 rhgb quiet

# initrd /initrd-2.6.9-1.667.img

title Other rootnoverify (hd0,0) chainloader +1

Listing 8-3 (continued)

As you can see, the default=0 line indicates that the first title section should be booted by default. GRUB starts its counting at 0 instead of 1. The title line contains the label that will be shown in the boot menu for that kernel.

The root line specifies that Linux will be booted off the first hard drive. The kernel line indicates the kernel’s location on the file system.

In the Other title section, notice that GRUB is calling a chain loader to be used for loading a different operating system; in this case it is actually Windows

XP. GRUB uses a chain loader because it doesn’t support loading Windows XP.

GRUB uses a chain loader to load any operating system that it doesn’t support.

C R O S S - R E F E R E N C E

See Chapter 6 for a detailed explanation of GRUB.

cron files

cron is a daemon that executes commands according to a preset schedule that a user defines. It wakes up every minute and checks all cron files to see what jobs need to be run at that time. cron files can be set up by users or by the administrator to take care of system tasks. Basically, users edit their crontab files by telling cron what programs they’d like run automatically and how often they’d like to run them.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 172

172 Chapter 8

N OT E

You should never manually edit the files in the /var/spool/cron

directory.

User crontab files are stored in /var/spool/cron/. They are named after the user they belong to. System cron files are stored in the following subdirectories of the /etc directory:

■■ cron.d

■■ cron.daily

■■ cron.hourly

■■ cron.monthly

■■ cron.weekly

crontab in the /etc directory is sort of the master control file set up to run all the scripts in the cron.daily directory on a daily basis, all the scripts in the cron.hourly

directory on an hourly bases, and so on with cron.monthly

and cron.weekly.

cron.d

is where system maintenance files that need to be run on a different schedule than the other /etc cron files are kept. By default, a file in cron.d

called sysstat runs a system activity accounting tool every 10 minutes, 24

×

7.

C R O S S - R E F E R E N C E

Chapter 28 explains the cron command in more detail.

syslog.conf

The syslog daemon logs any notable events on your local system. It can store these logs in a local file or send them to a remote log host for added security. It can also accept logs from other machines when acting as a remote log host.

These options and more, such as how detailed the logging should be, are set in the syslog.conf file.

Listing 8-4 is an excerpt that demonstrates the syntax and logic of the syslog.conf

file. The first entry specifies that all messages that are severitylevel info or higher should be logged in the /var/log/messages file.

Also indicated by the first entry is that any mail, news, private authentication, and cron messages should be logged elsewhere. Having separate log files makes it easier to search through logs if they are separated by type or program.

The lines following this one specify the other places where those messages should be logged.

Authentication privilege messages contain somewhat sensitive information, so they are logged to /var/log/secure. That file can be read by root only, whereas /var/log/messages is sometimes set to be readable by everyone

13_599496 ch08.qxd 8/30/05 6:37 PM Page 173

Examining the System Configuration Files 173

or at least has less stringent access control. By default, /var/log/messages is set to be read by root only as well.

All mail messages are logged to /var/log/maillog, and cron messages are saved at /var/log/cron. uucp and critical-level news daemon log messages are saved to /var/log/spooler. All of these log files are set by default to be readable by root only. Emergency messages are sent to all the log files listed in the syslog.conf file, including to the console.

# Log all kernel messages to the console.

# Logging much else clutters up the screen.

#kern.* /dev/console

# Log anything (except mail) of level info or higher.

# Don’t log private authentication messages!

*.info;mail.none;authpriv.none;cron.none /var/log/messages

# The authpriv file has restricted access.

authpriv.* /var/log/secure

# Log all the mail messages in one place.

mail.* -/var/log/maillog

# Log cron stuff cron.* /var/log/cron

# Everybody gets emergency messages

*.emerg *

# Save news errors of level crit and higher in a special file.

uucp,news.crit /var/log/spooler

# Save boot messages also to boot.log

local7.* /var/log/boot.log

# Log anything (except mail) of level info or higher.

# Don’t log private authentication messages!

*.info;mail.none;news.none;authpriv.none;cron.none /var/log/messages

# The authpriv file has restricted access.

authpriv.* /var/log/secure

# Log all the mail messages in one place.

mail.* /var/log/maillog

# Log cron stuff cron.* /var/log/cron

Listing 8-4 An excerpt from the /etc/syslog.conf file. (continued)

13_599496 ch08.qxd 8/30/05 6:37 PM Page 174

174 Chapter 8

# Everybody gets emergency messages

*.emerg *

# Save news errors of level crit and higher in a special file.

uucp,news.crit /var/log/spooler

Listing 8-4 (continued)

ld.so.conf

This configuration file is used by ldconfig, which configures dynamic linker runtime bindings. It contains a listing of directories that hold shared libraries.

Shared library files typically end with .so, whereas static library files typically end with .a, indicating they are an archive of objects.

You may need to edit this file if you’ve installed a program that has installed a shared library to a different library directory that is not listed in the ld.so.conf

file. In this case, you get an error at runtime that the library does not exist.

An additional troubleshooting step to take in that case is to run ldd on the executable in question, which prints shared library dependencies. The output would look something like this:

[[email protected] root]# ldd /bin/bash libtermcap.so.2 => /lib/libtermcap.so.2 (0x40026000) libdl.so.2 => /lib/libdl.so.2 (0x4002a000) libc.so.6 => /lib/tls/libc.so.6 (0x42000000)

/lib/ld-linux.so.2 (0x40000000)

You can see a default listing of library directories in Listing 8-5.

include ld.so.conf.d/*.conf

/usr/X11R6/lib

/usr/lib/qt-3.3/lib

/usr/lib/mysql

Listing 8-5 A typical ld.so.conf file.

logrotate.conf

logrotate.conf

and the files within the logrotate.d directory determine how often your log files are rotated by the logrotate program. Log rotation refers to the process of deleting older log files and replacing them with more recent ones. logrotate can automatically rotate, compress, remove,

13_599496 ch08.qxd 8/30/05 6:37 PM Page 175

Examining the System Configuration Files 175

and mail your log files. Log files can be rotated based on size or on time, such as daily, weekly, or monthly.

As you can see from the default logrotate.conf file shown in Listing

8-6, most of the options set for how and when to rotate the system logs are pretty self-explanatory.

For every program that has a separate log rotation configuration file in logrotate.d

, and uses syslogd for logging, there should be a logrot config file for all log entries in /etc/syslog.conf, as well as log files produced by external applications, such as Apache. This is because syslog needs to save log entries for these programs in separate files so that their log files can be rotated independently of one another.

# see “man logrotate” for details

# rotate log files weekly weekly

# keep 4 weeks worth of backlogs rotate 4

# create new (empty) log files after rotating old ones create

# uncomment this if you want your log files compressed

#compress

# RPM packages drop log rotation information into this directory include /etc/logrotate.d

# no packages own wtmp -- we’ll rotate them here

/var/log/wtmp { monthly create 0664 root utmp rotate 1

}

# system-specific logs may be also be configured here.

Listing 8-6 The logrotate.conf file.

Examining 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 used only in very specific or rare circumstances. The /usr/share/doc

/initscripts-version-number/sysconfig.txt

file contains a more

13_599496 ch08.qxd 8/30/05 6:37 PM Page 176

176 Chapter 8

authoritative listing of the files found in the /etc/sysconfig directory and the configuration options available. Figure 8-1 shows the contents in a Fedora

Core 3 /etc/sysconfig directory.

N OT E

These files are used to pass configuration information to scripts that run when the system starts. It is possible that your system may be missing some of the configuration files described here, or it may have more of the files and directories, depending on whether the corresponding programs that need the files are installed or not. Also, if the service that uses the configuration file is not started, the configuration file will not be read.

/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 provides information to the apmd during startup if apmd is set to start, depending on whether your hardware supports Advanced Power Management (APM) or whether you choose 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.

Figure 8-1 The contents of the /etc/sysconfig directory.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 177

Examining the System Configuration Files 177

/etc/sysconfig/authconfig

The /etc/sysconfig/authconfig file provides settings to /usr/sbin

/authconfig

, which is called from /etc/rc.sysinit for the kind of authorization to be used on the host. The basic syntax for lines in this file is:

USE <service name> =<value>

Some sample lines from the file are shown here.

■■

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. Currently, the correct values are as follows:

■■

UTC=value

, where value is one of the following Boolean values:

■■ true

— Indicates that the hardware 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 time zone file under /usr/share

/zoneinfo that /etc/localtime is a copy of, such as: ZONE=

”America/New York”

. Identifies the time zone file copied into /etc

/localtime

, such as ZONE=”America/New York”. Time zone files are stored in /usr/share/zoneinfo.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 178

178 Chapter 8

/etc/sysconfig/crond

This file contains settings for the cron daemon. You typically do not need to make any changes to this file.

/etc/sysconfig/desktop

The /etc/sysconfig/desktop file specifies the desktop manager to be run and is used by the /etc/X11/xinit/Xclients script, for example:

DESKTOP=”GNOME”

/etc/sysconfig/firstboot

In Fedora Core and Enterprise Linux, the first time you boot the system after the OS installation, 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/grub

The /etc/sysconfig/grub file is used to pass arguments to GRUB at boot time. The information passed is the drive to boot from and whether to use lba mode.

/etc/sysconfig/harddisks

The /etc/sysconfig/harddisks file allows you to tune your hard drive(s).

C A U T I O N

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.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 179

Examining the System Configuration Files 179

■■

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 can suddenly show up as added or not show up if removed.

/etc/sysconfig/i18n

The /etc/sysconfig/i18n file sets the default language, for example:

LANG=”en_US”

/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. It defaults to 60.

■■

MOVE_TO_COL=value

, where value moves the cursor to the value in the RES_COL line. It defaults to ANSI sequences output by echo -e.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 180

180 Chapter 8

■■

SETCOLOR_SUCCESS=value

, where value sets the color to a color indicating success. It 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. It 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. It defaults to ANSI sequences output by echo -e, setting the color to yellow.

■■

SETCOLOR_NORMAL=value

, where value sets the color to “normal.”

It 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/iptables

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 from a terminal prompt if you aren’t running an X server. If you are running an X server, you can type system-config-

securitylevel

from a terminal prompt or select Applications ➪ System

Settings ➪ Security Level from the main menu to start the graphical application to create your firewall. Using these applications automatically edits 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 are persisted through a system reboot or a service restart.

C R O S S - R E F E R E N C E

For more information on iptables, see Chapter 34.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 181

Examining the System Configuration Files 181

/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 whether 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 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/kernel

The settings in this file specify whether new kernels loaded by the up2date utility should be booted by default. You can change the setting from yes to no to prevent the newly updated kernel from booting.

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

13_599496 ch08.qxd 8/30/05 6:37 PM Page 182

182 Chapter 8

■■

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 is used by /etc/init.d/kudzu, and it 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 by /etc/init.d/gpm 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.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 183

Examining the System Configuration Files 183

■■

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 if the named daemon is started. 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 preceding ROOTDIR line.

For more information about what parameters you can use in this file, type

man named

. By default, the file contains no parameters.

C R O S S - R E F E R E N C E

For detailed information on how to configure a BIND

DNS server, see Chapter 18.

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

13_599496 ch08.qxd 8/30/05 6:37 PM Page 184

184 Chapter 8

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

N OT E

For compatibility with older software that people might install, 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 if it is used 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.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 185

Examining the System Configuration Files 185

■■

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

This file is a link to /etc/selinux/config and is used to control selinux on the system. It contains two settings that control the state of selinux — enforcing, permissive, or disabled — and the type of policy, either targeted or strict.

A sample of this file is shown here.

# This file controls the state of SELinux on the system.

# SELINUX= can take one of these three values:

# enforcing - SELinux security policy is enforced.

# permissive - SELinux prints warnings instead of enforcing.

# disabled - SELinux is fully disabled.

SELINUX=permissive

# SELINUXTYPE= type of policy in use. Possible values are:

# targeted - Only targeted network daemons are protected.

# strict - Full SELinux protection.

SELINUXTYPE=targeted

/etc/sysconfig/system-config-users

The /etc/sysconfig/system-config-users file is the configuration file for the graphical application User Manager. 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.

/etc/sysconfig/system-logviewer

The /etc/sysconfig/system-logviewer file is the configuration file for the graphical, interactive log-viewing application Log Viewer. This file is edited

13_599496 ch08.qxd 8/30/05 6:37 PM Page 186

186 Chapter 8

via the Edit ➪ Preferences pull-down menu in the System Logs 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 NetBIOSover-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/vncservers

The /etc/sysconfig/vncservers file configures the way the virtual network computing (VNC) server starts up. VNC is a remote display system that 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.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 187

Examining the System Configuration Files 187

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 research.att.com/vnc/sshvnc.html

. To find out more about SSH, see Chapter 28.

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

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

.

daemons

This directory is initially empty after the system installation. It is used to hold the configuration scripts for programs that the user may have installed. For example, the configuration files for the webmin program are placed in this directory during its installation.

networking

This directory is used by the Network Configuration tool (system-confignetwork), and its contents should not be edited manually.

C R O S S - R E F E R E N C E

For more information about configuring network interfaces using the Network Configuration tool, see Chapter 11.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 188

188 Chapter 8

network-scripts

This directory contains files used for network configuration.

■■

■■

■■

■■

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 ifupisdn and ifdown-isdn.

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

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 Web site at https:// rhn.redhat.com

.

Examining the Network Configuration Files

This section discusses the following topics:

■■

■■

Files to change when setting up a system or moving the system

Starting up network services from xinetd

■■

■■

Starting up network services from the rc scripts

Other important network configuration files in the /etc/sysconfig directory

Files to Change When Setting Up a System or Moving the System

Whenever you set up a system to work on a new network, either because you’ve just installed Red Hat or you’re moving the machine from one location to another, a set of files needs to be modified to get it working on the new network.

You need to:

■■

Set up the IP addresses of your network interfaces. Make changes to:

/etc/sysconfig/network-scripts/ifcfg-eth0

13_599496 ch08.qxd 8/30/05 6:37 PM Page 189

Examining the System Configuration Files 189

■■

Set up the hostname of your machine. Make changes to:

/etc/sysconfig/network

/etc/hosts

■■

Set up the DNS servers to reference. Make changes to:

/etc/resolv.conf

■■

Make a local file of hostname to IP address mappings. Make changes to:

/etc/hosts

■■

Set up the device order from which hostnames are looked up. Make changes to:

/etc/nsswitch.conf

C R O S S - R E F E R E N C E

Chapter 20 explains the Domain Name System (DNS) and how to set it up on your network.

T I P

Fedora Core and Red Hat Enterprise Linux provide a handy graphical tool, called the Network Configuration tool for configuring your network settings.

Start up the Network Configuration tool while in X-Window, and enjoy an interface very similar to the Windows control panel for networks. Refer to

Chapter 11 for instructions on using the Network Configuration tool. If you use the Network Configuration tool to set up your network, you do not need to edit the files manually as explained in the next sections. Also, if you use DHCP to obtain your IP information, you do not need to do any manual configuration and can skip the sections related to manually configuring your network settings.

Setting Up the IP Address

The first thing you should do is set an IP address on your network interfaces.

This step provides your computer with an identity on the network. If you haven’t set the IP address already in the installation process, you need to edit the configuration files by hand.

To set the IP address on your first Ethernet interface eth0, edit the /etc/ sysconfig/network-scripts/ifcfg-eth0 file. A copy of this file is shown in Listing 8-7.

Insert your interface’s IP address on the line that says:

IPADDR=””

You should also check that the rest of the lines look all right, but pay special attention to the following two lines:

13_599496 ch08.qxd 8/30/05 6:37 PM Page 190

190 Chapter 8

BROADCAST=192.168.1.255

NETMASK=”255.255.255.0”

DEVICE=”eth0”

BOOTPROTO=”static”

BROADCAST=192.168.1.255

IPADDR=”192.168.1.10”

NETMASK=”255.255.255.0”

NETWORK=192.168.1.0

ONBOOT=”yes”

USERCTL=no

Listing 8-7 The /etc/sysconfig/network-scripts/ifcfg-eth0 file.

Setting Up the Hostname

Once you’ve picked your hostname, you need to put it into two different places: /etc/sysconfig/network and /etc/hosts.

In /etc/sysconfig/network, shown next, change the line that says:

HOSTNAME=”terry”

This is the /etc/sysconfig/network file:

NETWORKING=yes

HOSTNAME=”terry”

GATEWAY=”192.168.1.1”

GATEWAYDEV=”eth0”

FORWARD_IPV4=”yes”

You also need to modify the /etc/hosts file. Change the first line in the file, which would look something like this by adding the hostname you want:

127.0.0.1 terry localhost.localdomain localhost locala localb localc

Setting Up the DNS Name Resolution

Now you should be able to communicate with the other hosts on the network.

However, you won’t be able to talk to them unless you know their IP addresses, because you haven’t set up what DNS servers you should reference to map hostnames to IP addresses.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 191

Examining the System Configuration Files 191

The program that resolves hostnames to IP addresses reads a file called resolv.conf

, so you need to put your DNS server IP addresses there. Generally, you need one name server, but you can include up to three, if you’d like.

Specifying more than one name server is important. If the first one on the list is not responding, your computer tries to resolve against the next one on the list, and so on, until it finds one that is responding.

Edit /etc/resolv.conf to contain a list of name servers, like this: nameserver 1.2.3.4

nameserver 1.2.3.5

nameserver 1.2.3.6

Making a Local File of Hostname to IP Address Mappings

Linux gives you the ability to store a list of hostnames and their corresponding

IP addresses in /etc/hosts, so that you don’t have to look them up in DNS every time you use them. While you shouldn’t do this with every hostname you ever use, one of the advantages gained by configuring often-used hostnames in this way includes the ability to alias a fully qualified hostname to a shorter version of itself. So instead of typing ssh foo.xena.edu every time you want to SSH to that machine, you can just type ssh foo, and have it connect to the same host.

Another useful example occurs if you’re monitoring several servers’ network services from a monitoring host. If you’re monitoring SSH connectivity to certain servers, for example, and your DNS server stops responding, then the monitoring software may report that all your hosts are down. This happens because the monitoring software tries to connect to the server via its hostname, and gets no response because DNS is not providing it with an IP address to connect to. In this case it looks as if your whole network fell over, when the real problem is that your DNS service is not responding properly.

To keep this kind of scenario from happening, you should put the hostnames and IP addresses of all your monitored servers in /etc/hosts. This way, your monitoring software looks into /etc/hosts to get the proper IP addresses, instead of relying on DNS.

The only caveat to keep in mind when putting hosts in /etc/hosts is that if the hostname’s IP address changes for whatever reason, the hosts file does not automatically update to reflect that change. If you start getting connection errors when connecting to a host in the /etc/hosts file, you should do an nslookup on the host and update your /etc/hosts file accordingly.

Your /etc/hosts file should contain IP address to hostname mappings that follow this format

IP_address canonical_hostname aliases

13_599496 ch08.qxd 8/30/05 6:37 PM Page 192

192 Chapter 8

so that the lines look like this:

192.168.1.66 foo.xena.edu foo

192.168.1.76 buffy.xena.edu buffy

152.2.210.81 sunsite.unc.edu sunsite

Setting Up Name Service Resolution Order

Now that you’ve set up your DNS servers and hosts file, you need to tell your

Linux server which method it should use first to look up hostnames.

The place to set up this configuration is in the /etc/nsswitch.conf file.

Edit the following line: hosts: files nisplus dns

The order of the words files, nisplus, and dns determines which method is checked first. Files refers to the /etc/hosts file, nisplus refers to any nisplus servers you may have on your network, and dns refers to any

DNS servers you have set up your machine to reference.

As you can see in Listing 8-8, the /etc/nsswitch.conf file contains some other useful settings; for example the following two lines, specify whether the server should authenticate users off the local password file or off the network’s

NIS plus service: passwd: files nisplus shadow: files nisplus

#

# /etc/nsswitch.conf

#

# An example Name Service Switch config file. This file should be

# sorted with the most-used services at the beginning.

#

# The entry ‘[NOTFOUND=return]’ means that the search for an

# entry should stop if the search in the previous entry turned

# up nothing. Note that if the search failed due to some other reason

# (like no NIS server responding) then the search continues with the

# next entry.

#

# Legal entries are:

#

# nisplus or nis+ Use NIS+ (NIS version 3)

# nis or yp Use NIS (NIS version 2), also called YP

# dns Use DNS (Domain Name Service)

# files Use the local files

Listing 8-8 The /etc/nsswitch.conf file. (continued)

13_599496 ch08.qxd 8/30/05 6:37 PM Page 193

Examining the System Configuration Files 193

# db Use the local database (.db) files

# compat Use NIS on compat mode

# hesiod Use Hesiod for user lookups

# [NOTFOUND=return] Stop searching if not found so far

#

# To use db, put the “db” in front of “files” for entries you want to be

# looked up first in the databases

#

# Example:

#passwd: db files nisplus nis

#shadow: db files nisplus nis

#group: db files nisplus nis passwd: files nisplus shadow: files nisplus group: files nisplus

#hosts: db files nisplus nis dns hosts: files nisplus dns

# Example - obey only what nisplus tells us...

#services: nisplus [NOTFOUND=return] files

#networks: nisplus [NOTFOUND=return] files

#protocols: nisplus [NOTFOUND=return] files

#rpc: nisplus [NOTFOUND=return] files

#ethers: nisplus [NOTFOUND=return] files

#netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files nisplus rpc: files services: files nisplus netgroup: files nisplus publickey: nisplus automount: files nisplus aliases: files nisplus

Listing 8-8 (continued)

Starting Up Network Services from xinetd

xinetd is the replacement for inetd. xinetd is started on bootup and listens on ports designated in the /etc/xinetd.conf for incoming network

13_599496 ch08.qxd 8/30/05 6:37 PM Page 194

194 Chapter 8

connections. When a new connection is made, xinetd starts up the corresponding network service.

You should disable any unnecessary services from being started from xinetd as part of securing your machine. The way to do this is to edit that service’s configuration file. xinetd’s main configuration file is /etc/xinetd.conf. At the end of the xinetd.conf file is a line that indicates that all the files in the /etc/ xinetd.d

are also included in the configuration. This means that you need to go through the files in that directory as well to turn off any services you don’t want.

So, to disable Telnet, you would look in /etc/xinetd.d for a file called telnet

. The telnet file is shown in Listing 8-9. Edit the line in the config file that says disable = no, and change that to disable = yes, as it appears in

Listing 8-9. After that line is set to disable = yes, the service is disabled and does not start up the next time you boot up.

/etc/xinetd.d/telnet

# default: on

# description: The telnet server serves telnet sessions; it uses \

# unencrypted username/password pairs for authentication.

service telnet

{ flags = REUSE socket_type = stream wait = no user = root server = /usr/sbin/in.telnetd

log_on_failure += USERID disable = yes

}

Listing 8-9 The Telnet config file in the xinetd.d directory.

An automated tool, called chkconfig, manages what services are started from xinetd and the rc scripts. You can read more about chkconfig in the section called “Managing rc Scripts Using chkconfig.”

Starting Up Network Services from the rc Scripts

Network services that are not started out of xinetd are started out of the rc scripts at boot time. Network services started at the default boot level 3 (multiuser networked mode) are started out of the /etc/rc3.d directory. If you look in that directory, you should see a file with the name of the service you want to stop or start. The script to start the service starts with an S, and the kill script starts with a K.

So for example, SSH is started from /etc/rc3.d /S55sshd, and killed upon shutdown from /etc/rc6.d/K25sshd. Runlevel 6 is the shutdown level, so that’s why its kill script is located in the rc6.d directory.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 195

Examining the System Configuration Files 195

Detailed information on managing all the services started at boot time can be found in the section “Managing the init Scripts” later in this chapter.

C R O S S - R E F E R E N C E

See Chapter 6 for details about the system startup process.

Other Important Network Configuration Files in the /etc/sysconfig Directory

You can use the files listed in this section to create routes to other hosts, either on your own network or on outside networks. You also can use these files to set up firewall rules for your network to either allow or disallow connections to your network.

static-routes

If you want to set up some static routes on your machine, you can do so in the static-routes file. This config file has lines in the following format: network-interface net network netmask netmask gw gateway

Iptables

iptables is the current Fedora Core and Enterprise Linux firewall. It supercedes the ipchains firewall. It can use ipchains rules as a component of its firewall filtering, but iptables and ipchains cannot be run at the same time. This is the file where the iptables rules are stored.

When you install Fedora or Enterprise Linux, the installation asks if you would like to enable a host-based firewall. If you select to enable a host-based firewall, a default set of iptables rules installs according to your preferences.

The following is a simplified configuration file. The gist of this configuration is that all incoming traffic to privileged ports (those below 1024) is dropped except for SSH traffic. The first line accepts all traffic from the loopback interface. The second line accepts all incoming TCP traffic to the SSH port. The third line drops all incoming TCP traffic to ports between 1 and 1024.

The last line drops all incoming UDP traffic to ports between 1 and 1024.

-A INPUT -i lo -j ACCEPT

-A INPUT -p tcp --dport 22 -p tcp -j ACCEPT

-A INPUT -p tcp -s ! 192.168.1.0/24 --dport 1:1024 -j DROP

-A INPUT -p udp -s ! 192.168.1.0/24 --dport 1:1024 -j DROP

13_599496 ch08.qxd 8/30/05 6:37 PM Page 196

196 Chapter 8

Network Configuration Files in

/etc/sysconfig/network-scripts

You can use the files in this directory to set the parameters for the hardware and software used for networking. The scripts contained here are used to enable network interfaces and set other network-related parameters.

ifcfg-networkinterfacename

A few files fall into this specification. Red Hat specifies a separate configuration file for each network interface. In a typical Red Hat install, you might have many different network interface config files that all follow the same basic syntax and format.

You could have ifcfg-eth0 for your first Ethernet interface, ifcfgirlan0 for your infrared network port, ifcfg-lo for the network loopback interface, and ifcfg-ppp0 for your PPP network interface.

ifup and ifdown

These files are symlinks to /sbin/ifup and /sbin/ifdown. In future releases, these symlinks might be phased out. But for now, these scripts are called when the network service is started or stopped. In turn, ifup and ifdow n call any other necessary scripts from within the network-scripts directory. These should be the only scripts you call from this directory.

You call these scripts with the name of the interface that you want to bring up or down. If these scripts are called at boot time, then boot is used as the second argument. For instance, to bring your Ethernet interface down and then up again after boot, you would type: ifup eth0 ifdown eth0

Managing the init Scripts

This section discusses the following topics:

■■

Managing rc scripts by hand

■■

Managing rc scripts using chkconfig

Init scripts determine which programs start up at boot time. Red Hat and other Unix distributions have different runlevels, so there are a different set of programs that are started at each runlevel.

13_599496 ch08.qxd 8/30/05 6:37 PM Page 197

Examining the System Configuration Files 197

Usually Red Hat Linux starts up in multiuser mode with networking turned on. These are some of the other runlevels available:

■■

0

— Halt

■■

1

— Single-user mode

■■

2

— Multiuser mode, without networking

■■

3

— Full multiuser mode

■■

4

— Not used

■■

5

— Full multiuser mode (with an X-based login screen)

■■

6

— Reboot

The system boots into the default runlevel set in /etc/inittab. (See Listing 8-10.)

N OT E

In Red Hat Linux, the default boot level is 3 for a non-GUI system.

When booting into an X-windows login, the default boot level is 5. You can get more information about this topic in Chapter 6.

#

# inittab This file describes how the INIT process should set up

# the system in a certain run-level.

#

# Author: Miquel van Smoorenburg, <[email protected]>

# Modified for RHS Linux by Marc Ewing and Donnie Barnes

#

# Default runlevel. The runlevels used by RHS are:

# 0 - halt (Do NOT set initdefault to this)

# 1 - Single user mode

# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)

# 3 - Full multiuser mode

# 4 - unused

# 5 - X11

# 6 - reboot (Do NOT set initdefault to this)

# id:5:initdefault:

# System initialization.

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

l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4

Listing 8-10 A default /etc/inittab file. (continued)

13_599496 ch08.qxd 8/30/05 6:37 PM Page 198

198 Chapter 8

l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6

# Things to run in every runlevel.

ud::once:/sbin/update

# Trap CTRL-ALT-DELETE ca::ctrlaltdel:/sbin/shutdown -t3 -r now

# When our UPS tells us power has failed, assume we have a few minutes

# of power left. Schedule a shutdown for 2 minutes from now.

# This does, of course, assume you have powerd installed and your

# UPS connected and working correctly.

pf::powerfail:/sbin/shutdown -f -h +2 “Power Failure; System Shutting Down”

# If power was restored before the shutdown kicked in, cancel it.

pr:12345:powerokwait:/sbin/shutdown -c “Power Restored; Shutdown Cancelled”

# Run gettys in standard runlevels

1:2345:respawn:/sbin/mingetty tty1

2:2345:respawn:/sbin/mingetty tty2

3:2345:respawn:/sbin/mingetty tty3

4:2345:respawn:/sbin/mingetty tty4

5:2345:respawn:/sbin/mingetty tty5

6:2345:respawn:/sbin/mingetty tty6

# Run xdm in runlevel 5

# xdm is now a separate service x:5:respawn:/etc/X11/prefdm –nodaemon

Listing 8-10 (continued)

Managing rc Scripts by Hand

If you want to configure which services are started at boot time, you need to edit the rc scripts for the appropriate runlevel. The default runlevel is 3, which is full multiuser mode without a graphical interface and runlevel 5 with a graphical interface. So, to change the services that are started in the default runlevel, you should edit the scripts found in /etc/rc3.d, or /etc/rc5.d

depending on your system.

When you look at a directory listing of the rc directories, notice that the files either start with S or K. The files that start with S are startup files, and the files that start with K are kill files. The S scripts are run in the numerical order listed in their filenames. It should be mentioned that if a startup script is set to S15, the K script should be K85 (or in general, SN becomes SM with M = 100 - n; the idea being the last started service is the first killed).

13_599496 ch08.qxd 8/30/05 6:37 PM Page 199

Examining the System Configuration Files 199

Note that case is important. Scripts that do not start with a capital S do not run upon startup. One good way to keep scripts from starting up at boot time without deleting them is to rename the file with a small s at the beginning instead of a capital S. This way you can always put the script back into the startup configuration by capitalizing the initial letter.

When the system starts up, it runs through the scripts in the rc directory of the runlevel it’s starting up in. So when the system starts up in runlevel 3, it runs the scripts in the /etc/rc3.d directory.

Looking at the directory listing included in Figure 8-2, you can see that the first few services start in this order: kudzu, reconfig, iptables, and network.

That is so because their scripts are named S05kudzu, S06cpuspeed,

S08iptables

, and S10network, respectively.

Kudzu is called first because it detects new hardware. cpuspeed runs to put into effect speed stepping for the CPU. iptables then starts up the built-in firewall. Network then brings up the system’s network interfaces. As you can see, the order in which these services are started makes a lot of sense, and their order is enforced by the way their rc startup scripts are named. All of the files in rc#.d are symbolic links to /etc/init.d scripts, and the names are used here only to affect what services start or stop and the ordering of those services. Editing the rc3.d/httpd file will affect rc5.d/httpd.

The S scripts are started in this order until they have all been started. When the system shuts down, the corresponding K or kill scripts are run to shut down the services started from the rc directory. In general, every S script should have a corresponding K script to kill the service at shutdown.

If you can’t find the corresponding K script in the startup directory, it is probably located in the shutdown directory. When the system is shut down, it enters runlevel 6. So, most K scripts are in /etc/rc6.d. A typical /etc/rc6.d directory listing is shown Figure 8-3.

Figure 8-2 A directory listing of the r3.d directory.

13_599496 ch08.qxd 8/30/05 6:38 PM Page 200

200 Chapter 8

Figure 8-3 The file contents of the /etc/rc6.d directory.

If you ever need to restart a service that’s started from an rc directory, an easy way to do it properly is to run its startup script with the restart option.

This procedure enables all the proper steps to be followed (configuration files read, lock files released, and so forth) when the service starts up again. So, to restart syslog, for example, run the following command from the rc directory:

[[email protected] rc3.d]# ./S12syslog restart

Shutting down kernel logger: [ OK ]

Shutting down system logger: [ OK ]

Starting system logger: [ OK ]

Starting kernel logger: [ OK ]

Managing rc Scripts Using chkconfig

Fedora Core and Red Hat Enterprise Linux come with a useful tool called chkconfig. It helps the system administrator manage rc scripts and xinetd configuration files without having to manipulate them directly. It is inspired by the chkconfig command included in the IRIX operating system.

Type chkconfig --list to see all the services chkconfig knows about, and whether they are stopped or started in each runlevel. An abridged example output is shown in the following listing. The chkconfig output can be a lot longer than that listed here, so be prepared to pipe it through less or more.

The first column is the name of the installed service. The next seven columns each represent a runlevel, and tell you whether that service is turned on or off in that runlevel.

Since xinetd is started on the system whose chkconfig output is excerpted, at the end of chkconfig’s report is a listing of what xinetd started services are

13_599496 ch08.qxd 8/30/05 6:38 PM Page 201

Examining the System Configuration Files 201

configured to begin at boot time. The listing is abridged, since a lot of services can be started from xinetd, and there’s no need to show all of them.

Listing 8-11 shows how chkconfig can be an effective tool for handling all your network services and controlling which ones get started up at boot time.

This is the output of chkconfig --list: atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off rwhod 0:off 1:off 2:off 3:off 4:off 5:off 6:off keytable 0:off 1:on 2:on 3:on 4:on 5:on 6:off nscd 0:off 1:off 2:off 3:off 4:off 5:off 6:off syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off gpm 0:off 1:off 2:on 3:off 4:off 5:off 6:off kudzu 0:off 1:off 2:off 3:on 4:on 5:on 6:off kdcrotate 0:off 1:off 2:off 3:off 4:off 5:off 6:off lpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off autofs 0:off 1:off 2:off 3:on 4:on 5:on 6:off sendmail 0:off 1:off 2:on 3:off 4:off 5:off 6:off rhnsd 0:off 1:off 2:off 3:on 4:on 5:on 6:off netfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off network 0:off 1:off 2:on 3:on 4:on 5:on 6:off random 0:off 1:off 2:on 3:on 4:on 5:on 6:off rawdevices 0:off 1:off 2:off 3:on 4:on 5:on 6:off apmd 0:off 1:off 2:on 3:off 4:off 5:off 6:off ipchains 0:off 1:off 2:off 3:off 4:off 5:off 6:off

<snip> xinetd based services: rexec: off rlogin: off rsh: off chargen: off chargen-udp: off daytime: off daytime-udp: off echo: off echo-udp: off time: off time-udp: off finger: off ntalk: off talk: off telnet: off wu-ftpd: on rsync: off eklogin: off gssftp: off klogin: off

Listing 8-11 Output from chkconfig –list.

13_599496 ch08.qxd 8/30/05 6:38 PM Page 202

202 Chapter 8

To turn a service off or on using chkconfig, use this syntax: chkconfig -level[0-6](you must choose the runlevel) servicename off|on|reset

So, to turn off the gpm daemon turned on previously, type: chkconfig --level 2 gpm off

To turn on xinetd, type: chkconfig xinetd on

Run chkconfig --list again to see if the service you changed has been set to the state you desire. Changes you make with chkconfig take place the next time you boot up the system. You can always start, stop, or restart a service by running service (service name) from a terminal prompt.

Summary

All systemwide configuration files are located in /etc. So, if you want to change something across the system, look in /etc and its subdirectories first.

If you’re at a loss in terms of figuring out which configuration file you need to edit, try grepping for keywords in /etc.

To change configuration variables for one or a few users, you can usually edit configuration files within the individual users’ home directories. Most configuration files in home directories start with a . so you need to look for them with the ls -a command.

Be mindful of configuration file permissions to ensure that unauthorized parties cannot modify them. Flat out instant root access for unauthorized parties is one possible outcome of a modified configuration file. A more likely outcome is that a configuration file modification would make it easier for a system compromise to take place.

You can either edit startup files by hand or by using one of the system administration tools such as chkconfig. You should at least know the format of the startup files and where they are, so that if automatic tools can’t do the job for some reason, you can always change things yourself.

14_599496 pt02.qxd 8/30/05 6:18 PM Page 203

PA R T

Two

Network Services

Chapter 9:

Managing the X Window System

Chapter 10:

Configuring Printers

Chapter 11:

TCP/IP Networking

Chapter 12:

The Network File System

Chapter 13:

The Network Information System

Chapter 14:

Connecting to Microsoft and Novell Networks

Chapter 15:

Configuring a Database Server

Chapter 16:

Creating a VNC Server

Chapter 17:

Providing Additional Network Services

Chapter 18:

Optimizing Network Services

14_599496 pt02.qxd 8/30/05 6:18 PM Page 204

15_599496 ch09.qxd 8/30/05 6:23 PM Page 205

C H A P T E R

9

Managing the

X Window System

IN THIS CHAPTER

■■

■■

Configuring the X Server with the X Configuration Tool

Manually Configuring the X Server

This chapter introduces you to the X Window system that is used to provide a graphical user interface (GUI) to the operating system. If you have used MS

Windows or Apple Macs, then you are already familiar with using a GUI.

Fedora Core and Enterprise Linux also give you similar features.

Configuring the X Server with the X Configuration Tool

You have basically two ways to configure the X server on your Fedora Core or

Enterprise Linux system. First, you can use the X Configuration tool, which is a graphical tool that gives you the ability to change some of the most significant settings, such as display, monitor, and video card settings. The X Configuration tool is a graphical front end to the X configuration file, xorg.conf, which is located in the /etc/X11 directory. Any changes that you make using the graphical utility are written to the /etc/X11/xorg.conf file. Second, you can edit the X Configuration file directly by using a text-editing application. In this section, I show you how to make X server configuration changes by using the X Configuration tool, beginning with changing the display resolution.

205

15_599496 ch09.qxd 8/30/05 6:23 PM Page 206

206 Chapter 9

Changing the Display Resolution

The X Configuration tool makes it easy for you to change your display resolution. To change your display resolution, do the following:

1. On Enterprise Linux 4 choose Applications ➪ System Settings ➪ Display to open the Display Settings dialog box, shown in Figure 9-1. On

Fedora Core 4 choose Desktop ➪ System Settings ➪ Display to open the

Display Settings dialog box.

N OT E

If you are not logged in as root, you will be prompted to enter the root password.

2. Select your desired resolution from the drop-down Resolution list.

3. Click OK to accept your choice, and close the dialog box.

N OT E

Any time you make changes to the X server configuration, you must restart the X server for the changes to take effect. When using the X

Configuration tool, you see a window reminding you to restart the X server.

Figure 9-1 Change your screen resolution here.

15_599496 ch09.qxd 8/30/05 6:23 PM Page 207

Managing the X Window System 207

Changing the Display Color Depth

The system display color depth setting determines the number of colors that are shown on the display. A higher color depth displays more colors on the monitor. To change the system color depth, do the following:

1. On Enterprise Linux 4 choose Applications ➪ System Settings ➪ Display to open the Display Settings dialog box. On Fedora Core 4 choose

Desktop ➪ System Settings ➪ Display to open the Display Settings dialog box. (Refer to Figure 9-1.)

2. Select your desired color depth from the Color Depth drop-down list.

3. Click OK to accept your choice and close the dialog box.

Changing Monitor Type Settings

The Fedora Core or Enterprise installer can usually detect the type of monitor that is connected to your system and set the configuration accordingly. Sometimes, however, the installer might not properly configure your monitor, requiring you to change the monitor settings. You also want to change your monitor settings if you get a different monitor with different parameters than your previous monitor. To change your monitor settings, do the following:

1. On Enterprise Linux 4 choose Applications ➪ System Settings ➪ Display to open the Display Settings dialog box. On Fedora Core 4 choose

Desktop ➪ System Settings ➪ Display to open the Display Settings dialog box. (Refer to Figure 9-1.)

2. Click the Hardware tab. (See Figure 9-2.)

3. Click the top Configure button (to the right of the monitor type listing) to open the Monitor dialog box, shown in Figure 9-3.

4. Find the manufacturer of your monitor in the list, and then click the arrow to the left of the manufacturer’s name to see a list of models.

5. Click the model number that matches your monitor.

6. Click OK twice to accept your choice, and exit the Display Settings dialog box.

T I P

If you can’t find your monitor manufacturer or model number on the monitor list, choose one of the generic monitors from the top of the monitor list.

15_599496 ch09.qxd 8/30/05 6:23 PM Page 208

208 Chapter 9

Figure 9-2 Access monitor and video card settings here.

Figure 9-3 Choose your monitor type.

Changing Your Video Card Type

The Fedora Core or Enterprise installer can usually detect the type of video card that is connected to your system and set the configuration accordingly.

However, if the installer doesn’t properly detect your video card, you might need to change the video card type. You would also want to change your video card type if you install a different video card. To change your video card type, do the following:

15_599496 ch09.qxd 8/30/05 6:23 PM Page 209

Managing the X Window System 209

1. On Enterprise Linux 4 choose Applications ➪ System Settings ➪ Display to open the Display Settings dialog box. On Fedora Core 4 choose

Desktop ➪ System Settings ➪ Display to open the Display Settings dialog box. (Refer to Figure 9-1.)

2. Click the Hardware tab. (Refer to Figure 9-2.)

3. Click the bottom Configure button (to the right of the video card type listing) to display the Video Card dialog box, shown in Figure 9-4.

4. Find the manufacturer of your video card in the list, and click the appropriate model.

Configuring Dual Monitors

In Fedora Core or Enterprise Linux, you can use two video cards and monitors on your system if you desire. To configure a second video card and monitor, do the following:

1. On Enterprise Linux 4 choose Applications ➪ System Settings ➪ Display to open the Display Settings dialog box. On Fedora Core 4 choose

Desktop ➪ System Settings ➪ Display to open the Display Settings dialog box. (Refer to Figure 9-1.)

2. Click the Dual Head tab, shown in Figure 9-5, in the Display Settings dialog box.

Figure 9-4 Configure your video card.

15_599496 ch09.qxd 8/30/05 6:23 PM Page 210

210 Chapter 9

Figure 9-5 Use the Dual Head tab to configure dual monitors.

3. Select the Use Dual Head check box.

4. Click the Configure button (next to the Second Monitor Type), choose your monitor from the list, and then click OK.

5. Enter the appropriate information for the video card type, display resolution, and color depth.

6. Select whether you want individual desktops on each display or a single desktop spanning both displays by selecting the appropriate choice.

7. Click OK twice to exit the configuration tool.

Manually Configuring Your X Server

The Fedora Core or Enterprise installer program usually does a good job of detecting the system mouse, keyboard, video card, and monitor. When you log in to your system, the settings are generally what they should be for a functioning X server. You may never need to configure your X server manually, but if you do, it would be good to know how. In this section you look at the X server configuration file /etc/X11/xorg.conf.

The X Server Configuration File

The X server configuration file, like most configuration files in Fedora Core or

Enterprise Linux is a plain-text file. Listing 9-1 is a typical X server configuration

15_599496 ch09.qxd 8/30/05 6:23 PM Page 211

Managing the X Window System 211

file that was created during system installation. A description of the section of the file follows the file.

# XFree86 4 configuration created by redhat-config-xfree86

Section “ServerLayout”

Identifier “Default Layout”

Screen 0 “Screen0” 0 0

InputDevice “Mouse0” “CorePointer”

InputDevice “Keyboard0” “CoreKeyboard”

InputDevice “DevInputMice” “AlwaysCore”

EndSection

Section “Files”

# RgbPath is the location of the RGB database.

#Note, this is the name of the

# file minus the extension (like “.txt” or “.db”).

#There is normally no need to change the default.

# Multiple FontPath entries are allowed (they are

# concatenated together)

# By default, Red Hat 6.0 and later now use a font

#server independent of the X server to render fonts.

RgbPath “/usr/X11R6/lib/X11/rgb”

FontPath “unix/:7100”

EndSection

Section “Module”

Load “dbe”

Load “extmod”

Load “fbdevhw”

Load “glx”

Load “record”

Load “freetype”

Load “type1”

Load “dri”

EndSection

Section “InputDevice”

# Specify which keyboard LEDs can be user-controlled

#(eg, with xset(1))

# Option “Xleds” “1 2 3”

# To disable the XKEYBOARD extension, uncomment

# kbDisable.

# Option “XkbDisable”

# To customise the XKB settings to suit your

# keyboard, modify the lines below (which are the

# defaults). For example, for a non-U.S.

# keyboard, you will probably want to use:

Listing 9-1 The X server configuration file /etc/X11/xorg.conf. (continued)

15_599496 ch09.qxd 8/30/05 6:23 PM Page 212

212 Chapter 9

# Option “XkbModel” “pc102”

# If you have a US Microsoft Natural keyboard, you

# can use:

# Option “XkbModel” “microsoft”

#

# Then to change the language, change the Layout

# setting.

# For example, a german layout can be obtained with:

# Option “XkbLayout” “de”

# or:

# Option “XkbLayout” “de”

# Option “XkbVariant” “nodeadkeys”

#

# If you’d like to switch the positions of your

# capslock and control keys, use:

# Option “XkbOptions” “ctrl:swapcaps”

# Or if you just want both to be control, use:

# Option “XkbOptions” “ctrl:nocaps”

#

Identifier “Keyboard0”

Driver “kbd”

Option “XkbModel” “pc105”

Option “XkbLayout” “us”

EndSection

Section “InputDevice”

Identifier “Mouse0”

Driver “mouse”

Option “Protocol” “IMPS/2”

Option “Device” “/dev/input/mice”

Option “ZAxisMapping” “4 5”

Option “Emulate3Buttons” “yes”

EndSection

Section “InputDevice”

# If the normal CorePointer mouse is not a USB mouse #then this input device can be used in AlwaysCore #mode to let you also use USB mice at the same time.

Identifier “DevInputMice”

Driver “mouse”

Option “Protocol” “IMPS/2”

Option “Device” “/dev/input/mice”

Option “ZAxisMapping” “4 5”

Option “Emulate3Buttons” “no”

EndSection

Section “Monitor”

Identifier “Monitor0”

Listing 9-1 (continued)

15_599496 ch09.qxd 8/30/05 6:23 PM Page 213

Managing the X Window System 213

VendorName “Monitor Vendor”

ModelName “LCD Panel 1280x1024”

DisplaySize 376 301

HorizSync 31.5 - 67.0

VertRefresh 50.0 - 75.0

Option “dpms”

EndSection

Section “Device”

Identifier “Videocard0”

Driver “nv”

VendorName “Videocard vendor”

BoardName “NVIDIA GeForce 2 MX (generic)”

VideoRam 32768

EndSection

Section “Screen”

Identifier “Screen0”

Device “Videocard0”

Monitor “Monitor0”

DefaultDepth 24

SubSection “Display”

Depth 24

Modes “1024x768” “800x600” “640x480”

EndSubSection

EndSection

Section “DRI”

Group 0

Mode 0666

EndSection

Listing 9-1 (continued)

This file contains configuration information for the fonts used by the system, the keyboard type and layout, and the video card, monitor, and displays.

There is a section in the file for each of these items. The sections and their uses are shown in Table 9-1.

Table 9-1 Sections Names and Their Uses

SECTION NAME USED FOR

Files

Server Flags

Module

File pathnames for fonts

Server Flags

Dynamic module loading

(continued)

15_599496 ch09.qxd 8/30/05 6:23 PM Page 214

214 Chapter 9

Table 9-1 (continued)

SECTION NAME

Input Device

Device

VideoAdapter

Monitor

Modes

Screen

Server Layout

DRI

USED FOR

Keyboards, mice, and other input devices

Video card information

Not used

Monitor description

Video mode descriptions

Display configuration

General description of the X server

Direct Rendering Infrastructure information

Listing 9-2 is the section listing for the screen section. Each of the sections follows a similar pattern beginning with the word Section, followed by the name of the device, then information or configuration details about the device, and finally ending with EndSection.

Section “Screen”

Identifier “Screen0”

Device “Videocard0”

Monitor “Monitor0”

DefaultDepth 24

SubSection “Display”

Depth 24

Modes “1024x768” “800x600” “640x480”

EndSubSection

EndSection

Listing 9-2 A typical section of the xorg.conf file.

Making changes to the xorg.conf file is easy. For example, to change the default color depth you just need to change the DefaultDepth number 24 shown in Listing 9-2 to 8, 16, or 32.

The modes line specifies the screen size in pixels that the X server will try to use in order beginning with the first one. If you wanted to add another screen resolution, you would enter the information into the Modes line of the display subsection. For example if you wanted to add 1200

×

1024, you would enter

1200x1024 to the beginning of the Modes line.

N OT E

You can toggle through the modes by holding Crtl+Alt and pressing plus or minus.

15_599496 ch09.qxd 8/30/05 6:23 PM Page 215

Managing the X Window System 215

Now you know what to do to change the screen section of the

/etc/X11/xorg.conf

file. Changing the information in the other sections is similar.

N OT E

Refer to the xorg.conf man pages for a complete description of the xorg.conf

file. The xorg.conf man pages are included with every installation

of Fedora Core or Enterprise Linux and are an excellent resource that provides

great detail about the xorg.conf file. To access the xorg.conf man page type man xorg.conf

at a terminal prompt.

Summary

In this chapter you learned about configuring the X server on your system. First you looked at using the graphical X configuration tool to make changes to the

X server configuration file. Then you looked at the configuration file itself and how to change some settings manually. Finally, you learned that the best place to get complete details about the xorg.conf file is the xorg.conf man pages.

15_599496 ch09.qxd 8/30/05 6:23 PM Page 216

16_599496 ch10.qxd 8/30/05 6:22 PM Page 217

C H A P T E R

10

Configuring

Printers

IN THIS CHAPTER

■■

■■

■■

Configuring Printers with the Printer Configuration Tool

Editing the Printer Configurations

Managing Print Jobs

In this chapter you learn how to successfully configure and manage your system printers. Included with Fedora Core and Red Hat Enterprise Linux is the

Printer Configuration tool to help you configure your printing system. The

Printer Configuration tool is an easy-to-use, graphical tool that will help you to set up whatever type of printer you choose.

After your printer is configured, you might want to gather information about jobs that you sent to the printer. You will also want to be able to change print job priority, see the contents of your print queue, and maybe even delete some of your scheduled print jobs. You will be able to do all these functions after going through this chapter.

Configuring Printers with the

Printer Configuration Tool

Because the Printing Configuration tool is a graphical-based utility, you can start it by choosing it from the Applications menu. To start the Printer Configuration tool, follow these steps:

1. In Enterprise Linux choose Applications ➪ System Settings ➪ Printing.

In Fedora Core 4 choose Desktop ➪ System Settings ➪ Printing.

217

16_599496 ch10.qxd 8/30/05 6:22 PM Page 218

218 Chapter 10

N OT E

If you aren’t logged in as the root user, the system prompts you for the root password before you can continue.

2. Type the root password, if necessary. The Printer Configuration tool opens, as shown in Figure 10-1.

3. Click the New button in the main Printer Configuration tool window.

The window shown in Figure 10-2 appears.

4. Click the Forward button. The Queue Name screen appears, as shown in Figure 10-3.

5. Enter a unique name for the printer in the Name text field. Choose a descriptive name for your printer, and follow these parameters:

■■

The printer name must begin with a letter and can’t contain spaces.

■■

You can use any valid characters for the remainder of the printer name. The valid characters are lowercase and uppercase letters a through z, numeral 0 through 9, – (dash), and _ (underscore).

■■

If you want, you can enter a description for the printer in the Short

Description field.

Figure 10-1 The Printer Configuration tool.

Figure 10-2 The Add a new print queue window.

16_599496 ch10.qxd 8/30/05 6:22 PM Page 219

Configuring Printers 219

6. When you finish entering a name for your printer, click Forward. The

Queue Type window appears, as shown in Figure 10-4, and the Printer

Configuration tool attempts to detect your printer.

The following sections detail the various possibilities available for configuring your print queue and selecting your print driver.

Configuring the Print Queue

You can configure six types of print queues. A print queue is a directory that holds the print jobs for the type of printer that you configure to work with the queue. The print queue is associated with the type of printer that you want to configure. At the top of the Queue Type window is a drop-down list containing the six types of print queues that you can configure. The queue type is set to Locally-Connected by default. If the printer is connected locally — that is, to either the parallel or the USB port on the PC, and is also recognized — it is shown in the list.

Figure 10-3 The Queue name window.

Figure 10-4 The Queue type window.

16_599496 ch10.qxd 8/30/05 6:22 PM Page 220

220 Chapter 10

The following list shows the six types of queue that you can install; to choose one, select the type that you desire from the drop-down list.

■■

Locally-Connected

— A printer attached directly to your computer through a parallel or USB port. If your printer isn’t listed, click the Custom Device button, type the name of your printer, and then click OK to add it to the printer device list. A printer attached to the parallel port is usually referred to as /dev/lp0. A printer attached to the USB port is usually referred to as /dev/usblp0.

N OT E

When you set up a locally connected printer it is set up as a local CUPS printer that only the localhost can use. If you want to use the printer on your

local network you need to modify the /etc/cups/cupsd.conf file to allow

other systems on your network to access the printer.

■■

Networked CUPS (IPP)

— A printer that can be accessed over a

TCP/IP network. The Common Unix Printing System (CUPS) is based on the Internet Printing Protocol (IPP), which was created in an attempt to set some standards for printing over the Internet. If you choose this type of queue, you need to enter the server name and the path to the server. Figure 10-5 shows the Networked CUPS queue dialog box.

■■

Networked UNIX (LPD)

— 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). If you choose this type of queue, you need to enter the server name and path to the server, as shown in Figure 10-6.

Figure 10-5 The Networked CUPS (IPP) screen is where you enter the server name and path.

16_599496 ch10.qxd 8/30/05 6:22 PM Page 221

Configuring Printers 221

Figure 10-6 Enter the server and queue for a networked UNIX (LPD) printer.

■■

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 lpr printing features.

LPR is an older printing protocol used by many UNIX systems.

N OT E

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.

■■

Networked Windows (SMB)

— A printer attached to a different system that shares a printer over an SMB network (for example, a printer attached to a Microsoft Windows machine). The Server Message Block

(SMB) protocol is the native protocol that computers running Windows use to communicate with each other. See Figure 10-7.

On this screen, you see a list of shares from which you can select the networked Windows printer that you want to use. To the left of the share name is an arrow that you can click to expand the share listing and show any configured printers. Figure 10-7 shows the RHL10 share expanded and also lists three printers. Click the printer that you wish to use and then click Forward. An Authentication screen appears, as shown in Figure 10-8.

16_599496 ch10.qxd 8/30/05 6:22 PM Page 222

222 Chapter 10

Figure 10-7 Configuring the Networked Windows (SMB) printer screen.

Figure 10-8 The Authentication screen for connecting to a SMB printer.

Text fields for the following options appear as shown in Figure 10-8:

■■

Workgroup — The name of your Windows workgroup needs to be entered here.

■■

Server — The name of the print server needs to be entered here.

■■

Share — This is 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 print server.

■■

User Name — This is the name by which you must log in 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.

■■

Password — The password (if required) for the user specified in the

User Name field.

■■

Networked Novell (NCP)

— A printer attached to a different system that uses the Novell NetWare networking technology. After choosing this type of queue, you need to enter additional information into the

Queue Type window, as shown in Figure 10-9.

16_599496 ch10.qxd 8/30/05 6:22 PM Page 223

Configuring Printers 223

You need to enter information for the following fields in Figure 10-9:

■■

Server — The host name 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 by which you must log in to access the printer.

■■

Password — The password for the user specified in the User field.

■■

Networked JetDirect

— A printer connected directly to the network through HP JetDirect instead of to a computer. (See Figure 10-10.)

You need to enter the appropriate information for the following text fields:

■■

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

Figure 10-9 Configuring a networked Novell (NCP) printer.

Figure 10-10 Configuring a networked JetDirect printer.

16_599496 ch10.qxd 8/30/05 6:22 PM Page 224

224 Chapter 10

N OT E

Whenever you add a new print queue or change an existing one, you must restart the printer daemon for the changes to take effect. See the upcoming “Editing the Printer Configuration” section. In case you are wondering what a daemon is, it means disk and execution monitor. It is basically a program that runs in the background, waiting for some event to occur. In this case, the printer daemon is waiting for print jobs.

Selecting the Print Driver

The next step in configuring a printer is to select the print driver. The print dri-

ver processes the data that you want to print into a format that the printer can understand.

1. After you select the queue type of the printer and enter the required information, click Forward to go to the Printer Model window, shown in Figure 10-11.

2. Select the driver from the list.

a. Click the arrow beside the manufacturer for your printer.

b. Find your printer from the expanded list, and then click the arrow beside the printer’s name. A list of drivers for your printer appears.

The printers are listed by manufacturer.

c. Select one appropriate for your printer. Sometimes you might need to try several of the listed drivers to find one that works properly.

Figure 10-11 Select the printer manufacturer and model.

16_599496 ch10.qxd 8/30/05 6:22 PM Page 225

Configuring Printers 225

N OT E

To read more about the print drivers, go to www.linuxprinting.org

/printer_list.cgi

. 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 Printer Driver tab, selecting a different print driver, and applying the changes.

3. Click Forward to go to the printer information confirmation page where you can verify your printer configuration choices.

a. Click Apply to add the print queue if the settings are correct.

b. Click Back to modify the printer configuration if necessary.

4. Click the Apply button in the main window to save your changes to the printer configuration file and restart the printer daemon (lpd), or click

Back to modify the printer configuration if necessary. Be sure to test your configuration by printing a test page.

Editing the Printer Configuration

After adding your printer(s), you can edit settings by selecting the printer from the printer list after opening the Printer Configuration tool and then clicking the Edit button. The tabbed window shown in Figure 6-12 appears. The window contains the current values for the printer that you selected to edit. Make any changes and click OK. Then click Apply in the main Printer Configuration tool window to save the changes and restart the printer daemon.

Figure 10-12 The Edit a print queue screen.

16_599496 ch10.qxd 8/30/05 6:22 PM Page 226

226 Chapter 10

The tabs and what they hold are as follows:

■■

■■

■■

■■

Queue Name

— To rename a printer, change the value of Name on the

Queue Name tab. Click OK to return to the main window. The name of the printer changes in the printer list. Click Apply to save the change and restart the printer daemon.

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 options. Refer to the section of this chapter that describes your particular printer; options unique to your printer are listed there.

Queue Options

— From the Queue Options tab, you can select banner pages before and after your print job. You can also set the printable area of the page. To modify filter options, highlight the option and click Edit to modify or click Delete to remove it. Click OK to accept your changes and return to the main window. Click Apply to save the change and restart the printer daemon.

Printer Driver

— The Printer Driver tab shows which print driver is currently being used. This is the same list that you use when you add the printer. If you change the print driver, click OK to accept your changes and return to the main window. Then click Apply to 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 the preceding bullet on the Send Form-Feed (FF) option.

■■

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 assumes that any data it cannot recognize is text and tries to print it as text. If you select this option and the Convert Text to PostScript option, the

16_599496 ch10.qxd 8/30/05 6:22 PM Page 227

Configuring Printers 227

print driver assumes that the unknown data is text and then converts it to PostScript.

■■

Select Prerender PostScript if you are trying to print characters outside of the basic ASCII character set (such as foreign language characters) that won’t print correctly. If your printer doesn’t support the fonts you are trying to print, try selecting this option. 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 deselecting 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.

Then click Apply to save the changes and restart the printer daemon.

Deleting a Printer

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.

Setting the Default Printer

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.

Managing Print Jobs

Whenever you print a document or image, the Print Notifier automatically opens and an icon appears on the panel at the top of the desktop. See Figure

10-13 to find out what the icon looks like.

You can open the Print Notifier by clicking the panel icon to open the window shown in Figure 10-14.

16_599496 ch10.qxd 8/30/05 6:22 PM Page 228

228 Chapter 10

Figure 10-13 The Print Notifier icon on the top panel.

Figure 10-14 The Print Notifier window.

You can see a list of your print jobs and their status. You can choose a job by clicking it and then either right-click or choose Edit from the top menu. This will let you pause the selected job, delete the selected job, or resume printing a previously paused job.

Summary

In this chapter you learned about the Printer Configuration tool. With this tool you can configure many different types of printers for use on your system. You saw the procedure to add a printer, select a print queue, and choose the proper driver for your printer. You also learned how to modify an existing printer configuration and manage jobs that you sent to the printer.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 229

C H A P T E R

11

TCP/IP

Networking

IN THIS CHAPTER

■■

■■

■■

■■

■■

■■

■■

■■

TCP/IP Explained

Understanding Network Classes

Setting Up a Network Interface Card (NIC)

Understanding Subnetting

Working with Gateways and Routers

Configuring Dynamic Host Configuration Protocol

Configuring the Network Using the Network Configuration Tool

Editing Your Network Configuration

This chapter provides an overview of the TCP/IP protocols as they apply to networking with Fedora Core and Red Hat Enterprise Linux. TCP/IP is complex, and many books have been written on this topic alone. If you want to learn more about TCP/IP, a good place to start is to use one of the Internet search engines to search for this topic on the Internet. After giving a description of TCP/IP, this chapter explains how to configure such a network in a Red

Hat environment.

TCP/IP Explained

TCP/IP is an acronym for Transmission Control Protocol/Internet Protocol, and refers to a family of protocols used for computer communications. TCP and IP are just two of the separate protocols contained in the group of protocols developed by the Department of Defense, sometimes called the DoD

Suite, but more commonly known as TCP/IP.

229

17_599496 ch11.qxd 8/30/05 6:44 PM Page 230

230 Chapter 11

In addition to Transmission Control Protocol and Internet Protocol, this family also includes Address Resolution Protocol (ARP); Domain Name System

(DNS); Internet Control Message Protocol (ICMP); User Datagram Protocol

(UDP); Routing Information Protocol (RIP); Simple Mail Transfer Protocol

(SMTP); Telnet, and many others. These protocols provide the necessary services for basic network functionality, and you will take a closer look at them for a better understanding of how the network works.

To be able to send and receive information on the network, each device connected to it must have an address. The address of any device on the network must be unique and have a standard, defined format by which it is known to any other device on the network. This device address consists of two parts:

■■

The address of the network to which the device is connected

■■

The address of the device itself — its node or host address

Devices that are physically connected to each other (not separated by routers) would have the same network number but different node, or host, numbers.

This would be typical of an internal network at a company or university. These types of networks are now often referred to as intranets.

The two unique addresses I’ve been talking about are typically called the

network layer addresses and the Media Access Control (MAC) addresses. Network Layer addresses are IP addresses that have been assigned to the device.

The MAC address is built into the card by the manufacturer and refers to only the lowest-level address by which all data is transferred between devices.

Now that you know a little about addressing, you need to learn how the address, and also the data, is transmitted across the network. This transfer is accomplished by breaking the information into small pieces of data called packets or datagrams. Why is it necessary to use packets instead of just sending the entire message as one long stream of data? There are two reasons for this — sharing resources and error correction.

Let’s look at the first, sharing resources. If two computers are communicating with each other, the line is busy. If these computers were sharing a large amount of data, other devices on the network would be unable to transfer their data. When long streams of data are broken into small packets, each packet is sent individually, and the other devices can send their packets between the packets of the long stream. Since each packet is uniquely addressed and has instructions on how to reassemble it, it does not matter the order that it arrives in or that it arrives in small pieces.

The second reason for breaking the data into packets is error correction.

Because the data is transmitted across media that is subject to interference, the data can become corrupt. One way to deal with the corruption is to send a checksum along with the data. A checksum is a running count of the bytes sent in the message. The receiving device compares its total to the total transmitted.

If these numbers are the same, the data is good; but if they are different, either

17_599496 ch11.qxd 8/30/05 6:44 PM Page 231

TCP/IP Networking 231

the checksum or the data itself is corrupt. The receiving device then asks the sender to resend the data. By breaking the data into small packets, each with its own checksum, it is easier to ensure that a good message arrives, and if not, only a small portion needs to be resent instead of the entire message.

In the description of packets, I mentioned unique addressing and reassembly instructions. Because packets also contain data, each is made up of two parts, the header, which contains the address and reassembly instructions, and the body, which contains the data. Keeping all this information in order is the

protocol. The protocol is a set of rules that specifies the format of the package and how it is used.

Understanding Network Classes

As stated earlier, all addresses must have two parts, the network part and the node, or host, part. In this section you look at Ipv4 addresses. Ipv4 addresses used in TCP/IP networks are 4 bytes long, called IP addresses, and are written in standard dot notation, which means that a decimal number separated by dots (for example, 192.168.1.2). The decimal numbers must be within the numeric range of 0 to 255 to conform to the 1-byte requirement. IP addresses are divided into classes with the most significant being classes A, B, and C, depending on the value of the first byte of the address. Table 11-1 shows valid numbers for these classes.

The reason for the class division is to enable efficient use of the address numbers. If the division were the first 2 bytes to the network part, as shown in

Table 11-1, and the last 2 bytes to the host part, then no network could have more than 2

16 hosts. This would be impractical for large networks and wasteful for small networks.

There are a few ways to assign IP addresses to the devices, depending on the purpose of the network. If the network is internal, an intranet, not connected to an outside network, any class A, B, or C network number can be used. The only requirement is choosing a class that allows for the appropriate number of hosts to be connected. Although this is possible, in the real world this approach would not allow for connecting to the Internet.

Table 11-1 Network Classes and Their IP Number Range

CLASS FIRST BYTE

Class A

Class B

Class C

0–127

128–191

192–233

17_599496 ch11.qxd 8/30/05 6:44 PM Page 232

232 Chapter 11

A more realistic approach would be to register with one of the domain registration services and request an officially assigned network number. An organization called the InterNIC maintains a database of all assigned network numbers to ensure that each assignment is unique. After obtaining a network number, the host numbers may be assigned as required. Nearly all IP devices require manual configuration; you will look at assigning IP addresses later when you actually set up your own network. You have now seen that each device has a unique network and node address, which is called an IP address.

Earlier, this was described as the Network Layer address. You also read about the Media Access Control, or MAC, address. The MAC address was defined as the lowest level at which communication occurs. On an Ethernet network, this address is also called the Ethernet address. This is the address that is ultimately necessary for transmission of data. For transfer to happen, the IP address must be mapped to the Ethernet address of the device. The mechanism that makes this possible is Address Resolution Protocol, or ARP.

To determine the Ethernet address of a node on the same network, the sending device sends an ARP request to the Ethernet broadcast address. The Ethernet broadcast address is a special address to which all Ethernet cards are configured to “listen.” The ARP request, containing the sender’s IP and Ethernet addresses, as well as the IP address it is looking for, asks each device for the

Ethernet address that corresponds to a particular IP address. The device whose address matches the request sends a reply to the sender’s Ethernet address.

The sender is then able to send its data to the specific address it received in response to its ARP request. This process works for sending data between devices on the same network, but what about sending data to devices on different networks? For this you need a router.

Routers enable networks not physically connected to each other to communicate. A router must be connected physically to each network that wants to communicate. The sending node must be able to send its request to a router on its own network, and the receiving node must also be on a network connected to a router. The sending node sends its request to the router on its network.

This router is typically called the default gateway, and its address must be configured in the sending node’s configuration files. You will learn how to do this later in this chapter in the “Exploring Gateways and Routers” section.

The router receives the request from the sending node and determines the best route for it to use to transmit the data. The router has an internal program, called a routing table, which it uses to send the data, either to another router if the other network is not directly connected, or directly to the other network. If the destination network cannot be found in the routing table, then the packet is considered undeliverable and is dropped. Typically, if the packet is dropped, the router sends an ICMP Destination Unreachable message to the sender.

Routing tables can be manually configured or acquired dynamically. Manual

configuration means that it is necessary for whoever is setting up the router to

17_599496 ch11.qxd 8/30/05 6:44 PM Page 233

TCP/IP Networking 233

provide all the information about other networks and how to reach them. This method is impractical because of the size of the file required and constantly changing information.

Dynamic acquisition means that the router sends a message using the Routing Information Protocol (RIP) or Open Shortest Path First (OSPF) protocol.

These dynamic protocols enable routers to share details with other routers concerning networks and their locations.

Ultimately, the purpose of everything you have looked at so far — packets,

IP addresses, and routing — is to give users access to services such as printing, file sharing, and email.

You have had a brief look at the IP part of the TCP/IP family of protocols and have arrived at TCP. Transmission Control Protocol is encapsulated in IP packets and provides access to services on remote network devices. TCP is considered to be a stream-oriented reliable protocol. The transmission can be any size because it is broken down into small pieces, as you have already seen. Data that is lost is retransmitted, and out-of-order data is reordered. The sender is notified about any data that cannot be delivered. Typical TCP services are File Transfer

Protocol (FTP), Telnet, and Simple Mail Transfer Protocol (SMTP).

Setting Up a Network Interface Card (NIC)

Every Fedora Core and Red Hat Enterprise Linux distribution includes networking support and tools that can be used to configure your network. In this section you’ll learn how to configure a computer for connection to an internal and external network.

N OT E

This section tells you how to configure a network interface card from the command line by modifying the configuration files directly. If you would rather use a graphical based configuration utility, skip to the section titled,

“Configuring the Network with the Network Configuration Tool.”

Even if the computer is not connected to outside networks, internal network functionality is required for some applications. This address is known as the loopback device, and its IP address is 127.0.0.1. You should check that this network interface is working before configuring your network cards. To do this, you can use the ifconfig utility to get some information. If you type ifconfig at a console prompt, you will be shown your current network interface configuration. Figure 11-1 illustrates the output of the ifconfig command.

T I P

Make sure that the loopback (IP address 127.0.0.1) is working before you begin to configure your network cards.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 234

234 Chapter 11

Figure 11-1 The ifconfig utility shows the current network interface configuration.

If your loopback is configured, the ifconfig shows a device called lo with the address 127.0.0.1. If this device and address are not shown, you can add the device by using the ifconfig command as follows: ifconfig lo 127.0.0.1

You then need to use the route command to give the system a little more information about this interface. For this, type: route add -net 127.0.0.0

You now have your loopback set up, and the ifconfig command shows the device lo in its listing.

Configuring the Network Card

The procedure for configuring a network card is the same as that for configuring the loopback interface. You use the same command, ifconfig, but this time use the name ‘eth0’ for an Ethernet device. You also need to know the

IP address, the net mask, and the broadcast addresses. These numbers vary, depending on the type of network being built. For an internal network that never connects to the outside world, any IP numbers can be used; however, there are IP numbers typically used with these networks. Table 11-2 shows the

IP numbers that are usually used for such networks.

N OT E

The network interface card (NIC), if already installed, is detected and configured during system installation. You should check to determine whether your card is already configured before following the configuration instructions in

this section. Use the ifconfig command to see the configured network cards.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 235

TCP/IP Networking 235

Table 11-2 Reserved Network Numbers

NETWORK CLASS NET MASK

A

B

C

255.0.0.0

255.255.0.0

255.255.255.0

NETWORK ADDRESSES

10.0.0.0–10.255.255.255

172.16.0.0–172.31.255.255

192.168.0.0–192.168.255.255

If you are connecting to an existing network, you must have its IP address, net mask, and broadcast address. You also need to have the router and domain name server (DNS) addresses.

In this example, you configure an Ethernet interface for an internal network.

You need to issue the following command: ifconfig eth0 192.168.2.5 netmask 255.255.255.0 broadcast 192.168.2.255

This results in the creation of device eth0 with a network address of

192.168.2.5

, a net mask of 255.255.255.0, and a broadcast address of

192.168.2.255

. A file is created in /etc/sysconfig/network-scripts called ifcfg-eth0. A listing of this file, shown in Figure 11-2, shows the information that you just entered. The line onboot=yes tells the kernel to configure this device at system startup. The line bootproto=static means that the IP address was manually entered for the NIC. If you desire, you can use Dynamic Host Configuration Protocol, or DHCP, to obtain the require IP information for your NIC.

N OT E

If you want to use DHCP to obtain the required IP information for your

NIC, see the section “Configuring Dynamic Host Configuration Protocol” later in this chapter.

Configuring an Internal Network

Now you have a network device configured for one computer. To add additional computers to your network, you need to repeat this process on the other computers you want to add. The only change is that you need to assign a different IP address. For example, the second computer on your network could have the address 192.168.2.6, the third could have 192.168.2.7, and so on.

N OT E

This section does not cover the physical requirements for building a network — cabling, hubs, and so forth. A good source for this information is

Network Plus

by David Groth (ISBN 0-7821-4014-9, published by Sybex).

17_599496 ch11.qxd 8/30/05 6:44 PM Page 236

236 Chapter 11

Figure 11-2 The configuration file for the network device eth0.

In addition to configuring the network cards on each of the computers in the network, three files on each computer need to be modified. These files are all located in the /etc directory:

■■

/etc/nsswitch.conf

■■

/etc/hosts

■■

/etc/resolv.conf

■■

/etc/sysconfig/network

The /etc/nsswitch.conf file contains configuration information for the name resolver and should contain the following line: hosts: files dns

This configuration tells the name resolver to check the /etc/hosts file before attempting to query a name server and to return all valid addresses for a host found in the /etc/hosts file instead of just the first.

The /etc/hosts file could contain the names of all the computers on the local network, or an outside network. For a small network, maintaining this file is not difficult, but for a large network, like the Internet, keeping the file up to date is often impractical. Figure 11-3 shows my home network, containing several computers. The first address represents the current system, and the other addresses represent other computers on the network.

The /etc/resolv.conf file provides information about name servers employed to resolve hostnames. Figure 11-4 shows a typical resolv.conf

file listing.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 237

TCP/IP Networking 237

Figure 11-3 The /etc/hosts file contains a listing of the computers on a network.

Figure 11-4 The /etc/resolv.conf file contains a listing of the domain and name servers on the network.

C R O S S - R E F E R E N C E

Chapter 14 discusses Domain Name Servers (DNS).

The /etc/sysconfig/network file contains two lines, as follows:

NETWORKING=yes

HOSTNAME=(host and domain name of your system)

The first line enables networking for your system. The second line displays the hostname of your system and the name of the domain to which it belongs.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 238

238 Chapter 11

Understanding Subnetting

You have learned how easy it is to build an internal network, but now you need to learn how to connect to the outside world. A few more steps accomplish outside connection, including configuring a router, obtaining an IP address, and actually making the connection. You begin with obtaining an IP address and subnetting.

Earlier in this chapter you saw that IP addresses used on the Internet are assigned by the InterNIC. Now you will take a closer look at the makeup of IP addresses and how they can be extended through subnetting.

IP numbers are not assigned to hosts; they are assigned to network interfaces on hosts. Even though many computers on an IP network have a single network interface and a single IP number, a single computer can have more than one network interface. In this case, each interface would have its own IP number.

T I P

It is also possible to assign more than one IP address to a single NIC. This

is accomplished by using the ifconfig and route commands. To add another

IP address, 192.168.1.4, to eth0 issue these commands: ifconfig eth0:1 192.168.1.4

route add -host 192.168.1.4 dev eth0

The first command binds the IP address to the virtual interface eth0:1, and the

second command adds a route for the address to the actual device eth0.

Another method for adding a second IP address to a single NIC is to create an

alias file. The configuration file for device eth0 is located in /etc/sysconfig

/network-scripts/ifcfg-eth0

. Copy this file to another file called /ifcfgeth0:1

in the same directory. Open the newly copied file and change the line that reads:

DEVICE=eth0

to read:

DEVICE=eth0:1

N OT E

If you create an alias for your NIC, you cannot use DHCP to obtain your

IP information. You must assign static IP addresses to the devices.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 239

TCP/IP Networking 239

Even though this is true, most people refer to host addresses when referring to an IP number. Just remember, this is simply shorthand for the IP number of this particular interface on this host. Many devices on the Internet have only a single interface and thus a single IP number.

In the current (IPv4) implementation, IP numbers consist of 4 (8-bit) bytes for a total of 32 bits of available information. This system results in large numbers, even when they are represented in decimal notation. To make them easier to read and organize, they are written in what is called dotted quad format.

The numbers you saw earlier in this chapter were expressed in this format, such as the internal network IP address 192.168.1.1. Each of the four groups of numbers can range from 0 to 255. The following shows the IP number in binary notation with its decimal equivalent. If the bit is set to 1 it is counted, and if set to zero it is not counted.

1 + 1 + 1 + 1 + 1 + 1 + 1 + 1

128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 = 255

The binary notation for 192.168.1.1 is:

11000000.10101000.00000001.00000001

The dotted quad notation from this binary is:

(128+64) . (128+32+8).(1).(1) = 192.168.1.1

The leftmost bits of the IP number of a host identify the network on which the host resides; the remaining bits of the IP number identify the network interface. Exactly how many bits are used by the network ID and how many are available to identify interfaces on that network is determined by the network class. Earlier you learned that there are three classes of networks, and you saw how they are composed in Table 11-1.

Class A IP network numbers use the left quad to identify the network, leaving three quads to identify host interfaces on that network. Class A addresses always have the farthest left bit of the farthest left byte a zero, so there is a maximum of 128 class A network numbers available, with each one containing up to 33,554,430 possible interfaces.

The network numbers 0.0.0.0, known as the default route, and 127.0.0.0, the loopback network, have special meanings and cannot be used to identify networks. You saw the loopback interface when you set up your internal network.

You’ll look at the default route when you set up your connection to the Internet. So if you take these two network numbers out, there are only 126 available class A network numbers.

Class B IP network numbers use the two left dotted quads to identify the network, leaving two dotted quads to identify host interfaces. Class B addresses

17_599496 ch11.qxd 8/30/05 6:44 PM Page 240

240 Chapter 11

always have the farthest left bits of the left byte set to 10. This leaves 14 bits left to specify the network address giving 32,767 available B class networks. Class

B networks have a range of 128 to 191 for the first of the dotted quads, with each network containing up to 32,766 possible interfaces.

Class C IP network numbers use the left three quads to identify the network, leaving the right quad to identify host interfaces. Class C addresses always start with the farthest left three bits set to 1 1 0 or a range of 192 to 255 for the farthest left dotted quad. This means that there are 4,194,303 available Class C network numbers, each containing 254 interfaces.

IP addresses are also set aside for internal networks, as you saw in Table 11-2.

Interpreting IP Numbers

IP numbers can have three possible meanings. The first of these is an address of a network, which is the number representing all the devices that are physically connected to each other. The second is the broadcast address of the network, which is the address that enables all devices on the network to be contacted. Finally, the last meaning is an actual interface address. Look at a

Class C network for an example. For a Class C network:

■■

192.168.3.0 is a Class C network number.

■■

■■

192.168.3.42 is a host address on this network.

192.168.3.255 is the network broadcast address.

When you set up your Ethernet device, eth0, you used the ifconfig utility to pass some information that was written to the ifcg-eth0 file. One of these parameters was the network mask. The network mask is more properly called the subnetwork mask. However, it is generally referred to as the network mask, or

subnet mask. The determining factor in subnetting is the network mask and how it is understood on a local network segment. In setting up your network card, you used a net mask of 255.255.255.0. In this case, all the network bits were set to one and the host bits were set to zero. This is the standard format for all network masks. Table 11-2 shows the network masks for the three classes of networks.

You should remember two important things about the network mask. The network mask affects only the interpretation of IP numbers on the same network segment, and the network mask is not an IP number; it is used to modify the way IP numbers are interpreted by the network.

N OT E

The network mask affects only the interpretation of IP numbers on the same network segment.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 241

TCP/IP Networking 241

A subnet enables you to use one IP address and split it up so that it can be used on several physically connected local networks. This is a tremendous advantage, as the number of IP numbers available is rapidly diminishing. You can have multiple subnetted networks connected to the outside world with just one IP address. By splitting the IP address, it can be used on sites that need multiple connections; splitting the address eliminates the problems of high traffic and difficult manageability.

The other advantages to subnetting are that different network topologies can exist on different network segments within the same organization, and overall network traffic is reduced. Subnetting also enables increased security by separating traffic into local networks. There is a limit to the number of subnets that can be created based on the number of times a given number can be divided. Tables 11-3, 11-5, and 11-6 show the possible numbers of subnets and hosts that can exist.

Before You Subnet Your Network

Before you can subnet your network, you need to make some choices and gather some information.

N OT E

The information in this section explains the concepts of subnetting a network and does not give actual details about the procedure to follow should you decide to subnet your network.

First, you need to decide the number of hosts on each of your subnets so that you can determine how many IP addresses you need. Earlier in this chapter you set up an Ethernet interface using the reserved internal Class C network number 192.168.1.0. You will continue to use this number for the subnetting example.

Every IP network has two addresses that cannot be used — the network IP number itself and the broadcast address. Whenever you subnetwork the IP network you are creating additional addresses that are unusable. For each subnet you create, two addresses are unusable, the subnet’s network IP address and its broadcast address. Every time you subnet you are creating these two unusable addresses, so the more subnets you have, the more IP addresses you lose. The point is that you don’t subnet your network more than necessary.

T I P

Don’t subnet your network more than necessary.

Next, you need to determine the subnetwork mask and network numbers.

The network mask for an IP network without subnets is simply a dotted quad that has all the network bits of the network number set to 1 and all the host bits set to 0.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 242

242 Chapter 11

So, for the three classes of IP networks, the standard network masks are shown in Table 11-2.

Subnetworking takes one or more of the available host bits and makes them appear as network bits to the local interfaces. If you wanted to divide your

Class C network into two subnetworks, you would change the first host bit to one, and you would get a net mask of 11111111.11111111.11111111.10000000, or

255.255.255.128. This would give you 126 possible IP numbers for each of your subnets. Remember that you lose two IP addresses for each subnet. If you want to have four subnetworks, you need to change the first two host bits to ones, and this would give you a net mask of 255.255.255.192. You would have

62 IP addresses available on each subnetwork. Table 11-3 shows the subnets, the subnet masks, and the available hosts for your Class C network.

Now all you need to do is assign the appropriate numbers for the network, the broadcast address, and the IP addresses for each of the interfaces and you’re nearly done. Table 11-4 shows these numbers for subnetting your Class

C network into two subnets.

To create subnets for Class A and B networks, you follow the same procedure as that shown for Class C networks. Table 11-5 shows the subnets for a

Class A network, and Table 11-6 shows the subnets for a Class B network.

5

6

3

4

Table 11-3 Class C Subnets and Subnet Masks

NUMBER

OF BITS

NUMBER OF

SUBNETS

SUBNET MASK

1*

2

2

4

255.255.255.128

255.255.255.192

8

16

32

64

255.255.255.224

255.255.255.240

255.255.255.248

255.255.255.252

6

2

30

14

NUMBER OF

HOSTS

126

62

Table 11-4 Creating Two Subnets for a Class C Network Address

NETWORK

192.168.1.0

NET MASK BROADCAST FIRST IP

255.255.255.128

192.168.1.127

192.168.1.1

LAST IP

192.168.1.126

192.168.1.128

255.255.255.128

192.168.1.255

192.168.1.129 192.168.1.254

17_599496 ch11.qxd 8/30/05 6:44 PM Page 243

TCP/IP Networking 243

20

21

22

16

17

18

19

12

13

14

15

8

9

10

11

6

7

4

5

Table 11-5 Class A Subnets and Subnet Masks

NUMBER

OF BITS

NUMBER OF

SUBNETS

SUBNET MASK

2

3

2

6

255.192.0.0

255.224.0.0

14

30

62

126

255.240.0.0

255.248.0.0

255.252.0.0

255.254.0.0

254

510

1022

2046

4094

8190

16382

32766

255.255.0.0

255.255.128.0

255.255.192.0

255.255.224.0

255.255.240.0

255.255.248.0

255.255.252.0

255.255.254.0

65534

131070

262142

524286

1048574

2097150

4194302

255.255.255.0

255.255.255.128

255.255.255.192

255.255.255.224

255.255.255.240

255.255.255.248

255.255.255.252

14

6

2

254

126

62

30

65534

32766

16382

8190

4094

2046

1022

510

NUMBER OF

HOSTS

4194302

2097150

1048574

524286

262142

131070

Table 11-6 Class B Subnets and Subnet Masks

NUMBER

OF BITS

NUMBER OF

SUBNETS

SUBNET MASK

2

3

4

2

6

14

255.255.192.0

255.255.224.0

255.255.240.0

NUMBER OF

HOSTS

16382

8190

4094

(continued)

17_599496 ch11.qxd 8/30/05 6:44 PM Page 244

244 Chapter 11

9

10

11

12

13

14

Table 11-6 (continued)

NUMBER

OF BITS

NUMBER OF

SUBNETS

7

8

5

6

30

62

126

254

510

1022

2046

4094

8190

16382

SUBNET MASK

255.255.248.0

255.255.252.0

255.255.254.0

255.255.255.0

255.255.255.128

255.255.255.192

255.255.255.224

255.255.255.240

255.255.255.248

255.255.255.252

6

2

30

14

510

254

126

62

NUMBER OF

HOSTS

2046

1022

Classless InterDomain Routing

Classless InterDomain Routing (CIDR) was invented several years ago to keep the Internet from running out of IP addresses. The class system of allocating IP addresses can be very wasteful. Anyone who could reasonably show a need for more than 254 host addresses was given a Class B address block of 65,533 host addresses. Even more wasteful was allocating companies and organizations Class A address blocks, which contain over 16 million host addresses!

Only a tiny percentage of the allocated Class A and Class B address space has ever been actually assigned to a host computer on the Internet.

People realized that addresses could be conserved if the class system was eliminated. By accurately allocating only the amount of address space that was actually needed, the address space crisis could be avoided for many years.

This solution was first proposed in 1992 as a scheme called supernetting. Under supernetting, the class subnet masks are extended so that a network address and subnet mask could, for example, specify multiple Class C subnets with one address. For example, if you needed about a thousand addresses, you could supernet four Class C networks together:

192.60.128.0 (11000000.00111100.10000000.00000000) Class C subnet address

192.60.129.0 (11000000.00111100.10000001.00000000) Class C subnet address

192.60.130.0 (11000000.00111100.10000010.00000000) Class C subnet address

192.60.131.0 (11000000.00111100.10000011.00000000) Class C subnet address

17_599496 ch11.qxd 8/30/05 6:44 PM Page 245

TCP/IP Networking 245

--------------------------------------------------------

192.60.128.0 (11000000.00111100.10000000.00000000) Supernetted Subnet address

255.255.252.0 (11111111.11111111.11111100.00000000) Subnet Mask

192.60.131.255 (11000000.00111100.10000011.11111111) Broadcast address

In this example, the subnet 192.60.128.0 includes all the addresses from

192.60.128.0 to 192.60.131.255. As you can see in the binary representation of the subnet mask, the network portion of the address is 22 bits long, and the host portion is 10 bits long.

Under CIDR, the subnet mask notation is reduced to simplified shorthand.

Instead of spelling out the bits of the subnet mask, the number of 1 bits that start the mask are simply listed. In the example, instead of writing the address and subnet mask as

192.60.128.0, Subnet Mask 255.255.252.0 the network address is written simply as

192.60.128.0/22

This address indicates the starting address of the network, and number of 1 bits (22) in the network portion of the address. If you look at the subnet mask in binary, you can easily see how this notation works.

(11111111.11111111.11111100.00000000)

The use of a CIDR-notated address is the same as for a class address. Class addresses can easily be written in CIDR notation (Class A = /8, Class B = /16, and Class C = /24).

It is currently almost impossible for you, as an individual or company, to be allocated your own IP address blocks. You will simply be told to get them from your ISP. The reason for this is the ever-growing size of the Internet routing table. Just five years ago, there were less than 5,000 network routes in the entire Internet. Today, there are over 100,000. Using CIDR, the biggest ISPs are allocated large chunks of address space, usually with a subnet mask of /19 or even smaller. The ISP’s customers, often other, smaller ISPs, are then allocated networks from the big ISP’s pool. That way, all the big ISP’s customers, and their customers, are accessible via one network route on the Internet.

CIDR will probably keep the Internet happily in IP addresses for the next few years at least. After that, IPv6, with 128-bit addresses, will be needed.

Under IPv6, even careless address allocation would comfortably enable a billion unique IP addresses for every person on earth! The complete details of

CIDR are documented in RFC1519, which was released in September 1993.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 246

246 Chapter 11

N OT E

Requests for Comment (RFCs) are documents containing information about computer networking and many areas of the Internet. If you want to

learn more about RFCs, check out ftp://ftp.rfc-editor.org/in-notes

/rfc2555.txt

.

Working with Gateways and Routers

You have successfully created two subnets from your Class C network, but the individual network segments cannot communicate with each other yet. You still have to configure a path for them; you do this by using a router. Earlier in this chapter, you learned that a router is necessary for separate networks to communicate with each other. You also learned that each network must be connected to a router in order for this communication to take place. This router connected to each network is called its gateway.

In Linux, you can use a computer with two network interfaces to route between two or more subnets. To be able to do this you need to make sure that you enable IP forwarding. All current Linux distributions have IP forwarding compiled as a module, so all you need to do is make sure the module is loaded.

You can check this by entering the following query at a command prompt: cat /proc/sys/net/ipv4/ip_forward

If forwarding is enabled, the number 1 is displayed; if forwarding is not enabled, the number 0 is displayed.

To enable IP forwarding if it is not already enabled, type the following command: echo “1” > /proc/sys/net/ipv4/ip_forward

Continue your setup using the two subnets you previously created with the information in Table 11-4.

Assume that a computer running Linux is acting as a router for your network. It has two network interfaces to the local LANs using the lowest available IP address in each subnetwork on its interface to that network. The network interfaces would be configured as shown in Table 11-7.

Table 11-7 Network Interface Configuration

INTERFACE IP ADDRESS

Eth0

Eth1

192.168.1.1

192.168.1.129

NET MASK

255.255.255.128

255.255.255.128

The network routing the system would use is shown in Table 11-8.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 247

TCP/IP Networking 247

Table 11-8 Network Routing Configuration

DESTINATION GATEWAY

192.168.1.0

192.168.1.128

192.168.1.1

192.168.1.129

MASK INTERFACE

255.255.255.128 eth0

255.255.255.128 eth1

You’re nearly finished now, just one more step. Each computer on the subnet has to show the IP address for the interface that is its gateway to the other network. The computers on the first subnet, the 192.168.1.0 network, would have the gateway 192.168.1.1. Remember that you used the first IP address on this network for the gateway computer. The computers on the second subnet,

192.168.1.128, would use 192.168.1.129 as the gateway address. You can add this information using the route command as follows: route add -net 192.168.1.0

and then type route add default gw 192.168.1.129

This command sets up the route for local (internal) routing and the external route for your first subnet. You need to repeat the previous commands, substituting the appropriate numbers for the second subnet and any additional subnets. You have now successfully set up two subnets and established communication between them. Next, you’ll look at automatic network address assignments.

Configuring Dynamic Host Configuration Protocol

So far, you have learned to configure a network card and assign it an IP address, subnet mask, broadcast address, and gateway. Using Dynamic Host

Configuration Protocol (DHCP), you can have an IP address and the other information automatically assigned to the hosts connected to your network.

This method is quite efficient and convenient for large networks with many hosts, because the process of manually configuring each host is quite timeconsuming. By using DHCP, you can ensure that every host on your network has a valid IP address, subnet mask, broadcast address, and gateway, with minimum effort on your part.

While not absolutely necessary, you should have a DHCP server configured for each of your subnets. Each host on the subnet needs to be configured as a

DHCP client. You may also need to configure the server that connects to your

ISP as a DHCP client if your ISP dynamically assigns your IP address.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 248

248 Chapter 11

Setting Up the Server

The program that runs on the server is dhcpd and is included as an RPM on the Fedora Core and Red Hat Enterprise Linux installation CDs. You can install it using the Package Management tool by following these instructions.

1. On Enterprise Linux choose Applications ➪ System Settings ➪

Add/Remove Applications from the top panel. On Fedora Core 4 choose Desktop ➪ System Settings ➪ Add/Remove Applications. The screen shown in Figure 11-5 appears.

2. Scroll down the list until you see a listing for Network Servers.

3. Click the Details link for Network Servers. The screen shown in Figure

11-6 appears.

4. Click Close; then click Update, and finally click Continue.

5. Insert the requested numbered installation CD when prompted and click OK.

6. After the package is installed, click Close to exit the Package Management tool.

Figure 11-5 Installing a package using the Package Management tool.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 249

TCP/IP Networking 249

Figure 11-6 Selecting the DHCP package for installation.

In Fedora Core and Red Hat Enterprise Linux the DHCP server is controlled by the text file /etc/dhcpd.conf. Listing 11-1 shows the configuration file for my system. Comment lines begin with a # sign.

#(The amount of time in seconds that the host can keep the IP address.) default-lease-time 36000;

#(The maximum time the host can keep the IP address.)

#domain name max-lease-time 100000;

# (The domain of the DHCP server.)

#nameserver option domain-name “tactechnology.com”; option domain-name-servers 192.168.1.1;

#gateway/routers, can pass more than one: option routers 1.2.3.4,1.2.3.5; option routers 192.168.1.1; (IP address of routers.)

#netmask (The subnet mask of the network.) option subnet-mask 255.255.255.0;

#broadcast address (The broadcast address of the network.) option broadcast-address 192.168.1.255;

#specify the subnet number gets assigned in subnet 192.168.1.0 netmask 255.255.255.0

#define which addresses can be used/assigned range 192.168.1.1 192.168.1.126;

Listing 11-1 The dhcpd.conf file.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 250

250 Chapter 11

A sample file is created when you install the dhcpd package that you can use as a guide. You can modify it using a text editor. Be sure to use the proper addresses for your network.

N OT E

You need to restart the DHCP server whenever you make changes to

the /etc/dhcpd.conf file.

To start the server, run the command service dhcpd start. To ensure that the dhcpd program runs whenever the system is booted, you should run the command chkconfig --level 35 dhcpd on.

Configuring the DHCP Client

First, you need to be sure that you NIC is properly configured and recognized by your system. After that, it is easy to tell your system to use DHCP to obtain its IP information. Follow these steps.

1. Using your favorite text editor, open the /etc/sysconfig/networkscripts/ifcfg-eth0 file.

2. Find the line bootproto=static.

3. Change static to dhcp.

4. Save your changes.

5. Restart the network by issuing the command service network

restart

, and your system will receive its IP information from the

DHCP server.

Configuring the Network Using the Network Configuration Tool

Fedora Core and Red Hat Enterprise Linux provide a graphical network configuration tool that you can use to configure network interface devices installed in your system. With this tool, you can configure Crypto IP Encapsulation

(CIPE), Ethernet, Integrated Services Digital Network (ISDN), modem, token ring, wireless, and xDSL. The x refers to different versions of Digital Subscriber

Loop (DSL) devices. In this chapter, I cover the most common types of devices:

Ethernet, modem, and wireless.

You can access the Network Configuration tool by using the Applications menu from the GNOME desktop. To start the Network Configuration tool in

Enterprise Linux choose Applications ➪ System Settings ➪ Network. In Fedora

Core 4 choose Desktop ➪ System Settings ➪ Network. The Network Configuration window, shown in Figure 11-7, appears.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 251

TCP/IP Networking 251

Figure 11-7 The Network Configuration tool main window.

The main Network Configuration tool window (shown in Figure 11-7) has five tabbed pages and opens to the Devices tab by default. Read on for a more detailed look at the five tabbed pages.

■■

Devices

— This tab shows the network devices that are installed and configured on your PC. Network devices are associated with the actual physical hardware in the PC.

N OT E

If you have a supported NIC installed on your system during installation of Red Hat Enterprise Linux, your NIC should already be listed in the Network

Configuration tool. Click the Hardware tab to see information about the device.

Figure 11-7 shows an Ethernet NIC with a wireless NIC already installed.

■■

Hardware

— This tab shows the actual physical hardware installed in your PC.

■■

IPSec

— This tab is where you can configure IPSec tunnels used for secure communications.

■■

DNS

— This tab shows the system hostname, domain, and name servers used for DNS lookups. You can configure this information here.

■■

Hosts

— This tab shows the PC hostname to static IP address mapping.

Adding an Ethernet Device

With the Network Configuration tool, you can easily add and configure your

Ethernet device. To add an Ethernet device, do the following:

17_599496 ch11.qxd 8/30/05 6:44 PM Page 252

252 Chapter 11

1. Click the New button from the toolbar of the Network Configuration tool main window. The Select Device Type window appears, as shown in Figure 11-8.

2. Choose Ethernet Connection from the Device Type list, and then click

Forward to go to the Select Ethernet Device list.

3. If your NIC is shown in the Select Ethernet Device list, select it and then click Forward to go to the Configure Network Settings window.

(See Figure 11-10.)

4. If your NIC is not listed, choose Other Ethernet Card and then click

Forward to open the Select Ethernet Adapter window, as shown in

Figure 11-9.

5. Select your card from the Adapter drop-down list.

6. Choose the device name from the Device drop-down list.

You should choose eth0 for the first device, eth1 for the second, eth2 for the third, and so on. You can also enter the system resources that the adapter will use, if desired. Usually, this is not necessary because the

OS automatically assigns resources to devices. But in the event that you need to control the resource assignments manually because of other hardware that you are using, you are able to do so.

7. Click Forward to continue to the Configure Network Settings window, as shown in Figure 11-10.

Figure 11-8 Select your network device here.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 253

TCP/IP Networking 253

Figure 11-9 The Select Ethernet Adapter window.

8. Choose whether you want to use DHCP to obtain your IP address automatically or whether you want to enter a static IP address.

Make your choice by selecting the appropriate radio button. If you choose to set your address statically, you must enter the IP address, the network mask, and the address of the default gateway. You can also enter a hostname for your PC, if you desire.

9. Click Forward.

You see a listing of your selected information.

Figure 11-10 The Configure Network Settings window.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 254

254 Chapter 11

10. (Optional) If you want to make changes, click Back to return to the desired window and make changes. If you are satisfied with your choices, click Apply to create the device.

After clicking Apply, the device is created and appears in the device list. Although the device has been configured and added to the list of devices, it is inactive, as you can see from the device listing. By default, the device will start at boot time, but you can activate it immediately by highlighting it and then clicking the Activate button from the menu bar at the top of the window.

11. Choose File ➪ Save from the menu to save your changes.

Adding a Wireless NIC

With the Network Configuration tool, you can easily add and configure your wireless NIC. To add a wireless NIC, do the following:

1. Click the New button from the toolbar of the Network Configuration tool main window. (Refer to Figure 11-7.)

The Select Device Type window appears. (Refer to Figure 11-8.)

2. Choose Wireless Connection from the Device Type list and then click

Forward to go to the Select Wireless Device list.

3. If your NIC is shown in the Select Wireless Device list, select it and click

Forward to go to the Configure Wireless Connection dialog box, as shown in Figure 11-11. If your NIC is not listed, go to Step 6.

Figure 11-11 The Configure Wireless Connection dialog box.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 255

TCP/IP Networking 255

4. In the Configure Wireless Connection dialog box, enter the appropriate information for your wireless connection as follows:

■■

Mode

— From the drop-down list, choose from:

Auto to have the system automatically determine the connection type

Managed to set your configuration to connect to a wireless access point

Ad-hoc if you will be connecting directly to other wireless NICs

■■

Network Name (SSID)

— Either select the Specified radio button and enter the name of your network here, or select the Auto radio button to have the system determine the name.

■■

Channel

— Enter the channel that your wireless network uses.

■■

Transmit Rate

— Choose Auto or a specific transmission rate for your network.

■■

Key

— If your network uses Wired Equivalent Privacy (WEP), enter the appropriate encryption key here.

5. After you enter your network information, click Forward to go to the

Configure Network Settings dialog box and continue with Step 10.

(Refer to Figure 11-10.)

6. If your NIC is not listed, choose Other Wireless Card and then click Forward to open the Select Ethernet Adapter window. (Refer to Figure 11-9.)

7. Select your card from the drop-down list in the Adapter field.

8. After choosing your card, choose the device name from the drop-down list in the Device field.

You should choose eth0 for the first device, eth1 for the second, eth2 for the third, and so on. You can also enter the system resources that the adapter will use, if desired. Usually, this is not necessary because the OS automatically assigns resources to devices. But in the event that you need to manually control the resource assignments because of other hardware you are using, you are able to do so.

9. Click Forward to continue to the Configure Wireless Connection dialog box. (Refer to Figure 11-11; see Step 4 for details on this dialog box.)

After entering your information, click Forward to go to the Configure

Network Settings window.

10. In the Configure Network Settings window, you can choose whether you want to use DHCP to obtain your IP address automatically or whether you want to enter a static IP address.

Make your choice by selecting the appropriate radio button. If you choose to set your address statically, you must enter the IP address, the network mask, and the address of the default gateway. You can also enter a hostname for your PC, if you desire.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 256

256 Chapter 11

11. After you make the appropriate entries, click Forward.

You see a listing of your selected information.

12. If you want to make changes, click Back to return to the desired window and make changes. If you are satisfied with your choices, click

Apply to create the device.

After clicking Apply, the device is created and appears in the Device list.

Although the device has been configured and added to the list of devices, it is inactive, as you can see from the device listing. By default, the device starts at boot time, but you can activate it immediately by highlighting it and then clicking the Activate button from the menu bar at the top of the window.

13. Choose File ➪ Save from the menu to save your changes.

Adding a Modem Connection

With the Network Configuration tool, you can easily add and configure your modem. To add a modem, do the following:

1. Click the New button on the toolbar.

2. Choose Modem Connection from the Device Type list, and then click

Forward.

The Configuration tool searches your system to try to detect a modem.

N OT E

If you have a modem installed in your system during installation your modem should already be listed in the Network Configuration tool. Click the

Hardware tab to see information about the device.

If you have a modem in your hardware list, the Configuration tool uses that modem and opens the Select Modem window, as shown in Figure

11-12, with values appropriate for the modem. If no modem is found, a message appears, stating that no modem was found and prompting you to click OK. After you click OK, the Select Modem dialog box appears, but the values might not be correct for the modem that you have installed.

3. If your modem was successfully found, you can accept the default values for modem device, baud rate, flow control, and modem volume; otherwise, enter the values appropriate for your modem.

4. When you are satisfied with the settings, click Forward to go to the

Select Provider window, as shown in Figure 11-13.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 257

TCP/IP Networking 257

Figure 11-12 The Select Modem dialog box.

5. Here you need to enter the name of your ISP and the telephone number that you dial to connect. Enter the login name and password that were given to you by your ISP. Unless you live in any of the countries listed, you can ignore the country list on the left.

6. Click Forward to go to the IP Settings window, as shown in Figure 11-14.

You can probably accept the default setting here to obtain IP addressing information automatically.

Figure 11-13 The Select Provider dialog box.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 258

258 Chapter 11

Figure 11-14 The IP Settings dialog box.

7. Click Forward to continue.

You see a listing of your selected information. If you want to make changes, click Back to return to the desired window and make changes.

If you are satisfied with your choices, click Apply to create the device.

The device is created and appears in the Device list. Although the device has been configured and added to the list of devices, it is inactive, as you can see from the device listing. By default, the device starts at boot time, but you can activate it immediately by highlighting it and then clicking the Activate button from the menu bar at the top of the window.

8. Choose File ➪ Save from the menu to save your changes.

Editing Your Network Configuration

After you add and configure your network connection device, whether it is a wired NIC, wireless NIC, or modem, you usually don’t need to change the configuration. You might need to modify the configuration, though, if you change to a different NIC.

Removing a NIC

Using the Network Configuration tool, you can easily make the necessary changes. Start the Network Configuration tool as follows:

17_599496 ch11.qxd 8/30/05 6:44 PM Page 259

TCP/IP Networking 259

1. In Enterprise Linux choose Applications ➪ System Settings ➪ Network.

In Fedora Core 4 choose Desktop ➪ System Settings ➪ Network.

2. Click the Hardware tab.

3. Highlight the device that you want to remove, and then click Delete.

4. When finished, choose File ➪ Save to save your changes.

Changing the NIC Configuration

Using the Network Configuration tool, you can easily make the necessary changes. Start the Network Configuration tool as follows:

1. In Enterprise Linux choose Applications ➪ System Settings ➪ Network.

In Fedora Core 4 choose Desktop ➪ System Settings ➪ Network.

2. Highlight the device that you want to modify, and then click Edit (on the toolbar).

The Ethernet Device properties dialog box for the device you selected, as shown in Figure 11-15, appears.

Figure 11-15 The Ethernet Device properties dialog box.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 260

260 Chapter 11

3. The three tabs available from this dialog box are used for the following:

■■

General

— Here you can enter a nickname for the device and choose whether the device is activated when the system starts. You can also choose to allow other users to be able to enable and disable the device. You can choose to obtain IP information automatically by using DHCP, or you can manually enter the IP information for the device.

N OT E

In most cases, you can accept the default setting and let the system obtain IP information using DHCP. If you need to use a static IP address, you can usually get the IP information from your system administrator. If you are the system administrator, you should know what IP information to use.

■■

Route

— Here you can enter static routes to other networks. You need to enter the network IP number as well as the gateway IP number. In most cases, you don’t need to enter any information here if you are using DHCP.

■■

Hardware Device

— This tab contains information about the hardware associated with the Ethernet device. You can assign device aliases here if you desire.

N OT E

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: a. Click the Add button in the Network Administration tool to create an alias for the device.

b. Select the network device and configure the network settings.

N OT E

The alias will appear in the device list with a device name, followed by a colon and the alias number.

4. After you make the changes you desire, click OK to return to the

Network Configuration dialog box.

5. Choose File ➪ Save to write your configuration changes to a file.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 261

TCP/IP Networking 261

Managing DNS Settings

The DNS tab of the Network Configuration tool is where you configure the system’s hostname, domain, name servers, and search domain. Name servers are used to look up other hosts on the network. To enter or change these settings, do the following:

1. In Enterprise Linux choose Applications ➪ System Settings ➪ Network.

In Fedora Core 4 choose Desktop ➪ System Settings ➪ Network.

2. Click the DNS tab from the Network Configuration dialog box.

3. On the DNS tab, enter the appropriate information for your system.

4. After you finish, choose File ➪ Save to save your changes.

N OT E

The Nameservers section does not configure the system to be a name server. 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.

Managing Hosts

On the Hosts tab of the Network Configuration tool, you can 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 name servers (if you are using the default

Fedora Core or Red Hat Enterprise Linux configuration). If the IP address is listed in the /etc/hosts file, the name servers 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.

1. In Enterprise Linux choose Applications ➪ System Settings ➪ Network.

In Fedora Core 4 choose Desktop ➪ System Settings ➪ Network.

2. Click the Hosts tab from the Network Configuration dialog box.

The Hosts tab that appears shows the hostname to static IP address mappings, if any.

3. Click New from the toolbar to open the Add/Edit Hosts Entry dialog box.

4. Enter the hostname and its IP address. If there is an alias for the hostname, enter it as well.

17_599496 ch11.qxd 8/30/05 6:44 PM Page 262

262 Chapter 11

5. Click OK to add the entry to the list.

6. Choose File ➪ Save to save your changes.

WA R N I N G

Never remove the Localhost entry from the Hosts section, or your network will not work properly.

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

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, do the following:

1. In Enterprise Linux choose Applications ➪ System Settings ➪ Network.

In Fedora Core 4 choose Desktop ➪ System Settings ➪ Network.

2. Choose Profile ➪ New from the menu.

3. Enter a unique name for the profile.

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

In the list of devices is a column of check boxes labeled Profile. For each profile, you can check (mark) or uncheck (clear) devices. Only the checked devices are included for the currently selected profile.

N OT E

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 (replacing profilename with the name of the profile): redhat-config-network-cmd --profile profilename

17_599496 ch11.qxd 8/30/05 6:44 PM Page 263

TCP/IP Networking 263

Configuring IP Masquerading

So far, you have configured an internal network consisting of two subnets, and you configured a router for connectivity between the networks. Assuming that you made the connection to the Internet through your router, you need to make only a few configuration changes and every computer on your network can connect to the Internet through your one connection. This type of connection provides a service known as Network Address Translation, or NAT. To use a single Internet connection for multiple computers, you need to use IP

masquerading. IP masquerading enables you to connect a TCP/IP network to the outside world using a single server and a single IP address.

Current Red Hat distributions make IP masquerading available as a module, so you need only load the module and enable the appropriate configuration. You already enabled IP forwarding when you configured your router, so you need to consider only one more item, a utility called iptables, which sets up a simple packet-filtering firewall.

C R O S S - R E F E R E N C E

To learn about securing your Red Hat system for the

Internet, see Chapter 31.

The iptables utility gives you enough protection for now. To set up masquerading, type the following commands:

iptables -P forward DENY iptables -A forward -s 192.168.0.0/24 -j MASQ -d 0.0.0.0/0

Those commands are all you need to enable the firewall rules and to start masquerading.

Of course you want IP masquerading enabled whenever you boot the computer, so it’s a good idea to make a script file that enables IP forwarding as well as the iptables utility. This file would ensure that forwarding and masquerading start each time the machine boots.

Be sure to include the command to start IP forwarding (shown earlier in this chapter) as well as the iptables commands shown here in your system startup sequence. You can place the appropriate commands in your /etc/rc.local

file so that they will run when your system starts.

Summary

In this chapter, you learned about the TCP/IP protocol suite and how it works to enable communication across networks. Then you learned how to configure a network interface card by creating and modifying the configuration files

17_599496 ch11.qxd 8/30/05 6:44 PM Page 264

264 Chapter 11

directly, as well as using the graphical Network Configuration tool. You used subnetting to create two internal subnetworks and configured a router so the subnetworks could communicate with each other. You set up a Dynamic Host

Configuration Protocol server to assign IP addresses to the hosts on the network. You also enabled forwarding and masquerading so that every computer on your internal network could have Internet access.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 265

C H A P T E R

12

The Network

File System

IN THIS CHAPTER

■■

■■

■■

■■

■■

■■

NFS Overview

Planning an NFS Installation

Configuring an NFS Server

Configuring an NFS Client

Using Automount Services

Examining NFS Security

Linux Servers are often installed to provide centralized file and print services for networks. This chapter explains how to use the Network File System (NFS) to create a file server. After a short overview of NFS, you learn how to plan an

NFS installation, how to configure an NFS server, and how to set up an NFS client. You’ll learn how to mount remote file systems automatically, eliminating the need to mount remote file systems manually before you can access it.

The final section of the chapter highlights NFS-related security issues.

NFS Overview

NFS is the most common method used to share files across Linux and UNIX networks. It is a distributed file system that enables local access to remote disks and file systems. In a properly designed and carefully implemented NFS installation, NFS’s operation is totally transparent to clients using remote file systems. Provided that you have the appropriate network connection, you can access files and directories that are physically located on another system or even in a different city or country using standard Linux commands. No special

265

18_599496 ch12.qxd 8/30/05 6:42 PM Page 266

266 Chapter 12

procedures, such as using a password, are necessary. NFS is a common and popular file-sharing protocol, so NFS clients are available for many non-UNIX operating systems, including the various Windows versions, MacOS, OS/2,

VAX/VMS, and MVS.

Understanding NFS

NFS follows standard client/server architectural principles. The server component of NFS consists of the physical disks that contain the file systems you want to share and several daemons that make these shared file systems visible to and available for use by client systems on the network. When an NFS server is sharing a file system in this manner, it is said to be exporting a file system. Similarly, the shared file system is referred to as an NFS export. The NFS server daemons provide remote access to the exported file systems, enable file locking over the network, and, optionally, allow the server administrator to set and enforce disk quotas on the NFS exports.

On the client side of the equation, an NFS client simply mounts the exported file systems locally, just as local disks would be mounted. The mounted file system is known colloquially as an NFS mount.

The possible uses of NFS are quite varied. NFS is often used to provide diskless clients, such as X terminals or the slave nodes in a cluster, with their entire file system, including the kernel image and other boot files. Another common scheme is to export shared data or project-specific directories from an NFS server and to enable clients to mount these remote file systems anywhere they see fit on the local system.

Perhaps the most common use of NFS is to provide centralized storage for users’ home directories. Many sites store users’ home directories on a central server and use NFS to mount the home directory when users log in or boot their systems. Usually, the exported directories are mounted as /home/username on the local (client) systems, but the export itself can be stored anywhere on the

NFS server, for example, /exports/users/username. Figure 12-1 illustrates both of these NFS uses.

The network shown in Figure 12-1 shows a server (suppose that its name is diskbeast) with two set of NFS exports, user home directories on the file system /exports/homes (/exports/homes/u1, /exports/homes/u2, and so on) and a project directory stored on a separate file system named /proj.

Figure 12-1 also illustrates a number of client systems (pear, apple, mango, and so forth). Each client system mounts /home locally from diskbeast. On diskbeast, the exported file systems are stored in the /exports/homes directory. When a user logs in to a given system, that user’s home directory is automatically mounted on /home/username on that system. So, for example,

18_599496 ch12.qxd 8/30/05 6:42 PM Page 267

The Network File System 267

because user u1 has logged in on pear, /exports/homes/u1 is mounted on pear’s file system as /home/u1. If u1 then logs in on mango, too (not illustrated in Figure 12-1), mango also mounts /home/u1. Logging in on two systems this way is potentially dangerous because changes to files in the exported file system made from one login session might adversely affect the other login session. Despite the potential for such unintended consequences, it is also very convenient for such changes to be immediately visible.

Figure 12-1 also shows that three users, u5, u6, and u7, have mounted the project-specific file system, /proj, in various locations on their local file systems. Specifically, user u5 has mounted it as /work/proj on kiwi (that is, kiwi:/work/proj in host:/mount/dir form) u6 as lime:/projects, and u7 as peach:/home/work.

NFS can be used in almost any situation requiring transparent local access to remote file systems. In fact, you can use NFS and NIS (Chapter 13 covers

NIS in depth) together to create a highly centralized network environment that makes it easier to administer the network, add and delete user accounts, protect and back up key data and file systems, and give users a uniform, consistent view of the network regardless of where they log in.

pear diskbeast kiwi

/home/u1 apple

/exports/homes

/home/u5

/work/proj lime

/home/u2 mango

/home/u3 guava

/proj

/home/u6

/projects peach

/home/u4

/home/u7

/home/work

Figure 12-1 Exporting home directories and project-specific file systems.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 268

268 Chapter 12

As you will see in the sections titled “Configuring an NFS Server” and

“Configuring an NFS Client,” NFS is easy to set up and maintain and pleasantly flexible. Exports can be mounted read-only or in read-write mode.

Permission to mount exported file systems can be limited to a single host or to a group of hosts using either hostnames with the wildcards * and ? or using IP address ranges, or even using NIS groups, which are similar to, but not the same as, standard UNIX user groups. Other options enable strengthening or weakening of certain security options as the situation demands.

What’s New with NFSv4?

NFS version 4, which is the version available in Fedora Core and Red Hat

Enterprise Linux, offers significant security and performance enhancements over older versions of the NFS protocol and adds features such as replication

(the ability to duplicate a server’s exported file systems on other servers) and migration (the capability to move file systems from one NFS server to another without affecting NFS clients) that NFS has historically lacked. For example, one of the (justified) knocks against NFS has been that it transmits authentication data as clear text. NFSv4 incorporates RPCSEC-GSS (the SecureRPC protocol using the Generic Security Service API) security, which makes it possible to encrypt the data stream transmitted between NFS clients and servers.

Another security feature added to NFSv4 is support for access control lists, or

ACLs. ACLs build on the traditional Linux UID- and GID-based file and directory access by giving users and administrators the ability to set more finely grained restrictions on who can read, write, and/or execute a given file.

In terms of backward compatibility, NFSv4 isn’t, at least not completely.

Specifically, an NFSv4 client might not be able to mount an NFSv2 export. It has been our experience that mounting an NFSv2 export on an NFSv4 client requires the use of the NFS-specific mount option nfsvers=2. Going the other direction, mounting an NFSv4 export on an NFSv2 does not require special handling. NFSv4 and NFSv3 interoperability is no problem. See the section titled “Configuring an NFS Client” for more details about interoperability between NFS versions.

In terms of performance enhancements, NFSv4 makes fuller use of clientside caching, which reduces the frequency with which clients must communicate with an NFS server. By decreasing the number of server round trips, overall performance increases. In addition, NFSv4 was specifically designed (or enhanced) to provide reasonable performance over the Internet, even on slow, low-bandwidth connections or in high latency situations (such as when someone on your LAN is downloading the entire Lord of the Rings trilogy). However, despite the improved client-side caching, NFS is still a stateless protocol.

Clients maintain no information about available servers across reboots, and the client-side cache is likewise lost on reboot. In addition, if a server reboots or

18_599496 ch12.qxd 8/30/05 6:42 PM Page 269

The Network File System 269

becomes unavailable when a client has pending (uncommitted) file changes, these changes will be lost if the server does not come back up fairly soon.

Complementing the new version’s greater Internet-friendliness, NFSv4 also supports Unicode (UTF-8) filenames, making cross-platform and intercharacter set file sharing more seamless and more international.

When applicable, this chapter will discuss using NFSv4 features, include examples of NFSv4 clients and servers, and warn you of potential problems you might encounter when using NFSv4.

N OT E

For more information about NFSv4 in Fedora Core and Red Hat

Enterprise Linux, see Van Emery’s excellent article, “Learning NFSv4 with Fedora

Core 2,” on the Web at www.vanemery.com/Linux/NFSv4/NFSv4-no-rpcsec

.html

. The NFSv4 open-source reference implementation is driven by the Center for Information Technology Integration (CITI) at the University of Michigan,

which maintains an information-rich Web site at www.citi.umich.edu

/projects/nfsv4

.

NFS Advantages and Disadvantages

Clearly, the biggest advantage NFS provides is centralized control, maintenance, and administration. It is much easier, for example, to back up a file system stored on a single server than it is to back up directories scattered across a network, on systems that are geographically dispersed, and that might or might not be accessible when the backup is made. Similarly, NFS makes it trivial to provide access to shared disk space, or limit access to sensitive data.

When NFS and NIS are used together, changes to systemwide configuration files, such as authentication files or network configuration information, can be quickly and automatically propagated across the network without requiring system administrators to physically visit each machine or requiring users to take any special action.

NFS can also conserve disk space and prevent duplication of resources.

Read-only file systems and file systems that change infrequently, such as

/usr

, can be exported as read-only NFS mounts. Likewise, upgrading applications employed by users throughout a network simply becomes a matter of installing the new application and changing the exported file system to point at the new application.

End users also benefit from NFS. When NFS is combined with NIS, users can log in from any system, even remotely, and still have access to their home directories and see a uniform view of shared data. Users can protect important or sensitive data or information that would be impossible or time-consuming to re-create by storing it on an NFS mounted file system that is regularly backed up.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 270

270 Chapter 12

NFS has its shortcomings, of course, primarily in terms of performance and security. As a distributed, network-based file system, NFS is sensitive to network congestion. Heavy network traffic slows down NFS performance. Similarly, heavy disk activity on the NFS server adversely affects NFS’s performance. In the face of network congestion or extreme disk activity, NFS clients run more slowly because file I/O takes longer. The performance enhancements incorporated in NFSv4 have increased NFS’s stability and reliability on high latency and heavily congested networks, but it should be clear that unless you are on a high-speed network, such as Gigabit Ethernet or

Myrinet, NFS will not be as fast as a local disk.

If an exported file system is not available when a client attempts to mount it, the client system can hang, although this can be mitigated using a specific mount option that you will read about in the section titled “Configuring an

NFS Client.” Another shortcoming of NFS is that an exported file system represents a single point of failure. If the disk or system exporting vital data or application becomes unavailable for any reason, such as a disk crash or server failure, no one can access that resource.

NFS suffers from potential security problems because its design assumes a trusted network, not a hostile environment in which systems are constantly being probed and attacked. The primary weakness of most NFS implementations based on protocol versions 1, 2, and 3 is that they are based on standard

(unencrypted) remote procedure calls (RPC). RPC is one of the most common targets of exploit attempts. As a result, sensitive information should never be exported from or mounted on systems directly exposed to the Internet, that is, one that is on or outside a firewall. While RPCSEC_GSS makes NFSv4 more secure and perhaps safer to use on Internet-facing systems, evaluate such usage carefully and perform testing before deploying even a version 4–based NFS system across the Internet. Never use NFS versions 3 and earlier on systems that front the Internet; clear-text protocols are trivial for anyone with a packet sniffer to intercept and interpret.

N OT E

An NFS client using NFS servers inside a protected network can safely be exposed to the Internet because traffic between client and server travels across the protected network. What we are discouraging is accessing an NFSv3

(or earlier) export across the Internet.

Quite aside from encryption and even inside a firewall, providing all users access to all files might pose greater risks than user convenience and administrative simplicity justify. Care must be taken when configuring NFS exports to limit access to the appropriate users and also to limit what those users are permitted to do with the data. Moreover, NFS has quirks that can prove disastrous

18_599496 ch12.qxd 8/30/05 6:42 PM Page 271

The Network File System 271

for unwary or inexperienced administrators. For example, when the root user on a client system mounts an NFS export, you do not want the root user on the client to have root privileges on the exported file system. By default, NFS prevents this, a procedure called root squashing, but a careless administrator might override it.

Planning an NFS Installation

Planning an NFS installation is a grand-sounding phrase that boils down to thoughtful design followed by careful implementation. Of these two steps, design is the more important because it ensures that the implementation is transparent to end users and trivial to the administrator. The implementation is remarkably straightforward. This section highlights the server configuration process and discusses the key design issues to consider.

“Thoughtful design” consists of deciding what file systems to export to which users and selecting a naming convention and mounting scheme that maintains network transparency. When you are designing your NFS installation, you need to:

■■

Select the file systems to export

■■

Establish which users (or hosts) are permitted to mount the exported file systems

■■

Identify the automounting or manual mounting scheme that clients will use to access exported file systems

■■

Choose a naming convention and mounting scheme that maintains network transparency and ease of use

With the design in place, implementation is a matter of configuring the exports and starting the appropriate daemons. Testing ensures that the naming convention and mounting scheme works as designed and identifies potential performance bottlenecks. Monitoring is an ongoing process to ensure that exported file systems continue to be available, network security and the network security policy remain uncompromised, and that heavy usage does not adversely affect overall performance.

A few general rules exist to guide the design process. You need to take into account site-specific needs, such as which file systems to export, the amount of data that will be shared, the design of the underlying network, what other network services you need to provide, and the number and type of servers and clients. The following tips and suggestions for designing an NFS server and its exports will simplify administrative tasks and reduce user confusion:

18_599496 ch12.qxd 8/30/05 6:42 PM Page 272

272 Chapter 12

■■

Good candidates for NFS exports include any file system that is shared among a large number of users, such as /home, workgroup project directories, shared data directories, such as /usr/share, the system mail spool (/var/spool/mail), and file systems that contain shared application binaries and data. File systems that are relatively static, such as /usr, are also good candidates for NFS exports because there is no need to replicate the same static data and binaries across multiple machines.

T I P

A single NFS server can export binaries for multiple platforms by exporting system-specific subdirectories. So, for example, you can export a subdirectory of Linux binaries from a Solaris NFS server with no difficulty. The point to emphasize here is that NFS can be used in heterogeneous environments as seamlessly as it can be used in homogeneous network installations.

■■

Use /home/username to mount home directories. This is one of the most fundamental directory idioms in the Linux world, so disregarding it not only antagonizes users but also breaks a lot of software that presumes user home directories live in /home. On the server, you have more leeway about where to situate the exports. Recall from Figure 12-1, for example, that diskbeast stored user home directories in /exports/home.

■■

Few networks are static, particularly network file systems, so design

NFS servers with growth in mind. For example, avoid the temptation to drop all third-party software onto a single exported file system. Over time, file systems usually grow to the point that they need to be subdivided, leading to administrative headaches when client mounts must be updated to reflect a new set of exports. Spread third-party applications across multiple NFS exports and export each application and its associated data separately.

■■

■■

If the previous tip will result in a large number of NFS mounts for clients, it might be wiser to create logical volume sets on the NFS server.

By using logical volumes underneath the exported file systems, you can increase disk space on the exported file systems as it is needed without having to take the server down or take needed exports offline.

At large sites, distribute multiple NFS exports across multiple disks so that a single disk failure will limit the impact to the affected application.

Better still, to minimize downtime on singleton servers, use RAID for redundancy and logical volumes for flexibility. If you have the capacity, use NFSv4’s replication facilities to ensure that exported file systems remain available even if the primary NFS server goes up in smoke.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 273

The Network File System 273

■■

Similarly, overall disk and network performance improves if you distribute exported file systems across multiple servers rather than concentrate them on a single server. If it is not possible to use multiple servers, at least try to situate NFS exports on separate physical disks and/or on separate disk controllers. Doing so reduces disk I/O contention.

When identifying the file systems to export, keep in mind a key restriction on which file systems can be exported and how they can be exported. You can export only local file systems and their subdirectories. To express this restriction in another way, you cannot export a file system that is itself already an

NFS mount. For example, if a client system named userbeast mounts /home from a server named homebeast, userbeast cannot reexport /home. Clients wishing to mount /home must do so directly from homebeast.

Configuring an NFS Server

This section shows you how to configure an NFS server, identifies the key files and commands you use to implement, maintain, and monitor the NFS server, and illustrates the server configuration process using a typical NFS setup.

On Fedora Core and Red Hat Enterprise Linux systems, the /etc/exports file is the main NFS configuration file. It lists the file systems the server exports, the systems permitted to mount the exported file systems, and the mount options for each export. NFS also maintains status information about existing exports and the client systems that have mounted those exports in

/var/lib/nfs/rmtab and /var/lib/nfs/xtab.

In addition to these configuration and status files, all of the daemons, commands, initialization scripts, and configuration files in the following list are part of NFS. Don’t panic because the list is so long, though; you have to concern yourself with only a few of them to have a fully functioning and properly configured NFS installation. Notice that approximately half of the supporting files are part of NFSv4 — presumably the price one pays for added features.

■■

Daemons

■■ rpc.gssd

(new in NFSv4)

■■ rpc.idmapd

(new in NFSv4)

■■ rpc.lockd

■■ rpc.mountd

■■ rpc.nfsd

■■ rpc.portmap

18_599496 ch12.qxd 8/30/05 6:42 PM Page 274

274 Chapter 12

■■ rpc.rquotad

■■ rpc.statd

■■ rpc.svcgssd

(new in NFSv4)

■■

Configuration files (in /etc)

■■ exports

■■ gssapi_mech.conf

(new in NFSv4)

■■ idmapd.conf

(new in NFSv4)

■■

Initialization scripts (in /etc/rc.d/init.d)

■■ nfs

■■

■■ rpcgssd

(new in NFSv4)

■■ rpcidmapd

(new in NFSv4)

■■ rpcsvcgssd

(new in NFSv4)

Commands

■■ exportfs

■■ nfsstat

■■ showmount

■■ rpcinfo

NFS Server Configuration and Status Files

The server configuration file is /etc/exports, which contains a list of file systems to export, the clients permitted to mount them, and the export options that apply to client mounts. Each line in /etc/exports has the following format:

dir [host](options) [...] dir specifies a directory or file system to export, host specifies one or more hosts permitted to mount dir, and options specifies one or more mount options. If you omit host, the listed options apply to every possible client system, likely not something you want to do. If you omit options, the default mount options (described shortly) will be applied. Do not insert a space between the hostname and the opening parenthesis that contains the export options; a space between the hostname and the opening parenthesis of the option list has four (probably unintended) consequences:

1. Any NFS client can mount the export.

2. You’ll see an abundance of error messages in /var/log/messages.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 275

The Network File System 275

3. The list options will be applied to all clients, not just the client(s) identified by the host specification.

4. The client(s) identified by the host specification will have the default mount options applied, not the mount options specified by options.

host can be specified as a single name, an NIS netgroup, a subnet using address/net mask form, or a group of hostnames using the wildcard characters ? and *. Multiple host(options) entries, separated by whitespace, are also accepted, enabling you to specify different export options for a single dir depending on the client.

T I P

The exports manual (man) page recommends not using the wildcard

characters * and ? with IP addresses because they don’t work except by accident

when reverse DNS lookups fail. We’ve used the wildcard characters without incident on systems we administer, but, as always, your mileage may vary.

When specified as a single name, host can be any name that DNS or the resolver library can resolve to an IP address. If host is an NIS netgroup, it is specified as @groupname. The address/net mask form enables you to specify all hosts on an IP network or subnet. In this case the net mask can be specified in dotted quad format (/255.255.252.0, for example) or as a mask length

(such as /22). As a special case, you can restrict access to an export to only those clients using RPCSEC_GSS security by using the client specification gss/krb5

. If you use this type of client specification, you cannot also specify an IP address. You may also specify the host using the wildcards * and ?.

Consider the following sample /etc/exports file:

/usr/local *.example.com(ro)

/usr/devtools 192.168.1.0/24(ro)

/home 192.168.0.0/255.255.255.0(rw)

/projects @dev(rw)

/var/spool/mail 192.168.0.1(rw)

/opt/kde gss/krb5(ro)

The first line permits all hosts with a name of the format somehost.

example.com

to mount /usr/local as a read-only directory. The second line uses the address/net mask form in which the net mask is specified in Classless Inter-Domain Routing (CIDR) format. In the CIDR format, the net mask is given as the number of bits (/24, in this example) used to determine the network address. A CIDR address of 192.168.1.0/24 allows any host with an IP address in the range 192.168.1.1 to 192.168.1.254 (192.168.1.0 is excluded because it is the network address; 192.168.1.255 is excluded because it is the broadcast address) to mount /usr/devtools read-only. The third line permits any host

18_599496 ch12.qxd 8/30/05 6:42 PM Page 276

276 Chapter 12

with an IP address in the range 192.168.0.1 to 192.168.0.254 to mount /home in read-write mode. This entry uses the address/net mask form in which the net mask is specified in dotted quad format. The fourth line permits any member of the NIS netgroup named dev to mount /projects (again, in read-write mode). The fifth line permits only the host whose IP address is 192.168.0.1 to mount /var/mail. The final line allows any host using RPCSEC_GSS security to mount /opt/kde in read-only mode.

T I P

If you have trouble remembering how to calculate IP address ranges

using the address/net mask format, use the excellent ipcalc utility created by

Krischan Jodies. You can download it from his Web site (jodies.de/ipcalc/)

or from the Web site supporting this book, wiley.com/go/redhat-admin3e.

The export options, listed in parentheses after the host specification, determine the characteristics of the exported file system. Table 12-1 lists valid values for options.

Table 12-1 Nfs Export Options

OPTION DESCRIPTION

all_squash

Maps all requests from all UIDs or GIDs to the UID or

GID, respectively, of the anonymous user.

anongid=gid anonuid=uid async fsid=n

Sets the GID of the anonymous account to gid.

Sets the UID of the anonymous account to uid.

Allows the server to cache disk writes to improve performance.

Forces NFS’s internal file system identification (FSID) number to be n.

hide insecure insecure_locks mp[=path] no_all_squash no_root_squash

Hides an exported file system that is a subdirectory of another exported file system.

Permits client requests to originate from unprivileged ports (those numbered 1024 and higher).

Disables the need for authentication before activating lock operations (synonym for no_auth_nlm).

Exports the file system specified by path only if the corresponding mount point is mounted (synonym for mountpoint[=path]

).

Disables all_squash.

Disables root_squash.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 277

The Network File System 277

Table 12-1 (continued)

OPTION

no_subtree_check no_wdelay nohide ro root_squash rw secure secure_locks subtree_check sync wdelay

DESCRIPTION

Disables subtree_check.

Disables wdelay (must be used with the sync option).

Does not hide an exported file system that is a subdirectory of another exported file system.

Exports the file system read-only, disabling any operation that changes the file system.

Maps all requests from a user ID (UID) or group ID (GID) of 0 to the UID or GID, respectively, of the anonymous user (-2 in Red Hat Linux).

Exports the file system read-write, permitting operations that change the file system.

Requires client requests to originate from a secure

(privileged) port, that is, one numbered less than 1024.

Requires that clients requesting lock operations be properly authenticated before activating the lock

(synonym for auth_nlm).

If only part of a file system, such as a subdirectory, is exported, subtree checking makes sure that file requests apply to files in the exported portion of the file system.

Forces the server to perform a disk write before notifying the client that the request is complete.

Instructs the server to delay a disk write if it believes another related disk write may be requested soon or if one is in progress, improving overall performance.

T I P

Recent versions of NFS (actually, of the NFS utilities) default to exporting

directories using the sync option. This is a change from past practice, in which

directories were exported and mounted using the async option. This change

was made because defaulting to async violated the NFS protocol specification.

The various squash options, and the anonuid and anongid options require additional explanation. root_squash prevents the root user on an NFS client from having root privileges on an NFS server via the exported file system. The

Linux security model ordinarily grants root full access to the file systems on a host. However, in an NFS environment, exported file systems are shared resources that are properly “owned” by the root user of the NFS server, not by

18_599496 ch12.qxd 8/30/05 6:42 PM Page 278

278 Chapter 12

the root users of the client systems that mount them. The root_squash option remaps the root UID and GID (0) on the client system to a less privileged UID and GID, -2. Remapping the root UID and GID prevents NFS clients from inappropriately taking ownership of NFS exports by. The no_root_squash option disables this behavior, but should not be used because doing so poses significant security risks. Consider the implications, for example, of giving a client system root access to the file system containing sensitive payroll information.

The all_squash option has a similar effect to root_squash, except that it applies to all users, not just the root user. The default is no_all_squash, however, because most users that access files on NFS exported file systems are already merely mortal users, that is, they have unprivileged UIDs and GIDs, so they do not have the power of the root account. Use the anonuid and anongid options to specify the UID and GID of the anonymous user. The default UID and GID of the anonymous user is -2, which should be adequate in most cases.

subtree_check and no_subtree check also deserve some elaboration.

When a subdirectory of file system is exported but the entire file system is not exported, the NFS server must verify that the accessed file resides in the exported portion of the file system. This verification, called a subtree check, is programmatically nontrivial to implement and can negatively impact NFS performance. To facilitate subtree checking, the server stores file location information in the file handles given to clients when they request a file.

In most cases, storing file location information in the file handle poses no problem. However, doing so becomes potentially troublesome when an NFS client is accessing a file that is renamed or moved while the file is open. Moving or renaming the file invalidates the location information stored in the file handle, so the next client I/O request on that file causes an error. Disabling the subtree check using no_subtree_check prevents this problem because the location information is not stored in the file handle when subtree checking is disabled. As an added benefit, disabling subtree checking improves performance because it removes the additional overhead involved in the check. The benefit is especially significant on exported file systems that are highly dynamic, such as /home.

Unfortunately, disabling subtree checking also poses a security risk. The subtree check routine ensures that files to which only root has access can be accessed only if the file system is exported with no_root_squash, even if the file’s permissions permit broader access.

The manual page for /etc/exports recommends using no_subtree_ check for /home because /home file systems normally experiences a high level of file renaming, moving, and deletion. It also recommends leaving subtree checking enabled (the default) for file systems that are exported read-only; file systems that are largely static (such as /usr or /var); and file systems from which only subdirectories and not the entire file system, are exported.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 279

The Network File System 279

The hide and nohide options mimic the behavior of NFS on SGI’s IRIX. By default, if an exported directory is a subdirectory of another exported directory, the exported subdirectory will be hidden unless both the parent and child exports are explicitly mounted. The rationale for this feature is that some NFS client implementations cannot deal with what appears to be two different files having the same inode. In addition, directory hiding simplifies client- and server-side caching. You can disable directory hiding by specifying nohide.

The final interesting mount option is mp. If set, the NFS server will not export a file system unless that file system is actually mounted on the server.

The reasoning behind this option is that a disk or file system containing an

NFS export might not mount successfully at boot time or might crash at runtime. This measure prevents NFS clients from mounting unavailable exports.

Here is a modified version of the /etc/exports file presented earlier:

/usr/local *.example.com(mp,ro,secure)

/usr/devtools 192.168.1.0/24(mp,ro,secure)

/home 192.168.0.0/255.255.255.0(mp,rw,secure,no_subtree_check)

/projects @dev(mp,rw,secure,anonuid=600,anongid=600,sync,no_wdelay)

/var/mail 192.168.0.1(mp,rw,insecure,no_subtree_check)

/opt/kde gss/krb5(mp,ro,async)

The hosts have not changed, but additional export options have been added. All file systems use the mp option to make sure that only mounted file systems are available for export. /usr/local, /usr/devtools, /home, and

/project can be accessed only from clients using secure ports (the secure option), but the server accepts requests destined for /var/mail from any port because the insecure option is specified. For /projects, the anonymous user is mapped to the UID and GID 600, as indicated by the anonuid=600 and anongid=600 options. The wrinkle in this case is that only members of the

NIS netgroup dev will have their UIDs and GIDs mapped because they are the only NFS clients permitted to mount /projects.

/home and /var/mail are exported using the no_subtree_check option because they see a high volume of file renaming, moving, and deletion.

Finally, the sync and no_wdelay options disable write caching and delayed writes to the /project file system. The rationale for using sync and no_wdelay is that the impact of data loss would be significant in the event the server crashes. However, forcing disk writes in this manner also imposes a performance penalty because the NFS server’s normal disk caching and buffering heuristics cannot be applied.

If you intend to use NFSv4-specific features, you need to be familiar with the RPCSEC_GSS configuration files, /etc/gssapi_mech.conf and /etc

/idmapd.conf

. idmapd.conf is the configuration file for NFSv4’s idmapd daemon. idmapd works on the behalf of both NFS servers and clients to translate NFSv4 IDs to user and group IDs and vice versa; idmapd.conf controls

18_599496 ch12.qxd 8/30/05 6:42 PM Page 280

280 Chapter 12

idmapd

’s runtime behavior. The default configuration (with comments and blank lines removed) should resemble Listing 12-1.

[General]

Verbosity = 0

Pipefs-Directory = /var/lib/nfs/rpc_pipefs

Domain = localdomain

[Mapping]

Nobody-User = nobody

Nobody-Group = nobody

[Translation]

Method = nsswitch

Listing 12-1 Default idmapd configuration.

In the [General] section, the Verbosity option controls the amount of log information that idmapd generates; Pipefs-directory tell idmapd where to find the RPC pipe file system it should use (idmapd communicates with the kernel using the pipefs virtual file system); Domain identifies the default domain. If Domain isn’t specified, it defaults to the server’s fully qualified domain name (FQDN) less the hostname. For example, if the FQDN is coondog.example.com

, the Domain parameter would be example.com; if the FQDN is mail.admin.example.com, the Domain parameter would be the subdomain admin.example.com. The Domain setting is probably the only change you will need to make to idmapd’s configuration.

The [Mapping] section identifies the user and group names that correspond to the nobody user and group that NFS server should use. The option

Method = nsswitch

, finally, tells idmapd how to perform the name resolution. In this case, names are resolved using the name service switch (NSS) features of glibc.

The /etc/gssapi_mech.conf file controls the GSS daemon (rpc

.svcgssd

). You won’t need to modify this file. As provided in Fedora Core and RHEL, gssapi_mech.conf lists the specific function call to use to initialize a given GSS library. Programs (in this case, NFS) need this information if they intend to use secure RPC.

Two additional files store status information about NFS exports, /var

/lib/nfs/rmtab and /var/lib/nfs/etab. /var/lib/nfs/rmtab is the table that lists each NFS export that is mounted by an NFS client. The daemon rpc.mountd

(described in the section “NFS Server Daemons”) is responsible for servicing requests to mount NFS exports. Each time the rpc.mountd daemon receives a mount request, it adds an entry to /var/lib/nfs/rmtab.

Conversely, when mountd receives a request to unmount an exported file system, it removes the corresponding entry from /var/lib/nfs/rmtab. The following short listing shows the contents of /var/lib/nfs/rmtab on an NFS

18_599496 ch12.qxd 8/30/05 6:42 PM Page 281

The Network File System 281

server that exports /home in read-write mode and /usr/local in read-only mode. In this case, the host with IP address 192.168.0.4 has mounted both exports:

$ cat /var/lib/nfs/rmtab

192.168.0.4:/home:0x00000001

192.168.0.4:/usr/local:0x00000001

Fields in rmtab are colon-delimited, so it has three fields: the host, the exported file system, and the mount options specified in /etc/exports.

Rather than try to decipher the hexadecimal options field, though, you can read the mount options directly from /var/lib/nfs/etab. The exportfs command, discussed in the subsection titled “NFS Server Scripts and Commands,” maintains /var/lib/nfs/etab. etab contains the table of currently exported file systems. The following listing shows the contents of

/var/lib/nfs/etab for the server exporting the /usr/local and /home file systems shown in the previous listing (the output wraps because of page width constraints).

$ cat /var/lib/nfs/etab

/usr/local

192.168.0.4(ro,sync,wdelay,hide,secure,root_squash,no_all_squash, subtree_check,secure_locks,mapping=identity,anonuid=-2,anongid=-2)

/home

192.168.0.2(rw,sync,wdelay,hide,secure,root_squash,no_all_squash, subtree_check,secure_locks,mapping=identity,anonuid=-2,anongid=-2)

As you can see in the listing, the format of the etab file resembles that of

/etc/exports

. Notice, however, that etab lists the default values for options not specified in /etc/exports in addition to the options specifically listed.

N OT E

Most Linux systems use /var/lib/nfs/etab to store the table of

currently exported file systems. The manual page for the exportfs command,

however, states that /var/lib/nfs/xtab contains the table of current

exports. We do not have an explanation for this — it’s just a fact of life that the manual page and actual usage differ.

The last two configuration files to discuss, /etc/hosts.allow and

/etc/hosts.deny

, are not, strictly speaking, part of the NFS server. Rather,

/etc/hosts.allow

and /etc/hosts.deny are access control files used by the TCP Wrappers system; you can configure an NFS server without them and the server will function perfectly (to the degree, at least, that anything ever functions perfectly). However, using TCP Wrappers’ access control features helps enhance both the overall security of the server and the security of the

NFS subsystem.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 282

282 Chapter 12

The TCP Wrappers package is covered in detail in Chapter 19. Rather than preempt that discussion here, we suggest how to modify these files, briefly explain the rationale, and suggest you refer to Chapter 19 to understand the modifications in detail.

First, add the following entries to /etc/hosts.deny: portmap:ALL lockd:ALL mountd:ALL rquotad:ALL statd:ALL

These entries deny access to NFS services to all hosts not explicitly permitted access in /etc/hosts.allow. Accordingly, the next step is to add entries to /etc/hosts.allow to permit access to NFS services to specific hosts. As you will learn in Chapter 19, entries in /etc/hosts.allow take the form:

daemon:host_list [host_list]

T I P

The NFS HOWTO (http://nfs.sourceforge.net/nfs-howto/server.

html#CONFIG

) discourages use of the ALL:ALL syntax in /etc/hosts.deny,

using this rationale: “While [denying access to all services] is more

secure behavior, it may also get you in trouble when you are installing new services, you forget you put it there, and you can’t figure out for the life of you why they won’t work.”

We respectfully disagree. The stronger security enabled by the ALL:ALL

construct in /etc/hosts.deny far outweighs any inconvenience it might pose

when configuring new services.

daemon is a daemon such as portmap or lockd, and host_list is a list of one or more hosts specified as hostnames, IP addresses, IP address patterns using wildcards, or address/net mask pairs. For example, the following entry permits all hosts in the example.com domain to access the portmap service: portmap:.example.com

The next entry permits access to all hosts on the subnetworks 192.168.0.0

and 192.168.1.0: portmap:192.168.0. 192.168.1.

You need to add entries for each host or host group permitted NFS access for each of the five daemons listed in /etc/hosts.deny. So, for example, to

18_599496 ch12.qxd 8/30/05 6:42 PM Page 283

The Network File System 283

permit access to all hosts in the example.com domain, add the following entries to /etc/host.allow: portmap:.example.com

lockd :.example.com

mountd :.example.com

rquotad:.example.com

statd :.example.com

Therefore, a name of the form .domain.dom matches all hosts, including hosts in subdomains like .subdom.domain.dom.

NFS Server Daemons

Providing NFS services requires the services of six daemons: /sbin/portmap,

/usr/sbin/rpc.mountd

, /usr/sbin/rpc.nfsd, /sbin/rpc.statd,

/sbin/rpc.lockd

, and, if necessary, /usr/sbin/rpc.rquotad. They are generally referred to as portmap, mountd, nfssd, statd, lockd, and rquotad

, respectively. If you intend to take advantage of NFSv4’s enhancements, you’ll also need to know about rpc.gssd, rpc.idmapd, and rpc

.svcgssd

. For convenience’s sake, we’ll refer to these daemons using the shorthand expressions gssd, idmapd, and svcgssd. Table 12-2 briefly describes each daemon’s purpose.

Table 12-2 Nfs Server Daemons

DAEMON FUNCTION

gssd

Creates security contexts on RPC clients for exchanging RPC information using SecureRPC (RPCSEC) using GSS idmapd lockd mountd nfsd

Maps local user and group names to NFSv4 IDs (and vice versa)

Starts the kernel’s NFS lock manager

Processes NFS client mount requests

Provides all NFS services except file locking and quota management portmap rquotad statd svcgssd

Enables NFS clients to discover the NFS services available on a given NFS server

Provides file system quota information NFS exports to NFS clients using file system quotas

Implements NFS lock recovery when an NFS server system crashes

Creates security contexts on RPC servers for exchanging RPC information using SecureRPC (RPCSEC) using GSS

18_599496 ch12.qxd 8/30/05 6:42 PM Page 284

284 Chapter 12

The NFS server daemons should be started in the following order to work properly:

1. portmap

2. nfsd

3. mountd

4. statd

5. rquotad (if necessary)

6. idmapd

7. svcgssd

The start order is handled for you automatically at boot time if you have enabled NFS services using Service Configuration Tool (/usr/bin/systemconfig-services

).

Notice that the list omits lockd. nfsd starts it on an as-needed basis, so you should rarely, if ever, need to invoke it manually. Fortunately, the Red Hat

Linux initialization script for NFS, /etc/rc.d/init.d/nfs, takes care of starting up the NFS server daemons for you. Should the need arise, however, you can start NFS yourself by executing the handy service utility script directly:

# service nfs start

Starting NFS services: [ OK ]

Starting NFS quotas: [ OK ]

Starting NFS daemon: [ OK ]

Starting NFS mountd [ OK ]

You can also use:

# /etc/rc.d/init.d/nfs start

Starting NFS services: [ OK ]

Starting NFS quotas: [ OK ]

Starting NFS daemon: [ OK ]

Starting NFS mountd [ OK ]

By default, the startup script starts eight copies of nfsd to enable the server to process multiple requests simultaneously. To change this value, edit

/etc/sysconfig/nfs and add an entry resembling the following (you need to be root to edit this file):

RPCNFSDCOUNT=n

Replace n with the number of nfsd processes you want to start. Busy servers with many active connections might benefit from doubling or tripling this

18_599496 ch12.qxd 8/30/05 6:42 PM Page 285

The Network File System 285

number. If file system quotas for exported file systems have not been enabled on the NFS server, it is unnecessary to start the quota manager, rquotad, but be aware that the initialization script starts rquotad whether quotas have been enabled or not.

T I P

If /etc/sysconfig/nfs does not exist, you can create it using your

favorite text editor. In a pinch, you can use the following command to create it

with the RPCNFSDCOUNT setting mentioned in the text:

# cat > /etc/sysconfig/nfs

RPCNFSDCOUNT=16

^d

^d

is the end-of-file mark, generated by pressing the Control key and d simultaneously.

NFS Server Scripts and Commands

Three initialization scripts control the required NFS server daemons,

/etc/rc.d/init.d/portmap

, /etc/rc.d/init.d/nfs, and /etc/rc.d

/init.d/nfslock

. The exportfs command enables you to manipulate the list of current exports on the fly without needing to edit /etc/exports. The showmount command provides information about clients and the file systems they have mounted. The nfsstat command displays detailed information about the status of the NFS subsystem.

The portmap script starts the portmap daemon, frequently referred to as

the portmapper. All programs that use RPC, such as NIS and NFS, rely on the information the portmapper provides. The portmapper starts automatically at boot time, so you rarely need to worry about it, but it is good to know you can control it manually. Like most startup scripts, it requires a single argument, such as start, stop, restart, or status. As you can probably guess, the start and stop arguments start and stop the portmapper, restart restarts it (by calling the script with the start and stop arguments, as it happens), and status indicates whether the portmapper is running, showing the portmapper’s PID if it is running.

The primary NFS startup script is /etc/rc.d/init.d/nfs. Like the portmapper, it requires a single argument, start, stop, status, restart, or reload. start and stop start and stop the NFS server, respectively. The restart argument stops and starts the server processes in a single command and can be used after changing the contents of /etc/exports. However, it is not necessary to reinitialize the NFS subsystem by bouncing the server daemons in this way. Rather, use the script’s reload argument, which causes exportfs

, discussed shortly, to reread /etc/exports and to reexport the

18_599496 ch12.qxd 8/30/05 6:42 PM Page 286

286 Chapter 12

file systems listed there. Both restart and reload also update the timestamp on the NFS lock file (/var/lock/subsys/nfs) used by the initialization script. The status argument displays the PIDs of the mountd, nfsd, and rquotad daemons. For example:

$ service nfs status rpc.mountd (pid 4358) is running...

nfsd (pid 1241 1240 1239 1238 1235 1234 1233 1232) is running...

rpc.rquotad (pid 1221) is running...

The output of the command confirms that the three daemons are running and shows the PIDs for each instance of each daemon. All users are permitted to invoke the NFS initialization script with the status argument, but all the other arguments (start, stop, restart, and reload) require root privileges.

NFS services also require the file-locking daemons lockd and statd. As explained earlier, nfsd starts lockd itself, but you still must start statd separately. You can use an initialization script for this purpose, /etc/rc.d

/init.d/nfslock

. It accepts almost the same arguments as /etc/rc.d

/init.d/nfs does, with the exception of the reload argument (because statd does not require a configuration file).

To tie everything together, if you ever need to start the NFS server manually, the proper invocation sequence is to start the portmapper first, followed by

NFS, followed by the NFS lock manager, that is:

# service portmap start

# service nfs start

# service nfslock start

Conversely, to shut down the server, reverse the start procedure:

# service nfslock stop

# service nfs stop

# service portmap stop

Because other programs and servers may require the portmapper’s service, we suggest that you let it run unless you drop the system to run level 1 to perform maintenance.

You can also find out what NFS daemons are running using the rpcinfo command with the -p option. rpcinfo is a general-purpose program that displays information about programs that use the RPC protocol, of which NFS is one. The -p option queries the portmapper and displays a list of all registered RPC programs. The following listing shows the output of rpcinfo -p on a fairly quiescent NFS server:

18_599496 ch12.qxd 8/30/05 6:42 PM Page 287

The Network File System 287

$ /usr/sbin/rpcinfo -p program vers proto port

100000 2 tcp 111 portmapper

100000 2 udp 111 portmapper

100011 1 udp 961 rquotad

100011 2 udp 961 rquotad

100011 1 tcp 964 rquotad

100011 2 tcp 964 rquotad

100003 2 udp 2049 nfs

100003 3 udp 2049 nfs

100003 4 udp 2049 nfs

100003 2 tcp 2049 nfs

100003 3 tcp 2049 nfs

100003 4 tcp 2049 nfs

100021 1 udp 32770 nlockmgr

100021 3 udp 32770 nlockmgr

100021 4 udp 32770 nlockmgr

100021 1 tcp 35605 nlockmgr

100021 3 tcp 35605 nlockmgr

100021 4 tcp 35605 nlockmgr

100005 1 udp 32772 mountd

100005 1 tcp 32825 mountd

100005 2 udp 32772 mountd

100005 2 tcp 32825 mountd

100005 3 udp 32772 mountd

100005 3 tcp 32825 mountd rpcinfo

’s output shows the RPC program’s ID number, version number, the network protocol it is using, the port number it is using, and an alias name for the program number. The program number and name (first and fifth columns) are taken from the file /etc/rpc, which maps program numbers to program names and also lists aliases for program names. At a bare minimum, to have a functioning NFS server, rpcinfo should list entries for portmapper, nfs, and mountd

.

The exportfs command enables you to manipulate the list of available exports, in some cases without editing /etc/exports. It also maintains the list of currently exported file systems in /var/lib/nfs/etab and the kernel’s internal table of exported file systems. In fact, the NFS initialization script discussed earlier in this subsection uses exportfs extensively. For example, the exportfs -a command initializes /var/lib/nfs/etab, synchronizing it with the contents of /etc/exports. To add a new export to etab and to the kernel’s internal table of NFS exports without editing /etc/exports, use the following syntax: exportfs -o opts host:dir

18_599496 ch12.qxd 8/30/05 6:42 PM Page 288

288 Chapter 12

opts

, host, and dir use the same syntax as that described for

/etc/exports earlier in the chapter. Consider the following command:

# exportfs -o async,rw 192.168.0.3:/var/spool/mail

This command exports /var/spool/mail with the async and rw options to the host whose IP address is 192.168.0.3. This invocation is exactly equivalent to the following entry in /etc/exports:

/var/spool/mail 192.168.0.3(async,rw)

A bare exportfs call lists all currently exported file systems; adding the -v option lists currently exported file systems with their mount options.

# exportfs -v

/usr/local 192.168.0.4(ro,wdelay,root_squash)

/home 192.168.0.4(rw,wdelay,root_squash)

To remove an exported file system, use the -u option with exportfs. For example, the following command unexports the /home file system shown in the previous example.

# exportfs -v -u 192.168.0.4:/home unexporting 192.168.0.4:/home

The showmount command queries the mount daemon, mountd, about the status of the NFS server. Its syntax is: showmount [-adehv] [host]

Invoked with no options, showmount displays a list of all clients that have mounted file systems from the current host. Specify host to query the mount daemon on that host, where host can be a resolvable DNS hostname or, as in the following example, an IP address:

# showmount 192.168.0.1

Hosts on 192.168.0.1:

192.168.0.0/24

192.168.0.1

Table 12-3 describes the effects of showmount’s options.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 289

The Network File System 289

Table 12-3 Options for the showmount Command

OPTION DESCRIPTION

-a

Displays client hostnames and mounted directories in host:directory format

-d

-e

-h

--no-headers

-v

Displays only the directories clients have mounted

Displays the NFS server’s list of exported file systems

Displays a short usage summary

Disables displaying descriptive headings for showmount’s output

Displays showmount’s version number

The following examples show the output of showmount executed on an

NFS server that has exported /media to the client named bubba.example

.com

, which has an IP address of 192.168.0.2, using the following entry in

/etc/exports

:

/media 192.168.0.0/24(rw)

The first command uses the -a option for the most comprehensive output, the second uses the -d option to show only the mounted directories, and the third example uses -e to show the server’s export list.

# showmount -a

All mount points on bubba.example.com:

192.168.0.0/24:/media

192.168.0.1:192.168.0.0/24

# showmount -d

Directories on bubba.example.com:

/media

# showmount -e

Export list for bubba.example.com:

/media 192.168.0.0/24

The showmount command is most useful on potential NFS clients because they can identify the directories an NFS server is exporting. By the same token, however, this poses a security risk because, in the absence of entries in

/etc/hosts.deny

that forbid access to the portmapper, any host can obtain this information from an NFS server.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 290

290 Chapter 12

Using Secure NFS

Although NFSv4 is installed, the default installation does not use NFSv4’s security enhancements by default. You need to set this up manually. To do so, use the following procedure:

1. Enable secure NFS by adding the following line to /etc/sysconfig

/nfs

:

SECURE_NFS=no

/etc/sysconfig/nfs does not exist on Fedora Core 4 and RHEL 4 systems. To use Kerberos 5 or other strong encryption mechanism with

NFSv4, you should set this variable to yes.

2. Edit /etc/idmapd.conf and set the Domain option to your domain and change the Nobody-User and Nobody-Group options to nobody:

Domain = example.com

[Mapping]

Nobody-User = nobody

Nobody-Group = nobody

You might not have to make this change because idmapd.conf is usually configured to use the nobody user and group by default.

3. Restart the portmapper and NFS using the service utility:

# service portmap restart

# service nfs condrestart

You do not need to start the GSS client and server daemons, rpcgssd and rpcsvcgssd, respectively, unless you wish to use Kerberos 5 or another strong encryption mechanism (in which case there is additional setup to perform that this chapter does not address).

Once the daemons are running, you can configure your server as described in the next section. You’ll learn how to mount the exports in the section titled

“Configuring an NFS Client.”

Example NFS Server

This section illustrates a simple but representative NFS server configuration. It exports two file systems, /home and /media. Here are the corresponding entries in /etc/exports:

/home 192.168.0.0/24(rw,async,no_subtree_check)

/media 192.168.0.0/24(ro)

18_599496 ch12.qxd 8/30/05 6:42 PM Page 291

The Network File System 291

With the exports configured, start (or restart) the daemons (the portmapper is already running) using the initialization scripts:

# service nfs start

Starting NFS services: [ OK ]

Starting NFS quotas: [ OK ]

Starting NFS mountd: [ OK ]

Starting NFS daemon: [ OK ]

# service nfslock start

Starting NFS file locking services:

Starting NFS statd: [ OK ]

Next, use rpcinfo -p to make sure the necessary daemons are running, then finish up with showmount -a (or exportfs -v) to list the server’s NFS exports:

# rpcinfo -p program vers proto port

100000 2 tcp 111 portmapper

100000 2 udp 111 portmapper

100011 1 udp 958 rquotad

100011 2 udp 958 rquotad

100011 1 tcp 961 rquotad

100011 2 tcp 961 rquotad

100003 2 udp 2049 nfs

100003 3 udp 2049 nfs

100003 4 udp 2049 nfs

100003 2 tcp 2049 nfs

100003 3 tcp 2049 nfs

100003 4 tcp 2049 nfs

100021 1 udp 37737 nlockmgr

100021 3 udp 37737 nlockmgr

100021 4 udp 37737 nlockmgr

100021 1 tcp 35981 nlockmgr

100021 3 tcp 35981 nlockmgr

100021 4 tcp 35981 nlockmgr

100005 1 udp 974 mountd

100005 1 tcp 977 mountd

100005 2 udp 974 mountd

100005 2 tcp 977 mountd

100005 3 udp 974 mountd

100005 3 tcp 977 mountd

# showmount -e

Export list for bubba.example.com:

/home 192.168.0.0/24

/media 192.168.0.0/24

18_599496 ch12.qxd 8/30/05 6:42 PM Page 292

292 Chapter 12

The final step in preparing an NFS server is to ensure that NFS services are started at boot time. You can use the Services Configuration Tool (Red Hat ➪

System Settings ➪ Server Settings ➪ Services on Fedora Core and Applications ➪ System Settings ➪ Server Settings ➪ Services on RHEL); systemconfig-services at the command line, or the chkconfig command-line services administration tool. Using chkconfig, execute the following commands:

# chkconfig --level 0123456 nfs off

# chkconfig --level 0123456 nfslock off

# chkconfig --level 345 nfs on

# chkconfig --level 345 nfslock on

The first two commands disable the nfs and nfslock initialization scripts for all run levels. The second two commands reenable them for run levels 3, 4, and 5. After you have confirmed that the NFS daemons are running and that the exports are available, you are ready to configure one or more NFS clients.

First, however, for the graphically addicted (or the command-line-challenged), we’ll show you how to use Red Hat Linux’s graphical tool for administering

NFS exports, the NFS Server Configuration Tool.

Using the NFS Server Configuration Tool

If you prefer to use graphical tools for system administration, Red Hat Linux includes the NFS Server Configuration tool. It edits the /etc/exports file directly, so you can use the graphical tool and edit the configuration file directly using a text editor interchangeably. To start the NFS Server Configuration tool, select Red Hat ➪ System Settings ➪ Server Settings ➪ NFS on Fedora Core or

Applications ➪ System Settings ➪ Server Settings ➪ NFS on RHEL. You can also start the tool by executing the command system-config-nfs (as root) in a terminal window. Figure 12-2 shows the NFS Server Configuration tool.

To add a new export, click the Add button, which opens the Add NFS Share dialog box (see Figure 12-3). On the Basic tab, type the name of the directory you want to export in the Directory text box or use the Browse button to locate the directory to export. Use the Host(s) text box to indicate which hosts are allowed to mount this directory. Click the Read-only radio button (selected by default) or the Read/Write radio button to indicate the basic access permissions for this export.

Figure 12-3, for example, shows that /home will be exported read-write to all hosts with an IP address in the range 192.168.0.0/24. Notice that you can use the same syntax for specifying IP addresses in this NFS Server Configuration tool that you can if you edit /etc/exports directly.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 293

The Network File System 293

Figure 12-2 The NFS Server Configuration dialog box.

Figure 12-3 The Add NFS Share dialog box.

To modify the mount options for your new NFS export, click the General

Options tab. On this tab, click the check boxes to enable the corresponding mount option. The possible mount options include:

■■

Allow connections from ports 1024 and higher

— This option corresponds to the insecure option listed in Table 12-1.

■■

Allow insecure file locking

— This option corresponds to the insecure_locks option listed in Table 12-1.

■■

Disable subtree checking

— This option corresponds to the no_subtree_check option listed in Table 12-1.

■■

Sync write operations on request

— This option (enabled by default) corresponds to the sync option listed in Table 12-1.

■■

Force sync of write operations immediately

— This option is only available if Sync write operations on request is enabled and corresponds to the no_wdelay option listed in Table 12-1.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 294

294 Chapter 12

■■

■■

Hide filesystems beneath

— This option corresponds to the hide option listed in Table 12-1.

Export only if mounted

— This option corresponds to the mp[=path] option listed in Table 12-1. Selecting this option is equivalent to specify the mp mount option with out the optional path mount point.

■■

Optional mount point

— This option corresponds to the path portion of the mp[=path] option listed in Table 12-1. You can type the mount point, if you want to specify on, the text box or use the Browse button to select the mount point graphically.

■■

Set explicit Filesystem ID

— This option corresponds to the fsid=n option listed in Table 12-1. Enter the actual FSID value in the text box.

Figure 12-4 shows the General Options tab. We have disabled subtree checking for /home and left the required sync option (Sync write operations on request) enabled.

The User Access tab, shown in Figure 12-5, implements the UID/GID remapping and root-squashing options described earlier in this chapter. Select the Treat remote root user as local root user check box if you want the equivalent of no_root_squash. To remap all UIDs and GIDs to the UID and GID of the anonymous user (the all_squash option from Table 12-1), select the Treat all client users as anonymous users check box. As you might guess, if you want to specify the anonymous UID or GID, click the corresponding check boxes to enable these options and then type the desired value in the matching text boxes. In Figure 12-5, all clients will be remapped to the anonymous user.

Figure 12-5 shows the User Access Tab as it appears in Fedora Core; it looks slightly different in RHEL.

Figure 12-4 The General Options tab.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 295

The Network File System 295

Figure 12-5 The User Access tab.

When you have finished configuring your new NFS export, click the OK button to close the Add NFS Share dialog box. After a short pause, the new

NFS share appears in this list of NFS exports, as shown in Figure 12-6. If you want to change the characteristics of an NFS share, select the share you want to modify and click the Properties button on the toolbar. This will open the

Edit NFS Share dialog box, which has the same interface as the Add NFS Share dialog box.

Similarly, if you want to remove an NFS share, select the export you want to cancel and click the Delete button. To close the NFS Server Configuration tool, type Ctrl+Q or click File ➪ Quit on the menu bar.

Figure 12-6 Adding an NFS share.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 296

296 Chapter 12

Configuring an NFS Client

Configuring client systems to mount NFS exports is simpler than configuring the NFS server itself. This section of the chapter provides a brief overview of client configuration, identifies the key files and commands involved in configuring and mounting NFS exported file systems, and shows you how to configure a client to access the NFS exports configured in the previous section.

Configuring a client system to use NFS involves making sure that the portmapper and the NFS file locking daemons statd and lockd are available, adding entries to the client’s /etc/fstab for the NFS exports, and mounting the exports using the mount command.

As explained at the beginning of the chapter, a mounted NFS exported file system is functionally equivalent to a local file system. Thus, as you might expect, you can use the mount command at the command line to mount NFS exports manually, just as you might mount a local file system. Similarly, to mount NFS exports at boot time, you just add entries to the file system mount table, /etc/fstab. As you will see in the section titled “Using Automount

Services” at the end of this chapter, you can even mount NFS file systems automatically when they are first used, without having to mount them manually.

The service that provides this feature is called, yup, you guessed it, the auto-

mounter. More on the automounter in a moment.

As a networked file system, NFS is sensitive to network conditions, so the

NFS client daemons accept a few options, passed via the mount command, address NFS’s sensitivities and peculiarities. Table 12-4 lists the major NFSspecific options that mount accepts. For a complete list and discussion of all

NFS-specific options, see the NFS manual page (man nfs).

Table 12-4 NFS-Specific Mount Options

OPTION DESCRIPTION

bg fg

Enables mount attempts to run in the background if the first mount attempt times out (disable with nobg).

Causes mount attempts to run in the foreground if the first mount attempt times out, the default behavior (disable with nofg

).

hard intr

Enables failed NFS file operations to continue retrying after reporting “server not responding” on the system, the default behavior (disable with nohard).

Allow signals (such as Ctrl+C) to interrupt a failed NFS file operation if the file system is mounted with the hard option

(disable with nointr). Has no effect unless the hard option is also specified or if soft or nohard is specified.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 297

The Network File System 297

Table 12-4 (continued)

OPTION DESCRIPTION

lock

Enables NFS locking and starts the statd and lockd daemons (disable with nolock).

mounthost=name mountport=n nfsvers=n port=n posix

Sets the name of the server running mountd to name.

Sets the mountd server port to connect to n (no default).

Specify the NFS protocol version to use, where n is 1, 2, 3, or 4.

Sets the NFS server port to which to connect to n (the default is 2049).

Mount the export using POSIX semantics so that the POSIX pathconf command will work properly.

retry=n rsize=n soft tcp timeo=n udp wsize=n

Sets the time to retry a mount operation before giving up to n minutes (the default is 10,000).

Sets the NFS read buffer size to n bytes (the default is

1024

); for NFSv4, the default value is 8192.

Allows an NFS file operation to fail and terminate (disable with nosoft).

Mount the NFS file system using the TCP protocol (disable with notcp).

Sets the RPC transmission timeout to n tenths of a second

(the default is 7). Especially useful with the soft mount option.

Mount the NFS file system using the UDP protocol, the default behavior (disable with noupd).

Sets the NFS write buffer size to n bytes (the default is

1024

); for NFSv4, the default value is 8192.

The options you are most likely to use are rsize, wsize, hard, intr, and nolock

. Increasing the default size of the NFS read and write buffers improves NFS’s performance. The suggested value is 8192 bytes, that is, rsize=8192 and wsize=8192, but you might find that you get better performance with larger or smaller values. The nolock option can also improve performance because it eliminates the overhead of file locking calls, but not all servers support file locking over NFS. If an NFS file operation fails, you can use a keyboard interrupt, usually Ctrl+C, to interrupt the operation if the exported file system was mounted with both the intr and hard options. This prevents NFS clients from hanging.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 298

298 Chapter 12

Like an NFS server, an NFS client needs the portmapper running in order to process and route RPC calls and returns from the server to the appropriate port and programs. Accordingly, make sure that the portmapper is running on the client system using the portmap initialization script:

# service portmap status

If the output says portmap is stopped (it shouldn’t be), start the portmapper:

# service portmap start

To use NFS file locking, both an NFS server and any NFS clients need to run statd and lockd. As explained in the section on configuring an NFS server, the simplest way to accomplish this is to use the initialization script, /etc

/rc.d/init.d/nfslock

. Presumably, you have already started nfslock on the server, so all that remains is to start it on the client system:

# service nfslock start

Once you have configured the mount table and started the requisite daemons, all you need to do is mount the file systems. You learned about the mount command used to mount file systems in a previous chapter, so this section shows only the mount invocations needed to mount NFS file systems.

During initial configuration and testing, it is easiest to mount and unmount

NFS export at the command line. For example, to mount /home from the server configured at the end of the previous section, execute the following command as root:

# mount -t nfs bubba:/home /home

You can, if you wish, specify client mount options using mount’s -o argument, as shown in the following example.

# mount -t nfs bubba:/home /home -o rsize=8292,wsize=8192,hard,intr,nolock

After satisfying yourself that the configuration works properly, you probably want to mount the exports at boot time. Fortunately, Fedora Core and RHEL make this easy because the initialization script /etc/rc.d/init.d/netfs, which runs at boot time, automatically mounts all networked file systems not configured with the noauto option, including NFS file systems. It does this by parsing /etc/fstab looking for file systems of type nfs, nfs4 (described in the next section), smbfs (Samba) cifs (Common Internet Filesystem) or ncpfs

(Netware) and mounting those file systems.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 299

The Network File System 299

T I P

If you are connecting an NFSv4 client to an NFSv2 server, you must use

the mount option nfsvers=2 or the mount attempt will fail. Use nfsvers=1

if you are connecting to an NFSv1 server. We learned this the hard way while trying to mount an export from an ancient server running Red Hat Linux 6.2

(we told you it was ancient). We kept getting an error indicating the server was down when we knew it wasn’t. Finally, we logged into the server, discovered it was running a very old distribution and were able to mount the export.

While we’re somewhat embarrassed to be running such an old version of Red

Hat, we’re also quite pleased to report that it has been running so well for so long that we forgot just how old it was.

Configuring an NFSv4 Client

The introduction of NFSv4 into the kernel added some NFSv4-specific behavior of which you need to be aware and changed some of the mount options.

This section covers NFSv4-specific features and begins with the mount options that have changed in terms of their meaning or behavior. Table 12-5 lists the new or changed mount options.

The two new options listed in Table 12-5 are clientaddr and proto. Version 3 of NFS introduced NFS over TCP, which improved NFS’s reliability over the older UDP-based implementation. Under NFSv3, you would use the mount option tcp or udp to specify to the client whether you wanted it to use TCP or

UDP to communicate with the server. NFSv4 replaces tcp and udp with a single option, proto= that accepts two arguments: tcp or udp. In case it isn’t clear, the NFSv3 option tcp is equivalent to the NFSv4 option proto=tcp.

Figuring out the udp option is left as an exercise for the reader.

Table 12-5 NFSv4-Specific Mount Options

OPTION DESCRIPTION

clientaddr=n proto=type rsize=n sec=mode wsize=n

Causes a client on a multi-homed system to use the IP address specified by n to communicate with an NFSv4 server.

Tells the client to use the network protocol specified by type, which can be tcp or udp (the default is udp); this option replaces the tcp and udp options from earlier versions of NFS.

Sets the read buffer size to n bytes (the default for NFSv4 is

8192

); the maximum value is 32678.

Set the security model to mode, which can be sys, krb5, krb5i

, or krb5p.

Sets the write buffer size to n bytes (the default for NFSv4 is

8192

); the maximum value is 32678.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 300

300 Chapter 12

The semantics for the rsize and wsize options have changed with NFSv4.

The default buffer size is for NFSv4 is 8192 bytes, but it can grow to as large and 32,678 bytes, which should result in a noticeable performance improvement, especially when you are transferring large files. The buffer setting is only a suggestion, however, because the client and server negotiate the buffer size to select an optimal value according to network conditions.

Strictly speaking, the sec option for selecting the security model NFS uses isn’t new with NFSv4. It existed in NFSv3, but now that NFSv4 has added strong encryption to the core NFS protocol, using this option is worthwhile. As shown in Table 12-5, legal values for the sec option are sys, krb5, krb5i, and krb5p. sys, the default security model, uses standard Linux UIDs and

GIDs to authenticate NFS transactions. krb5 uses Kerberos 5 to authenticate users but takes no special measures to validate NFS transactions; krb5i (Kerberos 5 with integrity checking) uses Kerberos 5 to authenticate users and checksums to enforce the data integrity on NFS transactions; krb5p (Kerberos

5 with privacy checking) uses Kerberos 5 to authenticate users and encryption to protect NFS transactions against packet sniffing. You can use the various

Kerberos-enabled security models only if the NFS server supports both NFSv4

and the requested security model.

Example NFS Client

The example in this section demonstrates how to mount /home and /usr

/local from the NFS server configured earlier in the chapter.

1. Clients that want to use both exports need to have the following entries in /etc/fstab: bubba:/usr/local /usr/local nfs rsize=8192,wsize=8192,hard,intr,nolock 0 0 bubba:/home /home nfs rsize=8192,wsize=8192,hard,intr,nolock 0 0

The hostname used on the left side of the colon, bubba, must resolve to an IP address either using DNS or an entry in the /etc/hosts file. We don’t recommend using an IP address because, in a well-run system, IP addresses can change, whereas a hostname won’t. If DNS is properly configured and maintained, the hostname will always point to the proper system regardless of what that system’s IP address is at any given time.

2. If it isn’t already running, start the portmapper using the following command:

# service portmap start

Starting portmapper: [ OK ]

18_599496 ch12.qxd 8/30/05 6:42 PM Page 301

The Network File System 301

3. Mount the exports using one of the following commands:

# mount –a –t nfs or

# mount /home /usr/local or

# service netfs start

The first command mounts all (-a) file systems of type nfs (-t nfs).

The second command mounts only the file systems /home and

/usr/local

(for this command to work, the file systems you want to mount must be listed in /etc/fstab). The third command uses the service command to mount all network file systems using by invoking the netfs service. Verify that the mounts completed successfully by attempting to access files on each file system. If everything works as designed, you are ready to go.

If all the preceding seems unnecessarily tedious, it only seems that way because it is more involved to explain how to set up an NFS client than it is actually to do it. Once you’ve done it a couple of times, you’ll be able to dazzle your friends and impress your coworkers with your wizardly mastery of NFS.

You can really wow them after reading the next section, which shows you how to avoid the tedium by using the automounter to mount file systems automatically the first time you use them.

Using Automount Services

The easiest way for client systems to mount NFS exports is to use autofs, which automatically mounts file systems not already mounted when the file system is first accessed. autofs uses the automount daemon to mount and unmount file systems that automount has been configured to control. Although slightly more involved to configure than the other methods for mounting NFS file systems, autofs setup has to be done only once. In the next chapter, you’ll even learn how to distribute automounter configuration files from a central server, obviating the need to touch client systems manually at all.

autofs uses a set of map files to control automounting. A master map file,

/etc/auto.master

, associates mount points with secondary map files. The secondary map files, in turn, control the file systems mounted under the corresponding mount points. For example, consider the following /etc/auto

.master autofs configuration file:

/home /etc/auto.home

/var /etc/auto.var --timeout 600

18_599496 ch12.qxd 8/30/05 6:42 PM Page 302

302 Chapter 12

This file associates the secondary map file /etc/auto.home with the mount point /home and the map file /etc/auto.var with the /var mount point. Thus, /etc/auto.home defines the file systems mounted under

/home

, and /etc/auto.var defines the file systems mounted under /var.

Each entry in /etc/auto.master, what we’ll refer to as the master map file, consists of at least two and possibly three fields. The first field is the mount point. The second field identifies the full path to the secondary map file that controls the map point. The third field, which is optional, consists of options that control the behavior of the automount daemon.

In the example master map file, the automount option for the /var mount point is --timeout 600, which means that after 600 seconds (10 minutes) of inactivity, the /var mount point will be umounted automatically. If a timeout value is not specified, it defaults to 300 seconds (5 minutes).

The secondary map file defines the mount options that apply to file systems mounted under the corresponding directory. Each line in a secondary map file has the general form:

localdir [-[options]] remotefs

localdir refers to the directory beneath the mount point where the NFS mount will be mounted. remotefs specifies the host and pathname of the NFS mount. remotefs is specified using the host:/path/name format described in the previous section. options, if specified, is a comma-separated list of mount options. These options are the same options you would use with the mount command.

Given the entry /home /etc/auto.home in the master map file, consider the following entries in /etc/auto.home: kurt -rw,soft,intr,rsize=8192,wsize=8192 luther:/home/kurt terry luther:/home/terry

In the first line, localdir is kurt, options is -rw,soft,intr,rsize=8192, wsize=8192

, and remotefs is luther:/home/kurt. This means that the NFS export /home/kurt on the system named luther will be mounted in /home

/kurt in read-write mode, as a soft mount, with read and write buffer sizes of

8192 bytes. A key point to keep in mind is that if /home/kurt exists on the local system, its contents will be temporarily replaced by the contents of the

NFS mount /home/kurt. In fact, it is probably best if the directory specified by localdir does not exist because autofs dynamically creates it when it is first accessed.

The second line of the example auto.home file specifies localdir as terry, no options, and remotefs as the NFS exported directory /home/terry exported from the system named luther. In this case, then, /home/terry on luther will be mounted as /home/terry on the NFS client using the default NFS

18_599496 ch12.qxd 8/30/05 6:42 PM Page 303

The Network File System 303

mount options. Again, /home/terry should not exist on the local system, but the base directory, /home, should exist.

Suppose that you want to use autofs to mount a shared projects directory named /proj on client systems on the /projects mount point. On the NFS server (named diskbeast in this case), you would export the /proj as described in the section “Configuring an NFS Server.” On each client that will mount this export, create an /etc/auto.master file that resembles the following:

/projects /etc/auto.projects --timeout 1800

This entry tells the automount daemon to consult the secondary map file

/etc/auto.projects

for all mounts located under /projects. After 1800 seconds without file system activity in /projects, autofs will automatically unmount it.

N OT E

If the autofs RPM is installed, Fedora Core and RHEL systems provide a

default /etc/auto.master map file. All of the entries are commented out

using the # sign, so you can edit the existing file if you wish.

Next, create the following /etc/auto.projects file on each client that will use diskbeast’s export: code -rw,soft,rsize=8192,wsize=8192 diskbeast:/proj

This entry mounts /proj from mailbeast as /projects/code on the client system. The mount options indicate that the directory will be read/write, that it will be a soft mount, and that the read and write block sizes are 8192 bytes. Recall from Table 12-4 that a soft mount means that the kernel can time out the mount operation after a period of time specified by the timeo=n option, where n is defined in tenths of a second.

Finally, as the root user, start the autofs service:

# /sbin/service autofs start

Starting automount: [ OK ]

After starting the autofs service, you can use the status option to verify that the automount daemon is working:

# /sbin/service autofs status

Configured Mount Points:

------------------------

/usr/sbin/automount --timeout 600 /projects file /etc/auto.projects

Active Mount Points:

--------------------

/usr/sbin/automount --timeout 600 /projects file /etc/auto.projects

18_599496 ch12.qxd 8/30/05 6:42 PM Page 304

304 Chapter 12

As you can see under the heading Active Mount Points, the /projects mount point is active. You can verify this by changing to the /projects/code directory and executing an ls command:

# cd /projects/code

# ls

3c501.c atp.c fmv18x.c net_init.c smc9194.c

3c503.c au1000_eth.c gmac.c ni5010.c smc-mca.c

3c505.c auto_irq.c gt96100eth.c ni52.c smcultra32.c

3c507.c bagetlance.c hamachi.c ni65.c smc-ultra.c

3c509.c bmac.c hp100.c ns83820.c sonic.c

You can also see the automount daemon at work by using the mount command:

# mount -t autofs automount(pid11081) on /projects type autofs

(rw,fd=4,pgrp=11081,minproto=2,maxproto=4)

# mount -t nfs diskbeast:/proj on /projects/code type nfs

(rw,soft,rsize=8192,wsize=8192,nfsvers=2,addr=192.168.0.1)

Using mount’s -t option limits the output to file systems of the specified type, autofs for automounted file systems, and nfs for NFS file systems.

The first output line shows that automount is managing the /projects file system; the second line shows that the automount-managed file system has mounted the NFS file system diskbeast:/proj on /projects using the options specified in /etc/auto.projects.

To stop the automounter, use the service script’s stop argument:

# /sbin/service autofs stop

Stopping automount: [ OK ]

One of the handiest features of the autofs service is that changes made to the secondary map files go into effect almost immediately. The next time that a directory or file system managed by autofs is accessed, the automounter rereads the secondary map files. So, changes to the secondary map files do not require any special treatment. However, if you modify the master map file, you have to reload the configuration file using the following command:

/sbin/service autofs reload

18_599496 ch12.qxd 8/30/05 6:42 PM Page 305

The Network File System 305

Examining NFS Security

As explained at the beginning of the chapter, NFS protocol versions 3 and older have some inherent security problems that make it unsuitable for use across the

Internet and potentially unsafe for use even in a trusted network. This section identifies key security issues of NFS in general and the security risks specific to an NFS server and to NFS clients and suggests remedies that minimize your network’s exposure to these security risks. Be forewarned, however, that no list of security tips, however comprehensive, makes your site completely secure.

Nor will plugging possible NFS security holes address other potential exploits.

General NFS Security Issues

One NFS weakness, in general terms, is the /etc/exports file. If a cracker is able to spoof or take over a trusted address, an address listed in /etc/exports, your exported NFS mounts are accessible. Another NFS weak spot is normal

Linux file system access controls that take over once a client has mounted an

NFS export: Once an NFS export has been mounted, normal user and group permissions on the files take over access control.

The first line of defense against these two weaknesses is to use host access control as described earlier in the chapter to limit access to services on your system, particularly the portmapper, which has long been a target of exploit attempts. Similarly, you should add entries in /etc/hosts.deny lockd, statd

, mountd, and rquotad.

More generally, judicious use of IP packet firewalls, using netfilter, dramatically increases NFS server security. netfilter is stronger than NFS daemon-level security or even TCP Wrappers because it restricts access to your server at the packet level. Although netfilter is described in detail in Chapter 34, this section gives you a few tips on how to configure a netfilter firewall that plays nicely with NFS.

First, you need to know the ports and services NFS uses so that you know where to apply the packet filters. Table 12-6 lists the ports and protocols each

NFS daemon (on both the client and server side) use.

Table 12-6 NFS Ports and Network Protocols

SERVICE PORT PROTOCOLS

portmap nfsd mountd

111

2049 variable

TCP, UDP

TCP, UDP

TCP, UDP

(continued)

18_599496 ch12.qxd 8/30/05 6:42 PM Page 306

306 Chapter 12

Table 12-6 (continued)

SERVICE PORT

lockd statd rquotad variable variable variable

PROTOCOLS

TCP, UDP

TCP, UDP

UDP

N OT E

Before NFSv4, NFS over TCP was experimental on the server side, so most administrators used UDP on the server. However, TCP is quite stable on

NFS clients. Nevertheless, using packet filters for both protocols on both the client and the server does no harm. NFSv4’s server-side TCP code is much more stable than NFSv3, so it is safe for deployment in a production environment.

Note that mountd, lockd, statd, and rquotad do not bind to any specific port; that is, they use a port number assigned randomly by the portmapper

(which is one of portmapper’s purposes in the first place). The best way to address this variability is to assign each daemon a specific port using the portmapper’s -p option and then to apply the packet filter to that port.

Regardless of how you configure your firewall, you must have the following rule: iptables -A INPUT -f -j ACCEPT

This rule accepts all packet fragments except the first one (which is treated as a normal packet) because NFS does not work correctly unless you let fragmented packets through the firewall. Be sure to read Chapter 34 carefully to configure your NFS server’s firewall properly.

Server Security Considerations

On the server, always use the root_squash option in /etc/exports. NFS helps you in this regard because root squashing is the default, so you should not disable it (with no_root_squash) unless you have an extremely compelling reason to do so, such as needing to provide boot files to diskless clients.

With root squashing in place, the server substitutes the UID of the anonymous user for root’s UID/GID (0), meaning that a client’s root account cannot change files that only the server’s root account can change.

The implication of root squashing might be unclear, so we’ll make it explicit: all critical binaries and files should be owned by root, not bin, wheel, adm or another non-root account. The only account that an NFS client’s root user cannot access is the server’s root account, so critical files owned by root are much less exposed than if they are owned by other accounts.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 307

The Network File System 307

It gets better, though. Consider the situation in which a user has root access on a system. In this case, exporting file systems using the all_squash option might be worth considering. A user with root access on a client can usually su to any user, and that UID will be used over NFS. Without all_squash, a compromised client can at least view and, if the file system is mounted read-write, update files owned by any user besides root if root_squash is enabled. This security hole is closed if the all_squash option is used.

NFS also helps you maintain a secure server through the secure mount option; because this mount option is one of the default options mountd applies to all exports unless explicitly disabled using the insecure option.

Ports 1–1024 are reserved for root’s use; merely mortal user accounts cannot bind these ports. Thus, ports 1–1024 are sometimes referred to as privileged or

secure ports. The secure option prevents a malevolent nonroot user from initiating a spoofed NFS dialog on an unprivileged port and using it as a launch point for exploit attempts.

Client Security Considerations

On the client, disable SUID (set UID) root programs on NFS mounts using the nosuid option. The nosuid mount option prevents a server’s root account from creating an SUID root program on an exported file system, logging in to the client as a normal user, and then using the UID root program to become root on the client. In some cases, you might also disable binaries on mounted file systems using the noexec option, but this effort almost always proves to be impractical or even counterproductive because one of the benefits of NFS is sharing file systems, such as /usr or /usr/local, that contain scripts or programs that need to be executed.

T I P

You might not want to use nosuid if you are sharing system binary

directories, because many things in /bin and /usr/bin will break if they are

not SUID.

NFS versions 3 and 4 support NFS file locking. Accordingly, NFS clients must run statd and lockd in order for NFS file locks to function correctly.

statd and lockd, in turn, depend on the portmapper, so consider applying the same precautions for portmap, statd, and lockd on NFS clients that were suggested for the NFS server.

In summary, using TCP wrappers, the secure, root_squash, and nosuid options, and sturdy packet filters can increase the overall security of your NFS setup. However, NFS is a complex, nontrivial subsystem, so it is entirely conceivable that new bugs and exploits will be discovered.

18_599496 ch12.qxd 8/30/05 6:42 PM Page 308

308 Chapter 12

Summary

In this chapter, you learned to configure NFS, the Network File System. First, you found a general overview of NFS, its typical uses, and its advantages and disadvantages. Next, you found out how to configure an NFS server, you identified key files and commands to use, and you saw the process with a typical real-world example. With the server configured and functioning, you then learned how to configure a client system to access NFS exported file systems, again using key configuration files and commands and simulating the procedure with a representative example. You also learned how to address NFS performance problems and how to troubleshoot some common NFS errors. The chapter’s final section identified potential security problems with NFS and suggested ways to mitigate the threat.

19_599496 ch13.qxd 8/30/05 6:24 PM Page 309

C H A P T E R

13

The Network

Information System

IN THIS CHAPTER

■■

■■

■■

■■

■■

Understanding NIS

Planning an NIS Installation

Configuring an NIS Server

Configuring an NIS Client

Using NIS and NFS Together

A common challenge facing administrators charged with maintaining a network of Linux machines is sharing information across the network while maintaining that information centrally. The Network Information Service (NIS) is one solution to such a challenge. This chapter describes NIS and explains how to configure an NIS server and an NIS client. You’ll also learn how to integrate

NIS and NFS, which can significantly simplify administering a large or geographically dispersed network.

Understanding NIS

NIS distributes information that needs to be shared throughout a Linux network to all machines that participate in the NIS domain. Originally developed by Sun Microsystems, NIS was first known as Yellow Pages (YP), so many

NIS-related commands begin with the letters yp, such as ypserv, ypbind, and yppasswd. Unfortunately for Sun, the phrase “Yellow Pages” was (and is) a registered trademark of British Telecom in the United Kingdom, so Sun changed the name of their Yellow Pages services to Network Information Service. Despite the name change, however, the NIS suite of utilities retained the yp prefixes because administrators had become accustomed to them.

309

19_599496 ch13.qxd 8/30/05 6:24 PM Page 310

310 Chapter 13

The information most commonly shared using NIS consists of user authentication information, such as /etc/passwd and /etc/group. If users’ password entries are accessible to all login hosts via NIS, any user can log in on any login host on the network that is running an NIS client. However, sharing authentication information is far from the only use for NIS; any information that needs to be distributed across a network and that can or should be centrally administered is a viable candidate for sharing via NIS. For instance, you can use NIS to distribute a company telephone directory or a listing of accounting codes. One of the examples in this chapter shows you how to distribute NFS automounter configuration files using NIS, which eliminates the need to edit automount files individually on each NFS client system.

Like NFS, NIS uses a standard client-server architecture that can be arrayed in one of several possible configurations. Each NIS domain must have at least one NIS server. An NIS server is a centrally administered repository for information shared across the network using NIS. NIS clients are programs that use

NIS to query designated servers for information that is stored in the servers’ databases, which are known as maps. NIS maps are stored in DBM format, a binary file format derived from simple ASCII text files. For example, the files

/etc/passwd and /etc/group can be converted directly to DBM databases using an ASCII-to-DBM conversion program named makedbm.

N OT E

Do not be confused by the use of the word database. As used in this chapter, database refers to a centralized store of information, not to refer to relational database management systems (RDBMSs) such as Oracle, PostgreSQl, or MySQL.

NIS servers can be further subdivided into master and slave servers. A mas-

ter server maintains the authoritative copies of the NIS maps. A slave server maintains copies of the maps, which it receives from the master. If the maps on the master server change, the slaves receive updated copies. Slave servers receive copies of the DBM databases, not the ASCII source files. The yppush program notifies slave servers of changes to the NIS maps, and then the slaves automatically retrieve the updated maps in order to synchronize their databases with the master. The purpose of slave servers is to provide redundancy.

On a busy network, slave servers can reduce the load on the master server.

More importantly, if the master server becomes unavailable for some reason, slave servers can function as backup servers until the master is again available.

NIS revolves around the notion of a domain. An NIS domain is a unique name that refers to any group of systems that use the same NIS maps. NIS domains function as system management tools providing a convenient method to organize groups of systems that need to access the same information set into

19_599496 ch13.qxd 8/30/05 6:24 PM Page 311

The Network Information System 311

a logical unit. NIS does not impose any physical restrictions on the make-up of a domain. While an NIS domain might consist of hosts on a single subnet or contain all of the systems in a single office or building, it doesn’t necessarily need to. At one place where Kurt worked, an NIS domain for the engineering group included hosts in both the United States and Germany.

Likewise, do not confuse an NIS domain with an Internet or DNS domain.

A DNS name (more specifically, a fully qualified domain name, or FQDN) is the official name that uniquely identifies a system to the Internet domain name system. In fact, although doing so is common practice, most NIS experts recommend not naming an NIS domain with the same name used in a DNS name or FQDN because such a naming convention is potentially confusing and makes it trivially easy for crackers to guess the name of your NIS domain. So, if your domain name is possumholler.com, avoid the temptation to name your NIS domain possumholler.

Before you proceed, make sure you have the NIS programs installed. For a complete installation, you need the following three packages:

■■ ypbind

■■ ypserv

■■ yp-tools

Planning an NIS Installation

Four NIS topologies are commonly used:

■■

A single domain with a master server, no slave servers, and one or more clients. (See Figure 13-1.)

■■

A single domain with a master server, one or more slave servers, and one or more clients. (See Figure 13-2.)

■■

Multiple domains, each with its own master server, no slave servers, and one or more clients. (See Figure 13-3.)

■■

Multiple domains, each with its own master server, one or more slave servers, and one or more clients. (See Figure 13-4.)

The single domain configurations are the most widely used. Figure 13-1 illustrates a typical single-domain/single-server configuration. The NIS domain name is admin. A single master server, admin-master, responds to all queries from NIS clients (client-1, client-2, and client-3) and is the sole source of information for the domain.

19_599496 ch13.qxd 8/30/05 6:24 PM Page 312

312 Chapter 13

admin

admin-master client-1 client-2 client-3

Figure 13-1 A single-domain/single-server NIS configuration.

Figure 13-2 shows the single-domain/multiple-server configuration. The admin domain shown in Figure 13-1 has a slave server, admin-slave, in addition to the master server, admin-master. In the modified configuration, client-1 and client-2 continue to query the master server, but client-3 communicates with the slave server when performing NIS queries. client-3 has not been configured specifically to communicate with admin-slave. Rather, client-3 sends out NIS broadcast messages to any listening server in its domain and accepts replies from any server authoritative for that domain — the server that “wins” is the server that replies first, whether it is a master or a slave.

At large sites or in complicated networks, you might find it necessary to create multiple NIS domains. Figures 13-3 and 13-4 illustrate such configurations.

Figure 13-3 shows two domains, admin and devel, each with its own master server, admin-master and devel-master. Clients in the admin domain (client-1, client-2, and client-3) communicate only with the admin-master server, and clients in the devel domain (client-4, client-5, and client-6) communicate only with devel-master.

Figure 13-4 illustrates the same setup as Figure 13-3, except that each domain has a slave server, admin-slave and devel-slave, and some of the clients in each domain communicate with the slave servers rather than with the master. As in the single-server example, any given client communicates with the server for its domain that responds the fastest to a broadcast query.

19_599496 ch13.qxd 8/30/05 6:24 PM Page 313

admin

admin-master admin-slave

The Network Information System 313

client-1 client-2 client-3

Figure 13-2 A single-domain/multiple-server NIS configuration.

admin

admin-master

devel

devel-master client-1 client-2 client-3 client-4 client-5 client-6

NETWORK

Figure 13-3 The multiple-domain/single-server NIS configuration.

19_599496 ch13.qxd 8/30/05 6:24 PM Page 314

314 Chapter 13

admin

admin-master admin-slave

devel

devel-master devel-slave client-1 client-2 client-3 client-4 client-5 client-6

NETWORK

Figure 13-4 The multiple-domain/multiple-server NIS configuration.

C A U T I O N

A singleton server (one whose function is not duplicated or replicated elsewhere in the network) that relies upon NIS for key data potentially represents a single point of failure. If your network or organization relies on the high availability of your network, NIS might not be an acceptable solution for information sharing unless you configure at least one slave server to provide redundancy and fail-over support for the master server.

A complete NIS setup involves configuring at least one NIS server and one or more NIS clients. If your Linux system is going to be part of a network with existing NIS servers, you only need to install and configure an NIS client programs, ypbind, ypwhich, ypcat, yppoll, and ypmatch. The most important program on an NIS client is the NIS client daemon, ypbind. ypbind is usually started from the system’s startup procedure. As soon as ypbind is running your system has become an NIS client.

On the other hand, if your system is going to be part of a network that does not already have NIS servers in place, you need to configure a master server and possibly one or more slave servers in addition to any NIS clients. Creating an NIS server involves configuring the ypserv client daemon and identifying the information that you want to distribute using NIS.

19_599496 ch13.qxd 8/30/05 6:24 PM Page 315

The Network Information System 315

Configuring an NIS Server

The simplest NIS configuration consists of a single NIS server and one or more clients. In this case, NIS server configuration involves the following steps:

1. Setting the NIS domain name.

2. Initializing the NIS maps.

3. Editing the configuration files.

4. Starting the server daemon, ypserv.

5. Starting the NIS password daemon.

6. Starting the NIS transfer daemon if you use slave servers.

7. Modifying the startup process to start the NIS daemons when the system reboots.

If your NIS configuration also utilizes slave servers, you need to perform configuration steps on the slave servers. This section shows you how to create an NIS master server and a slave server.

N OT E

For more information about NIS configuration, see the NIS How-To at the

Linux Documentation Project, linuxdoc.org/HOWTO/NIS-HOWTO/index.html,

and the NIS Web pages at www.linux-nis.org.

Key Files and Commands

Table 13-1 lists the commands, daemons, and configuration files used to configure and maintain an NIS server.

Table 13-1 NIS Server Configuration Commands and Files

COMMAND DESCRIPTION

/etc/ypserv.conf

Stores runtime configuration options and special host access directives nisdomainname

/var/yp/securenets ypinit yppasswdd

Sets a system’s NIS domain name

Lists hosts permitted to access the NIS maps

Builds and installs the NIS databases

Processes user password changes in an NIS environment

(continued)

19_599496 ch13.qxd 8/30/05 6:24 PM Page 316

316 Chapter 13

Table 13-1 (continued)

COMMAND

yppush ypserv ypxfrd

DESCRIPTION

Propagates updated NIS maps to slave servers

Handles the primary NIS server duties

Speeds up the transfer of large NIS maps from master to slave servers

The initial step in configuring an NIS client is to set the NIS domain name.

When first configuring the NIS server and for testing purposes, the quickest way to set an NIS domain name is to use the nisdomainname command:

# nisdomainname nisdomain

Replace nisdomain with the name of your NIS domain. Next, reissue the nisdomainname command with no arguments to confirm that the NIS domain name was successfully set. Setting the NIS domain name in this way is not a permanent change and will not survive a system reboot. You learn later in this section how to set the NIS domain name permanently.

N OT E

You can also use the domainname command to get and set a system’s

NIS domain name. In fact, you can use one of a number of similarly named

commands to do so. See the domainname man page for more information.

After you set the NIS domain name, configure the NIS server daemon, ypserv

. The key configuration files are /var/yp/securenets and /etc

/ypserv.conf

. /var/yp/securenets lists the hosts permitted to access the NIS maps on this server. /etc/ypserv.conf contains runtime configuration options and client access specifications that control ypserv and the NIS transfer daemon, ypxfrd.

The most important configuration file is /var/yp/securenets. As a rule,

RPC, on which NIS is based, happily replies to any client that asks for information. Obviously, you don’t want to share your password database, just for example, with any host that asks for it. So, securenets makes it possible to restrict access to NIS maps based on a requester’s IP address. The securenets file contains net mask and network number pairs that define the lists of hosts permitted to access your NIS server maps. /var/yp/securenets contains one pair per line of the form m.m.m.m n.n.n.n, where m.m.m.m. is a net mask, and n.n.n.n. is network number. A host match occurs when the IP address matches the network number and mask. For example, consider a /var/yp/securenets with these entries:

255.255.255.255 127.0.0.1

255.255.255.0 192.168.0.0

19_599496 ch13.qxd 8/30/05 6:24 PM Page 317

The Network Information System 317

The first line indicates that localhost (IP address 127.0.0.1) is permitted to access the NIS server. The second line specifies that any host with an IP address in the range 192.168.0.1 to 192.168.0.254 is permitted to access the NIS server. All other hosts are denied access.

The second configuration file, /etc/ypserv.conf, is used by both ypserv

, the primary NIS server daemon, and ypxfrd, the NIS transfer daemon. ypserv.conf contains two types of runtime configuration directives.

The first type of directive is known as an option line and is only used by ypserv

. The second configuration directive type is called an access rule. Access rules, used by ypserv and ypxfrd, determine which hosts may use NIS services and under what conditions. The following listing shows the default values in /etc/ypserv.conf: dns: no files: 30 slp: no slp_timeout: 3600 xfr_check_port: yes

*: *: shadow.byname: port

*: *: passwd.adjunct.byname: port

Entries in the file appear one per line. Option lines and access rules are made up of colon-separated fields. The first five entries in the example are option lines. The last two entries are access rules.

Option lines have the following format:

option:value option can be one of files, trusted_master, slp, slp_timeout, or xfr_check_port

.

■■

files:n

— Sets the number of maps that ypserv should cache. Setting n to 0 disables map caching.

■■

trusted_master:server

— Informs a slave server of the name of the server to accept as master. For instance, trusted_master

:nisbeast.example.com

tells the slave server to accept new or updated maps from the master NIS server nisbeast.example.com.

By default, no trusted master server is set.

■■

slp:{yes|no|domain}

— Indicates whether ypserv should use the

Service Location Protocol (SLP) and register itself as an SLP server. The default is no. If domain is set, ypserv registers itself as an NIS domain server for a specific group of NIS domains. The sidebar “A Hundred-

Word Tour of SLP” describes the Service Location Protocol.

19_599496 ch13.qxd 8/30/05 6:24 PM Page 318

318 Chapter 13

■■

■■

slp_timeout

— Defines the interval after which ypserv reregisters itself as an SLP server. This option is currently ignored.

xfr_check_port

— Controls whether ypserv runs on a port numbered less than 1024, a so-called privileged port. The default is yes.

As you can see in the default configuration file, the dns option is no. The absence of xfr_check_port from the configuration file means that ypserv uses a privileged port.

Access rules have a slightly more complicated format:

host:domain:map:security

■■

■■

host

— Specifies the IP address to match. Wildcards and address/net mask address forms are allowed. For example, the host values 192.168.0.

and 192.168.0.0/255.255.255.0 both refer to all IP addresses between

192.168.0.1 and 192.168.0.254.

domain

— Indicates the NIS domain to which the rule applies.

■■

■■

map

— Identifies the name of a map to match (or * for all maps).

security

— Indicates the type of security to use. Legal values are none, port

, or deny. A value of none enables access to map for host. port enables access if the connection comes from a privileged port (one numbered less than 1024). deny denies the matching host access to this map.

Access rules are tried in order, and all rules are evaluated. If no rule matches a connecting host, access to the corresponding map is enabled.

As usual with any RPC-based service, before starting the server, make sure that the portmapper daemon, portmap, is running. NIS requires the portmapper because NIS uses remote procedure calls (RPC). To see if the portmapper is running, you can use the portmapper’s initialization script, /etc/rc.d

/init.d/portmap

, or the rpcinfo command. If the portmapper is not running, you can easily start it. Using the initialization script, the command to execute and its output is:

# service portmap status portmap (pid 559) is running...

The output shows the process ID (PID) of the portmapper. On the other hand, if the portmapper is not running, the output of the command looks like the following:

# service portmap status portmap is stopped

19_599496 ch13.qxd 8/30/05 6:24 PM Page 319

The Network Information System 319

A HUNDRED-WORD TOUR OF SLP

SLP, the Service Location Protocol, provides a mechanism for networked applications to discover the presence, runtime behavior, and location of services available on a network (think Windows’ Network Neighborhood). The implementation used on Linux systems is OpenSLP, available on the Web at

www.openslp.org

. Ordinarily, to find and use network services, such as networked printers, one has to provide an address, name, or other parameters to locate and use the service. SLP eliminates this necessity by providing a queryresponse method to find out what services are available, the server(s) providing them, and the configuration details necessary for clients to access them.

To start the portmapper, execute the following command:

# service portmap start

Starting portmapper: [ OK ]

You can also use the rpcinfo command shown next to see if the portmapper is running:

# rpcinfo -u localhost portmapper program 100000 version 2 ready and waiting

# rpcinfo -t localhost portmapper program 100000 version 2 ready and waiting

The first command uses rpcinfo’s -u option to see if portmapper is listening on a UDP port on the host named localhost. The second command uses the

-t option to perform the same query on for a TCP port. If you do not see output indicating that the portmapper is running, use the initialization script shown previously to start the portmapper. Once you have the portmapper started, start the NIS server using the command:

# service ypserv start

Starting YP server services: [ OK ]

Next, use the following rpcinfo invocation to make sure that the server is running:

# rpcinfo -u localhost ypserv program 100004 version 1 ready and waiting program 100004 version 2 ready and waiting

After the NIS server is running, you have to create something for it to serve, which means you need to create the NIS databases on the machine acting as the

NIS server. The command for doing so is ypinit. ypinit builds a complete

19_599496 ch13.qxd 8/30/05 6:24 PM Page 320

320 Chapter 13

set of NIS maps for your system and places them in a subdirectory of /var/yp named after the NIS domain. As suggested earlier in this chapter, you should have only one master server per NIS domain. All databases are built from scratch, either from information available to the program at runtime or from the

ASCII database files in /etc. These files include (but aren’t limited to):

■■

/etc/passwd

■■

/etc/group

■■

/etc/hosts

■■

/etc/networks

■■

/etc/services

■■

/etc/protocols

■■

/etc/netgroup

■■

/etc/rpc

C A U T I O N

Long-time NIS users might recall needing to add the NIS entry

+::0:0::

to the bottom of /etc/passwd to indicate the end of local entries.

However, this entry spreads an opening for an NIS-based security exploit to all of your NIS clients. For obvious reasons, we won’t describe the nature of the exploit here, but you can read all about it the SecurityFocus Web site at

www.securityfocus.com

.

To create the NIS databases, execute the command /usr/lib/yp/ypinit -m.

# /usr/lib/yp/ypinit -m

The ypinit command uses the -m option to indicate that it is creating maps for the master server.

T I P

Before initializing the NIS databases, you might want to make backup copies of the source text files shown in the preceding list.

If you also configure one or more slave NIS servers, you need to make sure that they can successfully communicate with the master server. From each slave server, make sure that the command ypwhich -m works, which means that the slave servers must also be configured as NIS clients, as described in the section “Configuring an NIS Client,” later in this chapter. After configuring the slave server as described in that section, execute the command:

# /usr/lib/yp/ypinit -s master

19_599496 ch13.qxd 8/30/05 6:24 PM Page 321

The Network Information System 321

The -s option instructs ypinit to create a slave server using the databases from the master server specified by master. An NIS database on a slave server is set up by copying an existing database from a running server. master can also be a server on which the NIS maps are current and stable. Your NIS server is now up and running.

Starting the NIS Password Daemon

Because NIS is used to share authentication information, a method must exist for users to change this information on the NIS server and then to propagate the updated information out to other NIS clients and any slave servers that might be present. Similarly, when new users are added or existing users are deleted, clients and slaves must be notified of the change. The daemon that handles this requirement is yppasswdd. yppasswdd handles password changes and updating other NIS information that depends on user passwords.

yppasswdd runs only on the NIS master server. Starting the NIS password daemon is a simple matter of executing its initialization script with the start argument, as shown in the following example:

# service yppasswdd start

Starting YP passwd service: [ OK ]

Keep in mind that NIS users are not permitted, by default, to change their full name or their login shell. You can enable NIS users to change their login information by starting yppasswdd using the -e chfn option to allow name changes or the -e chsh option to allow login shell changes. You can make these changes by editing /etc/sysconfig/yppasswdd and modifying the line that begins YPPASSWDD_ARGS= so that it looks like the following:

YPPASSWDD_ARGS=”-e chfn -e chsh”

Starting the Server Transfer Daemon

ypxfrd

, which you need to use only if you run NIS slave servers, speeds up the transfer of large NIS maps from master to slave servers. Ordinarily, when a slave server receives a message from a master server that there is a new map, the slave starts ypxfr to transfer the new map. ypxfr reads the contents of a map from the master server one entry at a time. The transfer daemon, ypxfrd, speeds up the transfer process by enabling slave servers to copy the master’s maps rather than building their own from scratch. As with the password daemon, you run the transfer daemon on the master server only. To start the transfer daemon, execute the command:

# /sbin/service ypxfrd start

19_599496 ch13.qxd 8/30/05 6:24 PM Page 322

322 Chapter 13

If you need to update a map, run make in the /var/yp directory on the NIS master. This command updates a map if the source file is newer and propagates the new map out to the slave servers, if present.

Starting the NIS Servers at Boot Time

After you have configured your NIS server, you should make the system changes persistent, which means permanently storing the NIS domain name in the network configuration and ensuring that the required daemons

(ypserv, yppasswdd, and, if you use slave servers, ypxfrd) start and stop when the system starts and stops.

The first step is permanently saving the NIS domain name. To do this, add the following line to /etc/sysconfig/network:

NISDOMAIN=nisdomainname

Replace nisdomainname with the NIS domain name you selected when you initially configured your server. The networking initialization scripts read

/etc/sysconfig/network at boot time and pick up the domain name to use.

The next step is to use chkconfig to enable services at boot time. To start the ypserv and yppasswdd services, for example, use the following commands:

# chkconfig --levels 0123456 ypserv off

# chkconfig --levels 345 ypserv on

# chkconfig --levels 0123456 yppasswdd off

# chkconfig --levels 345 yppasswdd off

If you prefer graphical tools, use the Service Configuration tool. To do so, type system-config-services (as root) in a terminal window or select

Red Hat ➪ System Settings ➪ Server Settings ➪ Services. The resulting screen should resemble Figure 13-5.

Scroll down to the bottom of the list, and place check marks in the boxes next to the services you want to start at boot time. In Figure 13-6, for example, you can see that the yppasswdd service has been checked, meaning that it will start at boot time. The erstwhile administrator has enabled ypserv, too. Click the Save button to save your changes, and then select File ➪ Exit to close Service Configuration tool.

19_599496 ch13.qxd 8/30/05 6:24 PM Page 323

The Network Information System 323

Figure 13-5 The Service Configuration tool.

Figure 13-6 Enabling NIS at boot time.

19_599496 ch13.qxd 8/30/05 6:24 PM Page 324

324 Chapter 13

Configuring an Example NIS Server

This section illustrates the process of setting up a simple master server. The

NIS domain name is eng, running on the server nisbeast.example.com, which has an IP address 192.168.0.4. There are no slave servers, and all hosts in the example.com DNS domain are permitted to access the NIS server.

1. Set the NIS domain name:

# nisdomainname eng

# nisdomainname

eng

2. Edit /var/yp/securenets to permit access to the NIS server for the specified hosts. The default configuration enables all hosts to have access (0.0.0.0 0.0.0.0), so change that line to read 255.255.255.0

192.168.0.0

. The complete file now resembles the following:

255.255.255.255 127.0.0.1

255.255.255.0 192.168.0.0

N OT E

If /var/yp/securenets does not exist on your system, create it.

3. Make sure that the portmapper is running:

# rpcinfo -u nisbeast portmapper

program 100000 version 2 ready and waiting

4. Start the primary server daemon, ypserv:

# service ypserv start

Starting YP server services: [ OK ]

5. Confirm that ypserv is running:

# rpcinfo -u nisbeast ypserv

program 100004 version 1 ready and waiting program 100004 version 2 ready and waiting

6. Initialize the NIS maps:

# /usr/lib/yp/ypinit -m

At this point, we have to construct a list of the hosts which will run NIS servers. nistbeast.kurtwerks.com is in the list of NIS server hosts.

Please continue to add the names for the other hosts, one per line. When you are done with the list, type a <control D>.

next host to add: nisbeast.kurtwerks.com

next host to add:

The current list of NIS servers looks like this:

19_599496 ch13.qxd 8/30/05 6:24 PM Page 325

The Network Information System 325

nisbeast.kurtwerks.com

Is this correct? [y/n: y] y

We need a few minutes to build the databases...

Building /var/yp/eng/ypservers...

Running /var/yp/Makefile...

gmake[1]: Entering directory `/var/yp/eng’

Updating passwd.byname...

Updating passwd.byuid...

Updating group.byname...

Updating group.bygid...

Updating hosts.byname...

Updating hosts.byaddr...

Updating rpc.byname...

Updating rpc.bynumber...

Updating services.byname...

Updating services.byservicename...

Updating netid.byname...

Updating protocols.bynumber...

Updating protocols.byname...

Updating mail.aliases...

gmake[1]: Leaving directory `/var/yp/eng’ nisbeast.kurtwerks.com has been set up as a NIS master server.

Now you can run ypinit -s nisbeast.kurtwerks.com on all slave servers.

After running the ypinit command as shown, a new directory containing the NIS map files exists, /var/yp/nisbeast. Storing NIS maps in domain-specific directories makes it easy for a single system to act as an NIS server for multiple NIS domains.

7. Start the password daemon, yppasswdd:

# service yppaswdd start

Starting YP passwd services: [ OK ]

8. Confirm that yppasswd is running:

# rpcinfo -u nisbeast yppasswd

program 100009 version 1 ready and waiting

9. Edit /etc/sysconfig/network and add the following line, commenting out or deleting any other line that begins with NISDOMAIN:

NISDOMAIN=eng

10. Use the chkconfig utility or the Service Configuration tool, as shown earlier, to configure ypserv and yppasswdd to start at boot time.

19_599496 ch13.qxd 8/30/05 6:24 PM Page 326

326 Chapter 13

If you run slave servers, repeat Steps 7 and 8 for the transfer daemon, ypxfrd

(that is, start ypxfrd and make sure that it is running). Also make sure to set ypxfrd to start at boot time in Step 10. Your shiny new NIS master server is now up and running and ready to answer requests from NIS clients. What’s that? No clients? Read on.

Configuring an NIS Client

After you have successfully configured at least one master NIS server, you are ready to configure one or more NIS clients. The general procedure for setting up an NIS client involves the following steps:

1. Set the NIS domain name.

2. Configure and start the NIS client daemon.

3. Test the client daemon.

4. Configure the client’s startup files to use NIS.

The following subsections describe these steps in detail and discuss the command and configuration file syntax. Note that there is some overlap between configuring a client and a server, so the discussion emphasizes client configuration tasks. The final subsection configures an example NIS client to illustrate the process of setting up a no-frills NIS client system that connects to the server configured at the end of the previous section.

Setting the NIS Domain Name

The initial step in configuring an NIS client is to set the NIS domain name. As explained in the previous section, execute the following command to set it:

# nisdomainname nisdomain

As before, replace nisdomain with the name of your NIS domain.

Configuring and Starting the Client Daemon

The NIS client daemon, ypbind uses a configuration file named /etc

/yp.conf

that specifies which NIS that server’s clients should use and how to locate them, a process known as binding the client to the server. NIS clients can use one of three methods to bind the server, and the type of entry in

/etc/yp.conf

controls the way binding takes place. The simplest entry takes the form:

19_599496 ch13.qxd 8/30/05 6:24 PM Page 327

The Network Information System 327

ypserver nisserverip

This entry tells clients to use the server whose IP address is nisserverip.

An example of this kind of entry might be: ypserver 192.168.0.1

A somewhat more flexible approach enables clients to broadcast a query for the server to contact for a given NIS domain. This method saves tedious editing of client configuration files if (or, perhaps, when) the IP address of the NIS server changes. This entry takes the form shown here, where nisdomain is the name of the NIS domain of which the local host is a member.

domain nisdomain broadcast

An example entry for broadcast clients might resemble the following: domain eng broadcast

Finally, if client systems are members of multiple NIS domains or if they can connect to one of several servers for the same NIS domain, the following form enables you to associate a given server with a given NIS domain: domain nisdomain server nisserverip

This type of entry in /etc/yp.conf associates the NIS domain nisdomain with the NIS server (either master or slave) whose IP address is nisserverip.

One example of this type of entry might be: domain eng server 192.168.0.4

domain eng server 192.168.0.2

domain finance server 192.168.0.2

The first two lines identify two servers as the NIS servers for the eng NIS domain. The second and third lines indicate that the NIS server whose IP address is 192.168.0.2 serves two NIS domains, eng, and finance.

T I P

If the client system can resolve hostnames to IP addresses without NIS

(if, for example, the client runs a caching name server or has an entry in

/etc/hosts

for the NIS server), you can use a hostname instead of an IP

address, but your best bet is to use IP addresses in /etc/yp.conf to minimize

problems that might arise if name lookup services become inoperable for some reason.

19_599496 ch13.qxd 8/30/05 6:24 PM Page 328

328 Chapter 13

To set up the client’s NIS daemons, you can edit /etc/yp.conf directly or use the Authentication Configuration tool, a graphical tool for configuring user authentication. The following procedure shows you how to use the

Authentication Configuration tool to configure a client system to use NIS:

1. Select Red Hat ➪ System Settings ➪ Authentication or type system-

config-authentication

(as root) in a terminal window to open the

Authentication Configuration tool shown in Figure 13-7.

2. Check the Cache User Information check box. Setting this option causes the client to cache information retrieved from the server, making subsequent NIS lookups considerably faster.

3. Click the User Information tab.

4. Click the Enable NIS Support check box.

5. Click the Configure NIS button to open the NIS Settings dialog box (see

Figure 13-8).

6. If the NIS Domain Name text box is not already filled in, type the NIS domain name.

7. Type the NIS server’s IP address or name in the NIS Server text box.

The NIS Settings dialog box should now resemble Figure 13-8. The NIS domain name is eng and the NIS server is nisbeast.example.com.

8. Check the Cache User Information check box to store authentication information at runtime. This will make lookups for NIS-based information faster.

9. Click OK to close the NIS Settings dialog box.

10. Click OK to close the Authentication Configuration tool.

Figure 13-7 The Authentication Configuration tool.

19_599496 ch13.qxd 8/30/05 6:24 PM Page 329

The Network Information System 329

Figure 13-8 The completed NIS Settings dialog box.

The following listing shows the edits made to /etc/yp.conf by the

Authentication Configuration tool.

# /etc/yp.conf - ypbind configuration file

# Valid entries are

#

# domain NISDOMAIN server HOSTNAME

# Use server HOSTNAME for the domain NISDOMAIN.

#

# domain NISDOMAIN broadcast

# Use broadcast on the local net for domain NISDOMAIN

#

# domain NISDOMAIN slp

# Query local SLP server for ypserver supporting NISDOMAIN

#

# ypserver HOSTNAME

# Use server HOSTNAME for the local domain. The

# IP-address of server must be listed in /etc/hosts.

#

# broadcast

# If no server the default domain is specified or

# none of them is reachable, try a broadcast call to

# find a server domain eng server nisbeast.example.com

N OT E

If you use the server’s IP address instead of its name, the IP address will appear in place of the server name.

NIS client programs, like the NIS servers, require RPC to function properly, so make sure the portmapper is running before starting the client daemon, ypbind

. To start the client daemon, execute the following command, which invokes the ypbind initialization script:

# service ypbind start

Binding to the NIS domain: [ OK ]

Listening for an NIS domain server.

19_599496 ch13.qxd 8/30/05 6:24 PM Page 330

330 Chapter 13

After starting the NIS client daemon, use the command rpcinfo -u localhost ypbind to confirm that ypbind was able to register its service with the portmapper. The output should resemble the following:

# rpcinfo –u luther ypbind program 100007 version 1 ready and waiting program 100007 version 2 ready and waiting

N OT E

If you skip the test procedure outlined in this section, you must at least

set the domain name and create the /var/yp directory. Without this directory, ypbind

does not start.

Finally, use one of the NIS client commands discussed in the section titled

“Key NIS Client Files and Commands” to test whether the client and server are communicating properly. For example, use the ypcat command to display the contents of the NIS shared password file:

# ypcat passwd.byname

For user lookups to work properly on the client, do not add users whose authentication information will be retrieved using NIS on the client system.

Instead, add a + sign to the end of /etc/passwd and /etc/group on your

NIS clients. Experienced system administrators might use properly formatted entries for the password and group files (+:*:0:0:: and +:*:*, respectively), but this isn’t necessary for NIS to work properly.

Now edit /etc/host.conf so that it uses NIS for hostname lookups. By default, the Fedora Core and Red Hat Enterprise Linux host.conf file looks like the following: order hosts,bind

This configuration means that name service lookups first look in /etc

/hosts

, then use bind, the name server, to perform name lookups. Change this line so that it reads: order hosts,nis,bind

This entry causes name lookups to query NIS after looking in /etc/hosts and before using the resolver library.

Last, edit /etc/nsswitch.conf. By default, Red Hat Linux is configured to perform standard NIS (as opposed to NIS+) lookups when user authentication and related information is requested. Among other entries, you should see lines that look like the following:

19_599496 ch13.qxd 8/30/05 6:24 PM Page 331

The Network Information System 331

passwd: files nis shadow: files nis group: files nis hosts: files nis

If you don’t see these entries, add them.

Configuring the Client Startup Files

As when configuring an NIS server, you must modify some system configuration files and make sure that the client daemon starts and stops when the system starts and stops. In addition to setting the NIS domain name in /etc/sysconfig/ network and setting the server information in /etc/yp.conf, you must enable ypbind, the NIS client, at boot time. You can use the chkconfig utility or the Service Configuration tool to start ypbind when the system boots.

Using chkconfig, issue the following commands:

# chkconfig --levels 0123456 ypbind off

# chkconfig --levels 345 ypbind on

To use the Service Configuration tool, start system-config-services as demonstrated earlier, scroll down to the bottom of the services list, and place a check mark beside the ypbind service. When you’re done, select File ➪ Save to save your changes, and then select File ➪ Exit to close the Service Configuration tool.

NIS Client Commands

Table 13-2 lists the key NIS client commands and briefly describes their purpose.

The ypcat command enables you to view the contents of an NIS map.

ypcat displays maps from the default server unless you request a specific NIS server using -d nisdomain. Similarly, to view the maps from a specific machine, use -h hostname, replacing hostname with the host in which you are interested.

Table 13-2 NIS Client Configuration Files and Commands

COMMAND DESCRIPTION

ypcat ypmatch

Prints the entries in an NIS database

Prints the value of one or more entries in an NIS map yppasswd yppoll ypwhich

Changes user passwords and information on the NIS server

Displays the server and version number of an NIS map

Displays the name of the master NIS server

19_599496 ch13.qxd 8/30/05 6:24 PM Page 332

332 Chapter 13

ypwhich invoked with no arguments displays the name of the default NIS server. If invoked with the -d nisdomain option, it queries the master NIS server for the NIS domain named nisdomain. You can also specify use ypwhich hostname to query the NIS server, if any, on the machine named hostname

. The -x option causes ypwhich to display the list of available maps.

Suppose, for example, that you want to know the list of hosts that the NIS server nisbeast knows about. First, use ypwhich -x command to see a list of map nicknames available on nisbeast:

$ ypwhich -x

Use “ethers” for map “ethers.byname”

Use “aliases” for map “mail.aliases”

Use “services” for map “services.byname”

Use “protocols” for map “protocols.bynumber”

Use “hosts” for map “hosts.byname”

Use “networks” for map “networks.byaddr”

Use “group” for map “group.byname”

Use “passwd” for map “passwd.byname”

This output means, for example, that the map hosts.byname can be accessed using the nickname or hosts. So, try ypcat hosts:

$ ypcat hosts

192.168.0.1 coondog.example.com coondog

192.168.0.2 hounddog.example.com hounddog

192.168.0.3 moonshine.example.com moonshine

127.0.0.1 localhost.localdomain localhost

127.0.0.1 localhost.localdomain localhost

192.168.0.4 nisbeast.example.com nisbeast

If you are looking for a specific piece of information, use the ypmatch command. For example, to find the user bubba’s password file entry, use the command:

$ ypcat passwd | grep bubba bubba:$1$KXv8uWVw$Uk96z3r0bdHrM9gCfR.Ge0:501:501::/home/bubba:/bin/csh

A more elegant method is to tell ypmatch to do it:

$ ypmatch -k bubba passwd bubba:$1$KXv8uWVw$Uk96z3r0bdHrM9gCfR.Ge0:501:501::/home/bubba:/bin/csh

As you can see, the output is the same, but ypmatch enables you to zero in on precisely the information you want without having to retrieve the entire map and filter the output. ypmatch’s -k option defines the key, or the information you want; the second argument tells ypmatch the map you want to

19_599496 ch13.qxd 8/30/05 6:24 PM Page 333

The Network Information System 333

search (passwd in this case). To see bubba’s group file entry, for example, you would specify the map group:

$ ypmatch -k bubba group bubba bubba:!:501:

The yppasswd command enables users to change their NIS passwords.

What’s wrong with using plain vanilla passwd? The passwd command affects only the client machine. The yppasswd command, on the other hand, updates the NIS maps on the NIS server, which means that the updated password will be effective across the network, not just on the client machine. In fact, if you use the passwd command for a user that is authenticated via NIS, the password change, if it succeeds, will not be propagated to other NIS clients and will be discarded from the local machine’s authentication databases the next time the NIS maps are updated.

Before you test the configuration, you need to have an NIS client configured — it’s hard to test a server without a client — so we’ll delay testing the server configuration until the end of the next section.

Configuring an Example NIS Client

This subsection illustrates configuring an NIS client to use the NIS services provided by the NIS server configured earlier in this chapter. As before, the NIS domain name is eng, running on the server nisbeast.kurtwerks.com, which has an IP address 192.168.0.1.

1. Set the NIS domain name:

# nisdomainname eng

# nisdomainname

eng

2. Edit /etc/yp.conf to identify the default NIS server. The complete configuration file is (without comments): ypserver 192.168.0.1

3. Make sure that the portmapper is running on the client:

# rpcinfo -u localhost portmapper

program 100000 version 2 ready and waiting

4. Start the primary client daemon, ypbind:

# service ypbind start

Binding to the NIS domain: [ OK ]

Listening for an NIS domain server.

19_599496 ch13.qxd 8/30/05 6:24 PM Page 334

334 Chapter 13

WHAT ABOUT NIS+?

The Network Information Service Plus, NIS+, is a replacement for NIS that provides improved security, a more flexible naming model, and better support for large (okay, enormous) NIS installations. The security improvements include data encryption and secure RPC. The original NIS specification (often called

traditional NIS

to distinguish it from NIS+) suffered from the typical RPC vulnerabilities because it transmitted information over the wire as clear text, making it an easy target for packet snoopers and ne’er-do-wells. Data encryption makes snoopers’ jobs more difficult. The naming scheme in NIS+ is dramatically different. The new method is very LDAP-like, organized around a tree of object nodes rather than a set of flat text files. Unfortunately, development of NIS+ for Linux has stopped. As a result, NIS+ for Linux is too immature to be considered for a production environment. If you need the additional security features and more flexible (and complicated) namespace offered by NIS+, you will want to use some combination of Kerberos and LDAP.

See Chapter 34 for information about using Kerberos and LDAP for secure information sharing.

5. Confirm that ypbind is running:

# rpcinfo -u localhost ypbind

program 100007 version 1 ready and waiting program 100007 version 2 ready and waiting

6. Edit /etc/host.conf and add NIS to the services used for hostname lookups. The completed file looks like this: order hosts,nis,bind

7. Use the chkconfig utility or Service Configuration tool, as explained earlier in this chapter, to configure ypbind to start at boot time.

Using NIS and NFS Together

As we promised in Chapter 12, this section shows you how to use NIS and NFS to fully automate mounting NFS exports. What you’ll discover, though, is that we didn’t promise much. That is, the only thing you need to do to use NIS and

NFS together is use NIS to distribute the automounter configuration files. The rest “just works.” The technique uses NFS automounts to handle the mounting part of the process and NIS to distribute the automount files. The example shown in this section enables users to log in at any system (running an NIS client and an NFS client) and always have access to their home directory without having to make any modification on the client system except to enable NFS and NIS.

19_599496 ch13.qxd 8/30/05 6:24 PM Page 335

The Network Information System 335

Here’s the scenario:

■■

The NFS and NIS server is luther.kurtwerks.com, which has the IP address 192.168.0.4.

■■

The NIS domain name is possumholler.

■■

The home directories to export reside in the file system /export/homes.

■■

The client system is marta.kurtwerks.com, which has the IP address

192.168.0.1, and is running NFSv2.

■■

To keep the example clear, the exports will be mounted on the client system at the mount point /net.

And here’s the procedure: The server system has already been configured as an NIS and NFS server. Likewise, the client system has already been configured as an NIS and NFS client. Accordingly, the following steps focus only on modifying these services on the server and client systems.

1. On the NFS server, add the exported file system to /etc/exports:

# cat /etc/exports

/export/homes

192.168.0.0/24(rw,no_subtree_check,secure,async,wdelay)

This entry exports the file system /export/homes to any client with an IP address in the range 192.168.0.1-192.168.0.254. The export is configured as read-write, with subtree checking disabled, allows the server to handle NFS requests asynchronously, and permits the server to delay disk writes.

2. On the NIS server, create an automount file for /net. Keep in mind that this file, auto.net, will be used on client systems, not the server.

# /etc/auto.net

home -rw,soft,rsize=32678,wsize=32678,nfsvers=2 luther:/export/homes

This entry tells the automounter to mount the file system /export

/homes exported from luther under the mount point /net/home in read-write mode. The mount will be a soft mount, the read and write buffers can be a maximum of 32,678 bytes, and the protocol version to use is NFSv2. The latter measure is necessary because the client in the example is not running NFSv4.

3. Edit a copy of /var/yp/Makefile and make the following changes: a. Beneath the line that reads (near line 93):

AUTO_LOCAL = $(YPSRCDIR)/auto.local

add the following entry:

AUTO_NET = $(YPSRCDIR)/auto.net

19_599496 ch13.qxd 8/30/05 6:24 PM Page 336

336 Chapter 13

This entry tells the makefile where to find the auto.net automounter file.

b. At the end of the that reads (near line 109): all: passwd group hosts rpc service netid protocols mail \ insert the text auto.net auto.master before the terminating backslash. The modified rule should look like the following: all: passwd group hosts rpc service netid protocols mail auto.net

auto.master \

This change tells the makefile to include the auto.net and auto.master

files as two of the files to convert to NIS maps.

c. Add the text below to the end of the file: auto.net: $(AUTO_NET) $(YPDIR)/Makefile

@echo “Updating [email protected]

[email protected] -e “/^#/d” -e s/#.*$$// $(AUTO_NET) | $(DBLOAD) \

-i $(AUTO_NET) -o $(YPMAPDIR)/[email protected] - [email protected]

[email protected]$(NOPUSH) || $(YPPUSH) -d $(DOMAIN) [email protected]

Each line after the first must be indented with a tab character! This entry (a rule in makefile parlance) tells make how to create an NIS map from the source auto.net. You don’t need to understand how it works, just that it does.

4. Execute the make command in /var/yp to update the NIS maps:

# cd /var/yp

# make gmake[1]: Entering directory `/var/yp/possumholler’

Updating netid.byname...

Updating auto.net...

Updating auto.master...

gmake[1]: Leaving directory `/var/yp/possumholler’

As you can see from the output, the auto.net file has been created.

You can verify this by executing the following command:

# file /var/yp/possumholler/auto.net

/var/yp/possumholler/auto.net: GNU dbm 1.x or ndbm database, little endian

5. On the server, start the amd service, which starts the server’s automount daemon:

# service amd start

Starting amd: [ OK ]

19_599496 ch13.qxd 8/30/05 6:24 PM Page 337

The Network Information System 337

6. On the client system, make sure that NIS and NFS client servers are running. If not, start them.

7. On the client, start the autofs service, which handles local automounts:

# service autofs start

Starting automount: [ OK ]

8. On the client system, make sure that the NIS client can communicate with the server:

# ypwhich

luther.kurtwerks.com

9. Ensure that the client system can “see” the auto.net map:

# ypcat auto.net

-rw,soft,rsize=32768,wsize=32768,nfsvers=2 luther:/export/homes

10. Log in as user on the client system whose home directory is served by

NFS and whose authentication information is provided by NIS. If everything has gone according to plan, you should be able to log in and wind up in the proper home directory.

Summary

In this chapter, you saw how to configure Fedora Core and Red Hat Enterprise

Linux systems as NIS servers and clients. You first learned how to set up and test an NIS server and how to ensure that the NIS server comes up after a system reboot. You also learned how to configure an NIS client to connect to an

NIS server for user-authentication information. Finally, you learned how to use NIS and NFS together, enabling NIS-authenticated users to mount their

NFS-exported home directories on any NIS client system without requiring special setup at the NFS client.

19_599496 ch13.qxd 8/30/05 6:24 PM Page 338

20_599496 ch14.qxd 8/30/05 6:36 PM Page 339

C H A P T E R

14

Connecting to Microsoft and Novell Networks

IN THIS CHAPTER

■■

■■

■■

■■

■■

■■

■■

Installing Samba

Configuring the Samba Server

Creating Samba Users

Starting the Samba Server

Connecting to a Samba Client

Connecting from a Windows PC to a Samba Server

Connecting to Novell Networks

Using a program called Samba, you can emulate the Windows file-sharing protocol and connect your Fedora Core and Red Hat Enterprise network to a

Windows network to share files and printers. Novell networks before version

5.0 use a native protocol known as IPX, and with Fedora Core and Red Hat

Enterprise Linux you can emulate this protocol to enable file sharing and printing between Red Hat systems and Novell Netware systems. Novell versions 5.0 and later use native TCP/IP, and you can connect using that protocol.

There are still many Novell installations running versions before version 5. In this chapter, you learn how to connect a Red Hat network to a Microsoft network and a Novell network running versions prior to version 5.0.

N OT E

Both SMB and NCP support require kernel support, and this is active by default in both Fedora Core and Enterprise Linux kernels. If you build your own kernel, be sure to enable SMB and NCP support in the kernel.

339

20_599496 ch14.qxd 8/30/05 6:36 PM Page 340

340 Chapter 14

Installing Samba

Computers running Windows 95 or greater use a protocol called Server Message Block (SMB) to communicate with each other and to share services such as file and print sharing. With Samba, the Linux PC icon appears in the Windows Network Places window, and the files on the Linux PC can be browsed using Windows Explorer. The Windows file system can be mounted on your

Linux system, and you can browse the Windows files from your Linux PC.

Before you can use Samba to connect to the Windows computers, it must first be installed on the Linux PC. All current distributions of Fedora Core and

Red Hat Enterprise Linux include three Samba packages: Samba, Sambaclient, and Samba-common. They may not have been installed during the system installation. Even if they have been installed, you should always check for the latest versions to find out if any problems have been fixed by the latest release and to install it if necessary. To see whether Samba is installed on your system, type the following at a terminal window:

rpm -q samba

If Samba is not installed, the command returns the output stating that

Samba is not installed. If Samba is installed, the RPM query returns the version number of the Samba program installed on your system.

The latest version of Samba can be obtained at Samba’s Web site: samba.org

. Follow the instructions at the site for downloading the RPM file for your distribution. After downloading the Samba RPM file, install it as follows (“name of file” is the version number downloaded): rpm -i samba(name of file)

Be sure to install the Samba-common RPM, and if you want to use the Sambaclient, also install the Samba-client RPM. If you are unable to download the RPM version, or if you want to compile the program yourself, download the file samba-latest.tar.gz

. Extract the file using the following command: tar -xfvz samba-latest.tar.gz

Change to the directory containing the extracted files (usually /usr/src) and type ./configure.

Press Enter and wait for the command prompt to return. From the command prompt, type make.

Press Enter and wait for the command prompt to return. Finally, type make

install

from the command prompt. If all goes well, Samba is installed when the command prompt returns. Now you need to configure it.

20_599496 ch14.qxd 8/30/05 6:36 PM Page 341

Connecting to Microsoft and Novell Networks 341

For Samba to provide its services, the Red Hat Linux PC needs to be configured.

N OT E

In this chapter, I refer to the Red Hat Linux PC as the Samba server and the Windows PC as the Samba client.

Configuring the Samba Server

Before you can use Samba to connect with your Windows PCs, it must be configured. While there are several graphical-based programs available for configuring Samba, these programs are just front ends that make changes to the Samba configuration file behind the scenes. It is much quicker and easier to edit the Samba configuration file itself. The Samba configuration file is called smb.conf and is located in the /etc/samba directory by the installation program. A sample smb.conf file was created during the installation that can be used for reference and modification.

The smb.conf file is divided into several sections, called shares, the names of which I show as bracketed subsection titles in the following discussion.

Shown next is the smb.conf file from one of the computers I use at school.

Refer to this file to see what a section looks like as it is described.

# This is the main Samba configuration file. You should read the

# smb.conf(5) manual page in order to understand the options listed

# here. Samba has a huge number of configurable options (perhaps too

# many!) most of which are not shown in this example

# Any line which starts with a ; (semi-colon) or a # (hash)

# is a comment and is ignored. In this example we will use a #

# for commentry and a ; for parts of the config file that you

# may wish to enable

# NOTE: Whenever you modify this file you should run the command

“testparm”

# to check that you have not made any basic syntactic errors.

#======================= Global Settings

=====================================

[global] log file = /var/log/samba/%m.log

smb passwd file = /etc/samba/smbpasswd load printers = yes passwd chat = *New*password* %n\n *Retype*new*password* %n\n

*passwd:*all*authentication*tokens*updated*successfully* socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 obey pam restrictions = yes encrypt passwords = yes passwd program = /usr/bin/passwd %u

20_599496 ch14.qxd 8/30/05 6:36 PM Page 342

342 Chapter 14

dns proxy = no netbios name = rhl writeable = yes server string = Samba Server printing = lprng path = /home default = homes unix password sync = Yes workgroup = Tardis printcap name = /etc/printcap security = user max log size = 50 pam password change = yes

[homes] comment = Home Directories browseable = yes writeable = yes create mode = 0664 directory mode = 0775 max connections = 1

[printers] browseable = yes printable = yes path = /var/spool/samba comment = All Printers

[global]

The first section of the smb.conf file is the [global] section. The [global] section contains settings that apply to the entire server and default settings that may apply to the other shares. The [global] section contains a list of options and values in the following format: option = value

You have hundreds of options and values at your disposal, and you look at the most common ones here. For a complete listing of options, refer to the smb.conf

man page. Some of the more significant options are:

■■

■■

workgroup = Tardis

— This is the name of the workgroup shown in the identification tab of the network properties box on the Windows computer.

smb passwd file = /etc/samba/smbpasswd

— This shows the path to the location of the Samba password file. Be sure that you include this option/value pair in your smb.conf file.

20_599496 ch14.qxd 8/30/05 6:36 PM Page 343

Connecting to Microsoft and Novell Networks 343

■■

encryptpasswords = yes

— Beginning with Windows NT service pack 3 and later, passwords are encrypted. If you are connecting to any systems running these versions of Windows, you should choose encrypted passwords.

■■

netbios name = RHL

— This is the name by which the Samba server is known to the Windows computer.

■■

server string = Samba Server

— This is shown as a comment on the Windows PC in the network browser.

■■

security = user

— This is the level of security applied to server access. Other options are share, domain, and server. Share is used to make it easier to create anonymous shares that do not require authentication, and it is useful when the NetBIOS names of the Windows computers are different from other names on the Linux computer. Server is used to specify the server to use if the password file is on another server in the network. Domain is used if the clients are added to a Windows NT domain using smbpasswd, and login requests are executed by a Windows NT primary or backup domain controller.

■■

log file = /var/log/samba/log

— This is the location of the log file.

■■

max log size = 50

— This is the maximum size in kilobytes that the file can grow to.

■■

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SND-

BUF=8192

— This enables the server to be tuned for better performance. TCP_NODELAY is a default value; the BUF values set send and receive buffers.

■■

dns proxy = No

— This indicates that the NetBIOS name will not be treated like a DNS name and that there is no DNS lookup.

[homes]

The next section of the smb.conf file, [homes], is used to enable the server to give users quick access to their home directories. Refer to the smb.conf

man page for a more complete description of how the [homes] section works.

■■

comment = Home Directories

— A comment line.

■■

browseable = yes

— Means that the directory will appear in the

Windows file browser.

■■

writeable = yes

— Means that users can write to their directories.

■■

create mode = 0664

— Sets the default file permissions for files created in the directory.

20_599496 ch14.qxd 8/30/05 6:36 PM Page 344

344 Chapter 14

■■

■■

directory mode = 0775

— Sets the default permissions for created directories.

max connections = 1

— The maximum number of simultaneous connections allowed. Setting this number to 1 prevents a user from logging in to the server from more than one location. Setting this number to 2 allows a user to log in from two locations and so on. Setting this number to 0 allows an unlimited number of connections.

[printers]

This section sets the options for printing.

■■

■■

■■

path = /var/spool/samba

— The location of the printer spool directory.

printable = yes

— Enables clients to send print jobs to the specified directory. This option must be set, or printing does not work.

browseable = yes

— Means that the printer appears in the browse list.

N OT E

Be sure to have your printer properly configured for your Linux network before you attempt to set it up for use with Windows clients. You may need to enter the location of the path to the print spool for the printer you want to use

in the smb.conf file.

The smb.conf file shown in the examples allows users who already have system accounts to access their home directories and to use printers. After modifying and saving the /etc/samba/smb.conf file, check the syntax of the file. To do this, you can use the testparm command as follows:

[[email protected] terry]# testparm

Load smb config files from /etc/samba/smb.conf

Processing section “[printers]”

Processing section “[homes]”

Loaded services file OK.

Press enter to see a dump of your service definitions

Pressing Enter displays the contents of the configuration file. The smb.conf

file is now ready to use.

Creating Samba Users

If you are using security-server and have assigned a domain instead of a workgroup, you don’t need to create Samba users since your users will be logging

20_599496 ch14.qxd 8/30/05 6:36 PM Page 345

Connecting to Microsoft and Novell Networks 345

into a Windows domain controller. In this example though, we will create a

Samba users’ password file. You can convert all of your system users to Samba users by running the following command: cat /etc/passwd | mksmbpasswd.sh > /etc/samba/smbpasswd

This utility creates only the users’ accounts, not their passwords. You need to create passwords for your users by using the smbpasswd command and the user’s name as shown here:

[[email protected] terry]# smbpasswd terry

New SMB password:

Retype new SMB password:

Password changed for user terry

Password changed for user terry

Starting the Samba Server

The last step is to start the Samba daemon. The command to start Samba is:

[[email protected] terry]# /sbin/service smb start

Starting SMB services: [ OK ]

Starting NMB services: [ OK ]

At this point, you should have a functioning Samba server running on your system. It is configured to allow users who have accounts on your Red Hat

Enterprise Linux system to access their home directories from a Windows PC.

Logged-in users are also able to use the printers configured with the Red Hat system.

Connecting to a Samba Client

In this section, you learn how to connect your system to other systems running the SMB protocol. Connecting a PC running Windows 2000 or XP is covered in the section “Connecting from a Windows PC to the Samba Server,” later in this chapter. You can connect your system to any computer that is running the SMB protocol, whether it is a Windows PC or another Linux system running Samba.

The connection can be made from the command line using two methods. The first uses a utility called smbclient, and the command syntax is smbclient

//computer name/sharename

, as shown in the following example. Be sure to replace the computer name in the example with the name of your computer.

20_599496 ch14.qxd 8/30/05 6:36 PM Page 346

346 Chapter 14

[[email protected] terry]# smbclient //terrycollings/c added interface ip=192.168.9.93 bcast=192.168.9.255 nmask=255.255.255.0

Got a positive name query response from 192.168.9.102 (192.168.9.102)

Password:

Domain=[Tardis] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager] smb: \>

The preceding example shows me logging in to my Windows PC from my

Red Hat system. I was prompted for a password to log in and was given some information about the Windows system and a command prompt. You can type help at the command prompt to get a list of possible commands. The commands at the smb prompt are very similar to command-line FTP commands.

To exit the connection, type exit.

Another way to make the files on the Samba client accessible on your Red

Hat system is to mount the client file system on your file system. You can do this using the smbmount command. The syntax for this command is smbmount

//computer name/directory /mysystem/mount/point

, as shown in the following example:

[[email protected] terry]# smbmount //terrycollings/c /mnt/windows

Password:

Next, you can change to the directory on the system where you mounted the

Windows system by issuing the following command:

[[email protected] terry]# cd /mnt/windows

Then you can get a directory listing by using the ls command:

[[email protected] windows]# ls arcldr.exe MSDOS.SYS quicktime arcsetup.exe Muhlnet Setup QuickTimeInstaller.zip

AUTOEXEC.BAT My Download Files Recycled boot.ini My Music rhsa camtasia NALCache W2K.CD

CONFIG.SYS netplus Windows Update Setup Files

Documents and Settings Novell WINNT

Drivers NTDETECT.COM WSREMOTE.ID

fgc ntldr WT61CE.UWL

hiberfil.sys p2.pdf WT61OZ.UWL

IO.SYS pagefile.sys WT61UK.UWL

lconfig.aot Program Files WT61US.UWL

Local Muhlnet PUTTY.RND

In this example, I am connecting to the same Windows PC to which I connected in the previous example. However, by using the smbmount command,

I am mounting the Windows file system on my Red Hat file system. After

20_599496 ch14.qxd 8/30/05 6:36 PM Page 347

Connecting to Microsoft and Novell Networks 347

entering the password for the Windows PC and returning to the command prompt, I change to the directory that I just mounted and run the ls command to obtain a directory listing of the Windows PC share I mounted. I can now easily move files between the two systems using regular file system utilities.

You can put the mount command into a local startup script so that the directories are mounted at system boot, if you desire. Use the command as shown earlier and add an option to look for a file that contains the login username and password. smbmount //terrycollings/c /mnt/windows -o credentials=/home/terry/.sambacred

You need to create a file as shown in the following code. I created a hidden file called .sambacred and in the file I placed these two lines:

Username = terry password = (password)

Be sure to put the information relevant to your system for the path to the file and the username and password. The reason for creating the hidden file and pointing to it from the smbmount command is to prevent someone from being able to find out the password that is in the file in plain text. Be sure to change the permissions on this file accordingly.

Using this method is preferable to placing the mount information in the

/etc/fstab file. While it is possible to place the mount information in the /etc/fstab file, someone could find out the username and password just by looking at the /etc/fstab file.

To unmount the client file system, enter the following smbumount command and the path to the directory to unmount:

# smbumount /mnt/windows

After you press Enter, the file system will be unmounted.

Connecting from a Windows PC to the Samba Server

Now you are ready to test your connection on the Windows PC. For systems running Windows 2000 or XP, no configuration is required. On the Windows computer, double-click the My Network Places icon from the desktop. In the

Network Places window, you should now see a listing for the Red Hat computer, which in this example would be rhl10. Double-click the rhl10 PC icon, and you will see the shares you made available.

20_599496 ch14.qxd 8/30/05 6:36 PM Page 348

348 Chapter 14

WHY USE SAMBA INSTEAD OF NFS?

Earlier, you set up the Network File System to enable file sharing across your network. Why didn’t you just use NFS to share the Windows files? Well, you could have, but it makes more sense to use Samba to communicate with

Windows computers. Windows systems don’t natively support NFS; the Server

Message Block (SMB) protocol is how Windows computers communicate with each other. It is the Windows native protocol for sharing files and printers. By using the same protocol, you are ensuring that file and printer sharing operate with a minimum of difficulty.

When you double-click the directory share from the rhl10 PC, you are prompted for a username and password to enter the directories. That’s all there is to it. Now you can share files between your Linux and Windows computers.

T I P

You can use the Windows Map Network Drive command to set up a

Windows system to always connect to your Samba share when you start the

Windows PC.

C R O S S - R E F E R E N C E

To learn how to set up a printer to use under Samba, refer to Chapter 10.

Connecting to Novell Networks

With Red Hat Enterprise Linux, you can easily configure your system to connect to Novell Netware servers. In this section, you learn how to configure your Red Hat system to be a Novell client.

Two packages need to be installed to enable communication between the

Novell servers and your Fedora or Red Hat Enterprise system. The first package to load is ipxutils, which is Internetwork Packet Exchange protocol — the Novell protocol for networking. The second package you need to load is ncpfs — the Novell file system package. If you do not have these packages installed on your system, the RPMs can be found on the Red Hat Installation

CDs. Install the packages before continuing.

After the packages have been installed, two modules need to be loaded before you can configure the Novell client. From a terminal command prompt, enter the following command to load the modules.

#/sbin/modprobe ipx ncpfs

20_599496 ch14.qxd 8/30/05 6:36 PM Page 349

Connecting to Microsoft and Novell Networks 349

N OT E

The ipx and ncpfs kernel modules are now in the kernel-unsupported package, which may not be installed. You may have to install this package to

obtain the necessary modules. Or, you can do a Google search for ipx rpm and ncpfs rpm

for your distribution.

After the modules are loaded, you need to configure your IPX connection by entering the following command, which attempts to automatically detect and configure your IPX connection.

#/sbin/ipx_configure -auto_interface=on -auto_primary=on

The previous command enables the automatic configuration of the interface and detects the primary connection. You can check if your configuration is successful by issuing the slist command from the terminal prompt. The output from the slist command is shown in Figure 14-1.

If you receive a listing similar to that shown in Figure 14-1, your IPX configuration is correct, and you can attempt to log in to a server and mount its file system on your system. To do this you will use the ncpmount command as follows: ncpmount -S (fileserver name) (fileserver directory (optional)) -U (fileserver login id (complete context)) -P (password) (directory mount point).

Be sure to replace the information in the parentheses with the information appropriate to your system.

Figure 14-1 The output from the slist command shows the Novell servers on the network.

20_599496 ch14.qxd 8/30/05 6:36 PM Page 350

350 Chapter 14

Suppose that you want to log in to the server BART, shown in Figure 14-1, and mount its file system on my system in the bart directory. You need to enter the following command:

# ncpmount -S BART -U terry.mediaservices.admin -P password

/home/terry/novell/bart

After logging in and mounting the Novell file system on your system, a directory listing shows the contents of the server Bart. Be sure to replace the information in the example with the information appropriate for your systems.

You can unmount an NCP file system by issuing the ncpumount command and specifying the mount point to unmount. During system shutdown, the

NCP mounts are cleanly unmounted, so it is not necessary to unmount the file system before shutting down the system.

If you do not want to go through the manual configuration process to connect your system as a Novell client each time you start your system, you should place the commands in this section in your rc.local file. The configuration then occurs automatically at boot time. You can even have the file system mounted at the same time, if you desire.

C R O S S - R E F E R E N C E

See Chapter 10 for more information on how to configure a Novell networked printer.

Summary

In this chapter, you learned about the Server Message Block (SMB) protocol.

This protocol is used by Windows computers to communicate with each other.

You learned about a Linux program called Samba, which emulates the SMB protocol and can be used to connect Linux networks to Windows networks.

You installed and configured Samba on a Red Hat Enterprise Linux server and configured the Windows clients. You also learned how to configure your Red

Hat system as a Novell client using the NCP file system.

21_599496 ch15.qxd 8/30/05 6:39 PM Page 351

C H A P T E R

15

Configuring a

Database Server

IN THIS CHAPTER

■■

■■

■■

Linux Database Servers

Using MySQL

Using PostgreSQL

As Linux continues to penetrate deeper into the enterprise, it is increasingly being used to house corporate data. This chapter describes installing, configuring, and testing three of the major relational database management systems

(RDBMSs) on Fedora Core and Red Hat Enterprise Linux: MySQL, and PostgreSQL, the two most popular open source RDBMSs, and Oracle, the

800-pound gorilla of commercial RDBMSs. This chapter’s scope is limited to helping you install these database systems and to verify the basic functionality of the installed system. In the interests of setting your expectations appropriately, you will not be a database expert after reading this chapter because we don’t cover SQL, database design, query optimization, or any other technical database-specific topics. Those subjects are worth a book (each).

Linux Database Servers

Much as Linux has come to dominate the world of Web servers and cluster computing, Linux is gradually becoming the preferred OS to host corporate data and it is doing so for the same reasons that it dominates Web services and high-performance computing: Linux is fast, stable, reliable, tunable, and flexible; the source is available; and it runs on commodity hardware. Most of the major databases, including Oracle, DB/2, Informix, MySQL, and PostgreSQL,

351

21_599496 ch15.qxd 8/30/05 6:39 PM Page 352

352 Chapter 15

run on it. As a result, system administrators have to contend with running database servers.

As a system administrator, you rarely have the final say or deciding vote in which database you will run on your server and be responsible for maintaining.

Indeed, someone farther up the food chain than you usually dictates the decision. Nonetheless, it is your responsibility to make sure that the server is running, is accessible, and performs acceptably. In most shops, Linux system administrators are not responsible for the daily care and feeding of the database because database administrators (DBAs) handle that task. At smaller sites that don’t have the luxury of a dedicated DBA, you might have more responsibilities for database maintenance, but, as a rule, you won’t be writing queries, building applications, or providing technical support for the database.

Nonetheless, having passing familiarity with the services that your system or systems provide is essential. Knowing at least how to install a database server and how to make sure it is running is important because DBAs sometimes lack the ability to administer the system on which the database runs; their job is to groom the database, not the hardware and operating system on which it runs.

Regardless of the database system used, the basic procedure for bootstrapping a database server is the same:

1. Install and configure the hardware.

2. Install and configure the operating system.

3. Install and configure the database software to create a standard installation.

4. Make sure that the basic installation works.

5. Set up monitoring and backup jobs for the database.

6. Turn it over to the DBA(s).

The purpose of this chapter is to address Steps 3 and 4. The particulars involved in installing and configuring the database software varies, of course.

Likewise, making sure the stock installation works requires different measures depending on the database you are using. This chapter isn’t long enough to cover all of the popular database packages available, so it concentrates on the two most popular ones, MySQL and PostgreSQL. MySQL is the most popular of the three in the free software world and it certainly outstrips PostgreSQL in terms of the installed base. We chose PostgreSQL because it is part of Fedora

Core and RHEL and because it is the database technology underneath the Red

Hat Database. Together, familiarity with these two database packages should cover the majority of situations in which you have to install, configure, and maintain a database server.

21_599496 ch15.qxd 8/30/05 6:39 PM Page 353

Configuring a Database Server 353

Using MySQL

MySQL is the most popular open-source RDBMS in the world. It is popular enough, at least, that it is the third part of an acronym widely used to describe

Web services built with free tools, LAMP, which stands for Linux, Apache,

MySQL, and PHP (or Perl or Python, depending on who you ask). MySQL’s popularity is result of its speed, ease of use, flexibility, and, to be sure, its cost.

Most Linux distributions include MySQL as part of server-class installations.

Another important element of MySQL’s popularity is that it integrates smoothly and seamlessly with the other pillars of the LAMPpost, Linux, Apache, and PHP.

For example, Apache’s mod_auth_mysql module integrates MySQL authentication directly into Apache, making it possible to control access to Apache-based services using a MySQL database. Third-party Apache modules (modules not part of the standard Apache distribution) that provide MySQL support or features include the following (numbers in parentheses indicated the Apache version the module supports):

■■

mod_accessCookie

— Implements Apache’s Allow From directive using a cookie validated against a MySQL database (1.3.x)

■■

mod_auth_cookie_mysql

— Provides authentication against a

MySQL database using cryptographically secure cookie (1.3.x)

■■

mod_auth_form

— Peforms authentication using forms and a MySQL database (2.x)

■■

mod_auth_sim

— Incorporates authentication and session ID management into Apache using a MySQL database (2.x)

■■

mod_authn_dbi

— Uses a database-independent API (libdbi) to provide authentication services against a MySQL database (2.x)

■■

mod_crescent

— Serves as the foundation for creating a “virtual community” using MySQL for authentication (1.3.x)

■■

mod_dbd_mysql

— Provides a DBD driver module for MySQL based on mod_dbd (2.x)

■■

mod_log_mysql

— Logs Apache requests to a MySQL database instead of or in addition to the standard flat file, /var/log/httpd

/access_log

(1.3.x, 2.x)

■■

mod_mya

— YAMAM (Yet Another MySQL Authentication Module) that stores authentication information in a MySQL database (1.3.x, 2.x)

■■

mod_sqlinclude

— Uses a MySQL database to store the Apache configuration file, functionality intended to simplify managing large numbers of virtual (Web) hosts (1.3.x)

21_599496 ch15.qxd 8/30/05 6:39 PM Page 354

354 Chapter 15

■■

■■

mod_vhost_mysql2

— Maintains virtual host configurations in a

MySQL database (2.x)

mod_vhs

— Stores virtual host configuration data in a MySQL database (2.x)

N OT E

Chapters 23 and 24 discuss Apache and using Apache modules in detail.

PHP, an extremely popular Web scripting language, has at least two different

APIs for using MySQL in PHP-based applications. Python, a popular and easyto-use object-oriented programming language, has a module that incorporates

MySQL into Python-based programs in a standard, uniform fashion. Other programming languages also incorporate MySQL via modules, loadable libraries, or APIs. Even the zsh shell includes a set of predefined shell functions for using

MySQL command line client programs (mysql, mysqlshow, mysqldump, mysqldiff

, and mysqladmin).

If you’re convinced that MySQL is the database you want to use, it will help to make sure it is installed. Use the rpmquery command to see if the packages mysql-server

, mysql, and mysql-devel are installed. You can use the following commands to see if these packages are installed:

# rpmquery mysql-server mysql-server-3.23.58-14

# rpmquery mysql mysql-3.23.58-14

# rpmquery mysql-devel mysql-devel-3.23.58-14

The versions installed on your system might be different by the time you read this. If these packages aren’t installed (you’ll need at least mysql-server and mysql), install them. mysql-server contains the MySQL server, sample configuration files, the system initialization scripts, a logrotate script for the server’s log files, and a two directories the server uses at runtime. The mysql package contains the client programs, a shared library the client utilities need to interact with the server, and manual pages and language files for the client programs. The mysql-devel package installs the header files and libraries necessary to write MySQL programs in C, C++, and Objective-C.

N OT E

Chapter 30 explains how to install RPM-based software packages.

Other MySQL-related packages that might be installed or that you might want to install include:

■■

mod_auth_mysql

— Provides an Apache module that uses MySQL to control access to Web pages

21_599496 ch15.qxd 8/30/05 6:40 PM Page 355

Configuring a Database Server 355

■■

libdbi-dbd-mysql

— Installs a device-independent database driver for use by programs using ldbdbi

■■

php-mysql

— Contains a PHP module that enables PHP to connect to and manipulate MySQL databases

■■

mysql-bench

— Includes a suite of benchmark tests and test data to use for benchmarking MySQL’s performance on your system

Securing the MySQL Installation

Part of the MySQL installation process installs a script to create a database

(named mysql) of administrative tables that handle access control and database privileges, a test database (imaginatively named test), an administrative user for the database (named root), and an anonymous user (named anonymous

). This script is executed the first time you start the mysqld database daemon. Neither the root account nor the anonymous account is password-protected, so the first thing you want to do is create a password for the root account. In our opinion, naming the administrative user root was a poor choice because it is quite confusing in that the superuser on your system is also named root. This user has superuser privileges on the database, so root is a natural but unfortunate choice. Just so there’s no confusion, MySQL’s root

user is not the same as the system’s root user.

Before attempting to change any passwords, verify that the database is running. One way to do so is to become the (system) root user and use the service utility:

# service mysqld status mysqld (pid 24900) is running...

If mysqld, the MySQL server daemon, isn’t running, you can start it using the usual command:

# service mysql start

Starting MySQL: [ OK ]

Another way to do test the server, one that doesn’t require root access, is to use the mysqladmin and/or mysqlshow commands to see whether the server is running and responding to connections. For example, the following mysqladmin command shows the server version:

$ mysqladmin version mysqladmin Ver 8.23 Distrib 3.23.58, for redhat-linux-gnu on i386

Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB

This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to modify and redistribute it under the GPL license

21_599496 ch15.qxd 8/30/05 6:40 PM Page 356

356 Chapter 15

Server version 3.23.58

Protocol version 10

Connection Localhost via UNIX socket

UNIX socket /var/lib/mysql/mysql.sock

Uptime: 2 min 55 sec

Threads: 1 Questions: 2 Slow queries: 0 Opens: 6 Flush tables: 1 Open tabl es: 0 Queries per second avg: 0.011

The output might differ slightly, depending on the version of MySQL installed. The mysqlshow command can be used to get information about the server, such as what databases it is serving and the tables that exist in those databases. For example, a bare mysqlshow command displays the available databases:

$ mysqlshow

+-----------+

| Databases |

+-----------+

| mysql |

| test |

+-----------+

You’ll learn more about the MySQL client programs in the next section.

After you’ve established that MySQL is running, set the passwords for the

MySQL root account using the mysqladmin commands shown in the following listing (you must be root to execute these commands):

# mysqladmin -u root password “sekritword

# mysqladmin -u root -h hostname sekritword

The first command sets the password for MySQL’s root user when it is connecting from localhost, to sekritword. The second command changes the password for the MySQL when root is connecting from the hostname specified by hostname. What’s the difference? MySQL distinguishes connections by the username and by the host from which users are connecting. By default, MySQL assumes that a user is connecting from localhost (that is, the IP address

127.0.0.1), so [email protected] needs a password. However, in most cases, the localhost also has a fully qualified domain name (that is, a hostname), such as datagrunt.example.com, and MySQL considers such a connection distinct. Accordingly, [email protected] (say, [email protected]

.example.com

) also needs a password.

Use the following command to see the results of your commands:

$ mysql -e “select host, user, password from mysql.user” -u root -p

Enter password:

21_599496 ch15.qxd 8/30/05 6:40 PM Page 357

Configuring a Database Server 357

+-----------------------+------+------------------+

| host | user | password |

+-----------------------+------+------------------+

| localhost | root | 5d2e19393cc5ef67 |

| datagrunt.example.com | root | 5d2e19393cc5ef67 |

| localhost | | |

| datagrunt.example.com | | |

+-----------------------+------+------------------+

You can see that the password for the root use has been set. You can also see that the password you entered has been encrypted. The -u root argument to the mysql command specifies the username; -p tells mysql to show a password prompt. You should enter the password you used when you set the password as shown earlier.

Notice that a similar set of accounts exists for a user with no name; this is the anonymous user mentioned previously. You need to decide at this point if you want to permit anonymous access to the server. If you do, you can leave the accounts without a password or you can set a password. Alternatively, you can delete the anonymous accounts entirely. Whether you leave the accounts intact is a matter of local security policy. We leave them in place and don’t set passwords on them for testing applications during development and delete them on production systems. The anonymous user has limited privileges (essentially, read-only), but it isn’t a good idea to have unsecured accounts on a production system.

If you choose to set a password for the anonymous accounts, use the commands shown in the following example:

# mysql -u root -p

Enter password: mysql> set password for ‘’@localhost = password(‘magicword’);

Query OK, 0 rows affected (0.00 sec) mysql> set password for ‘’@hostname = password(‘magicword’);

Query OK, 0 rows affected (0.00 sec) mysql> flush privileges;

Query OK, 0 rows affected (0.00 sec) mysql> quit

Bye

The semicolons (;) terminating each command are required. The first command starts the MySQL shell, a command interpreter for the MySQL database server, using MySQL’s root account. The rest of the commands are executed from the MySQL shell, which uses the mysql> prompt. In your commands, replace magicword with the password you’ve chosen and hostname with

21_599496 ch15.qxd 8/30/05 6:40 PM Page 358

358 Chapter 15

the fully qualified domain name of your system. The flush privileges instruction causes MySQL to reread the access tables and makes the new password for the anonymous account take effect. Notice that the anonymous username is specified using a pair of single quotes. This is necessary because the anonymous account doesn’t, strictly speaking, have a username. The last command, quit, terminates the MySQL shell session and returns you to the command prompt.

T I P

If you make a real mess of the instructions in this section or just want to start over, you can restore your MySQL installation to its original state by using the following procedure:

1. Stop MySQL:

# service mysqld stop

2. Delete the MySQL data directories and files in /var/lib/mysql:

# cd /var/lib/mysql

# rm -rf mysql test

3. Restart MySQL:

# service mysqld start

This procedure works because the mysqld initialization script creates the initial

databases if the directory /var/lib/mysql/mysql doesn’t exist.

If you prefer to delete the anonymous accounts entirely, use the following commands:

$ mysql -u root -p

Enter password: mysql> delete from mysql.user where user = ‘’;

Query OK, 2 rows affected (0.02 sec) mysql> flush privileges;

Query OK, 0 rows affected (0.00 sec); mysql> quit

Bye

With the root account properly secured and having made a decision about how to handle the anonymous accounts, you are ready to learn a bit more about the MySQL client programs.

21_599496 ch15.qxd 8/30/05 6:40 PM Page 359

Configuring a Database Server 359

Using the MySQL Client Programs

What precisely is a MySQL client program? MySQL is a standard client-server program. The MySQL server daemon, mysqld, is the actual database server. It listens for incoming connections and retrieves, manipulates, and returns data.

It has no interface other than that provided by a client API. Programs that are written to MySQL’s client API provide the user interface to the MySQL server.

It is the client programs that enable you to submit queries to the database, to add and delete users, and so on. The client programs also make it easier to perform certain tasks. For example, in theory, a SQL database can be manipulated entirely using SQL statements. However, to simplify certain activities, it is often more convenient to use programs that hide SQL functionality behind a simpler interface. MySQL’s client programs provide this simpler interface.

You’ve already seen three of the MySQL client programs in action, mysqladmin

, mysqlshow, and mysql. mysqladmin is a utility that enables you to perform administrative activities, such as:

■■

Creating, modifying, and deleting (dropping, in SQL parlance) databases

■■

Starting and stopping the MySQL server

■■

Confirming the database is up

■■

Finding out which server threads are running

■■

Killing specific MySQL server threads

■■

Retrieving status information from a running server

■■

Flushing (syncing) data to disk

■■

Changing passwords mysqladmin

’s basic syntax is: mysqladmin -u username -p[password] command

Replace username with the database username, such as root, that you want to use. The account specified in username must have the privileges required to perform the requested operation. If you specify just -p, MySQL will prompt you for username’s password. You can add the password after -p, but doing so isn’t a good idea because it will appear on screen. command specifies the operation you want to perform. For example, to create a database named techbooks

, the command would be: mysqladmin -u username -p create techbooks

To delete (drop) this database, use the following command: mysqladmin -u username -p drop techbooks

21_599496 ch15.qxd 8/30/05 6:40 PM Page 360

360 Chapter 15

To change the password for the root user, you would use the following command: mysqladmin -u username -p password ‘new_password

Replace new_password with the password you want to assign to username and make sure to enclose the new password in single quotes (‘). In this case the command passed to mysqladmin is password ‘new_password’; the -p option is not being given an argument of password.

To stop a running server, use the shutdown command, as shown in the following example: mysqladmin -u username -p shutdown

For more details about using the mysqladmin command, see the mysqladmin main page or refer to the MySQL documentation.

mysqlshow is a utility that displays the structure of a MySQL database, the tables in that database, and the columns (or fields) that make up that database.

It uses an option syntax similar mysqladmin, but takes different (and fewer) arguments: mysqlshow -u username -p [database [table [column]]]

As before, replace username with the user account you want to use. If database is not specified, mysqlshow displays all of the available databases.

If database is specified, mysqlshow lists the tables that exist in database. If table is also specified (it must exist in the indicated database), mysqlshow displays that table’s columns (fields). If column is also specified (the column must exist in the specified table, which must likewise exist in the requested database), mysqlshow displays that column’s characteristics. For example, the following command display the tables in the mysql database:

$ mysqlshow -u root -p mysql

Database: mysql

+--------------+

| Tables |

+--------------+

| columns_priv |

| db |

| func |

| host |

| tables_priv |

| user |

+--------------+

21_599496 ch15.qxd 8/30/05 6:40 PM Page 361

Configuring a Database Server 361

mysql

, as already explained, is a MySQL shell or command interpreter. The commands it interprets are SQL statements. mysql gives you the most direct access to the MySQL’s database engine, but also requires that you speak fluent

SQL. You enter SQL statements at a command prompt, the interpreter passes them to the database engine, and the database engine sends the results of those

SQL statements back the interpreter, which displays the results on the screen.

There are many other MySQL clients. Table 15-1 lists the ones you are most likely to use; there are others, but they are special-purpose programs that (we hope) you never need to use.

We don’t have the space to go into all of MySQL’s capabilities, much less provide proper guidance on using all its commands and utilities. The initial setup instructions and the short introduction to some of the MySQL client commands should, nevertheless, get you started. Fortunately, one of MySQL’s strongest selling points is that it is ready to run with minimal setup after installation and that it requires very little ongoing maintenance. MySQL’s simplicity makes it an ideal choice for busy system administrators who have enough to do keeping their mail servers from getting clogged up with spam and viruses without having to learn how to maintain a complicated RDBMS. As remarked at the beginning of this section, MySQL is an extremely popular database with

Web programmers, precisely because it is easy to use and requires little in the way of ongoing care and feeding. If, after some period of time, you outgrow

MySQL, it might be time to consider PostgreSQL, discussed in the next section.

Table 15-1 MySQL Client Programs

PROGRAM DESCRIPTION

mysql

Provides an interactive command interpreter for the MySQL server mysqlaccess mysqladmin mysqlbinlog mysqlbug

Adds new users to MySQL

Performs MySQL administrative functions

Displays a MySQL binary log file in a format readable by humans

Creates and files bug reports for MySQL mysqlcheck mysqldump

Tests, repairs, analyzes, and optimizes MySQL databases

Backs up or restores data from or to a MySQL database mysqldumpslow

Displays and summaries MySQL’s query log, producing information you can use to optimize slow queries mysqlimport mysqlshow mysqltest

Imports data into MySQL tables from text files of various formats

Displays the structure of MySQL databases, tables, and columns

Runs a database test and compares the results to previous runs

21_599496 ch15.qxd 8/30/05 6:40 PM Page 362

362 Chapter 15

Using PostgreSQL

PostgreSQL is the second most popular free RDBMS. It provides some features not available in MySQL, so if you find you need features or functionality that

MySQL lacks, PostgreSQL might be the solution you need. As with MySQL,

PostgreSQL is popular with Linux users because it is free; fast; feature-rich; easy to set up, use, and maintain; and provides fuller support for the ANSI

SQL99 and SQL 2003 standards than MySQL does. Like MySQL, PostgreSQL is also widely supported by and integrated into a variety of third-party applications. There are numerous Apache modules that make it possible to use

PostgreSQL in Apache-based Web servers, and PHP’s support for PostgreSQL is surpassed only by PHP’s support for MySQL. Among scripting languages,

Perl and Python have wide support for PostgreSQL, and PostgreSQL’s client

API makes it possible and reasonably easy to include PostgreSQL support in C and C++ applications.

Out of the box, PostgreSQL is ready to use. You’ll need to make sure that it is installed of course, and there are some postinstallation tasks you need to perform to secure the database and to make sure the database is functioning and answering requests. This section will also show you, briefly, how to use some of the PostgreSQL client commands.

Why would you want to use PostgreSQL instead of MySQL? The easiest answer is that you should use PostgreSQL if it has a feature or functionality that MySQL doesn’t. If you are looking for standards compliance, PostgreSQL is more compliant with SQL standards than MySQL is and supports certain types of SQL queries that MySQL doesn’t. Traditionally, the biggest knock against MySQL was that it was just a glorified data file (an ISAM or index

sequential access method file, to be precise) that supported SQL-driven data access. PostgreSQL, on the other hand, while providing persistent data storage using the file system, used to have a different in-memory layout to support

SQL-driven data access. This distinction is no longer true because MySQL now provides multiple methods of persistent data storage and is no longer an

ISAM-based one-trick pony.

PostgreSQL is more marketing-buzzword-compliant, too, in that it supports spatial data types and is object-relational. The spatial data types make it possible to create GIS applications using PostgreSQL. Object-relational means that

PostgreSQL can use standard SQL access methods and relational data structures to access and manipulate object-oriented data. To provide some guidance, we have prepared a sidebar, “MySQL or PostgreSQL,” that provides a side-by-side comparison of the two packages.

To return to the original question, which one should you use? We can’t tell you. As a system administrator, these concerns are ordinarily peripheral to your primary job function. You maintain the system on which the database

21_599496 ch15.qxd 8/30/05 6:40 PM Page 363

Configuring a Database Server 363

MYSQL OR POSTGRESQL?

If you want to start an argument among in a group of people familiar with free

RDBMSes, ask them which is better, PostgreSQL or MySQL. It is not this chapter’s intent to start an argument, so it avoids saying which is better. There are significant differences between MySQL and PostgreSQL, though, and knowing what these differences are might help you decide which one to use. Table 15-2 lists features generally expected to exist in a RDBMS and shows whether MySQL and PostgreSQL as shipped in Fedora Core and RHEL support them.

As you can see in the table, PostgreSQL supports a larger set of features common in the commercial RDBMS world than MySQL. However, bigger isn’t necessarily better because the richer feature set might be overkill for your needs.

In addition, the versions of PostgreSQL and MySQL that ship in Fedora Core and

Red Hat Enterprise Linux lag somewhat behind the current stable versions of those products. At the time this book went to press, the versions of PostgreSQL and MySQL shipping with Fedora Core and RHEL were 7.4.7 and 3.23.58, respectively, while the latest and greatest released versions were 8.0 and 4.1.9

(MySQL 5.0 had just entered an alpha release state).

For a fuller comparison of the features set of particular version

PostgreSQL and MySQL, see the comparison table maintained by MySQL at

http://dev.mysql.com/tech-resources/features.html

.

runs and possibly install/upgrade the software and perform the initial configuration. It is up to information architects and database administrators (DBAs) to make decisions about which database to use and the relative merits of one database or another. Of course, not every site running Linux has the luxury of this kind of separation of duties. The system administrator of smaller sites is often also the DBA (and the network administrator, mail administrator, Webmaster, telephone technician, and brewer of the morning coffee), so it pays to be familiar with the broad outlines of database features.

Table 15-2 Database Feature Comparison

FEATURE

ACID compliance

Aggregate functions

ANSI SQL compliance

API for custom applications

MYSQL

Yes

Yes

Incomplete

Yes

Complex queries (UNION, UNION ALL, EXCEPT) Yes

Cross-database compatibility features Yes

Yes

Yes

Yes

POSTGRESQL

Yes

Yes

Yes

(continued)

21_599496 ch15.qxd 8/30/05 6:40 PM Page 364

364 Chapter 15

Table 15-2 (continued)

FEATURE

Views

Default column values

Dynamically loadable extensions

Extensible, user-defined data types

Foreign keys

Functional indexes

Functions

Hot stand-by

Index methods

Inheritance

Kerberos support

Locking granularity

ODBC support

Outer joins

Partial indexes

Procedural languages

Referential integrity

Replication

Rules

Sequences

SSL support

Stored procedures

Sub-selects

Transactions

Triggers

Unicode support

Yes

No

Yes

Yes

Yes

Yes

No

Yes

Yes

No

Incomplete

Yes

Yes

Yes

Yes

No

Yes

No

No

No

Yes

No

Yes

MYSQL

No

No

No

Assuming that you’ve decided that PostgreSQL is the database to use, the next two sections show you how to get the standard PostgreSQL installation working and how to use some of PostgreSQL’s client utilities.

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

POSTGRESQL

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Incomplete

Yes

Yes

21_599496 ch15.qxd 8/30/05 6:40 PM Page 365

Configuring a Database Server 365

Verifying the PostgreSQL Installation

You won’t get very far in this section if PostgreSQL is not installed. You can use the following commands to see if the key PostgreSQL RPMs are installed:

# rpmquery postgresql-server postgresql-server-7.4.7-1.FC3.2

# rpmquery postgresql postgresql-7.4.7-1.FC3.2

# rpmquery postgresql-libs postgresql-libs-7.4.7-1.FC3.2

# rpmquery postgresql-devel postgresql-7.4.7-1.FC3.2

The postgresql-server package contains the core PostgreSQL database server. It is required to create and maintain a PostgreSQL database. The postgresql package installs the client utilities, which you will need to do anything with the server. Similarly, the postgresql-libs package installs shared libraries used by all PostgreSQL clients and interfaces; you must have this package installed to be able to connect to the server and to use any other

PostgreSQL package. postgresql-devel, another required package, provides the header files and shared libraries required to create C and C++ programs that interact with PostgreSQL databases. It also includes a C preprocessor to use against C and C++ programs that use the PostgreSQL API. If these four packages aren’t installed, install them as described in Chapter 30.

Other PostgreSQL packages that might also be installed or that you might want to install include:

■■

postgresql-contrib

— Includes selected contributed modules and programs not part of the standard PostgreSQL distribution

■■

postgresql-docs

— Provides a rich documentation suite in both source (SGML) and rendered formats suitable for online viewing or printing

■■

postgresql-jdbc

— Installs a Java database connectivity (JDBC) driver necessary to connect to PostgreSQL using Java

■■

postgresql-odbc

— Installs the Open Database Connectivity (ODBC) driver necessary to connect to PostgreSQL using ODBC

■■

postgresql-pl

— Contains PostgreSQL-specific procedural languages for Perl, Tcl, and Python, enabling you to use these languages to manipulate the server

■■

postgresql-python

— Includes Python support, and the PL/Python procedural language for using Python with PostgreSQL

21_599496 ch15.qxd 8/30/05 6:40 PM Page 366

366 Chapter 15

■■

postgresql-tcl

— Provides Tcl (Tool command language, an embeddable scripting language) support, the PL/Tcl procedural language, and a PostgreSQL-enabled tclsh (a Tcl shell)

■■

postgresql-test

— Contains a number of test suites for performing benchmark and regression tests against the PostgreSQL server

In addition to the packages in the preceding list, other RPMs provide PostgreSQL-related functionality that you likely won’t need. To keep this section simple, we will only refer to programs and utilities provided by the four required packages.

Finalizing the PostgreSQL Installation

On a fresh PostgreSQL installation, no data structures have been created.

Rather, the software has been installed, the postgres user and group have been created, and the data directory, /var/lib/pgsql/data, has been created. The steps you need to take to finalize the installation are:

1. Initialize the installation.

2. Modify access privileges.

3. Create a test database.

4. Validate connectivity to the test database.

The following sections describe each step in this process in more detail.

Initializing the Installation

Use the following procedure to initialize the installation, which consists of creating template data structures and starting the database server:

1. Become the postgres user using su. You do this in two steps, first su

-ing to the root account and then su-ing to the postgres user account:

$ su - root

Password:

# su - postgres

-bash-3.00$

2. Set the environment variable $PGDATA to point to: /var/lib/pgsql

/data

.

$ export $PGDATA=/var/lib/pgsql/data

Most PostgreSQL commands read $PGDATA to know where to find the database. If you don’t set it, you’ll continually have to add an argument

21_599496 ch15.qxd 8/30/05 6:40 PM Page 367

Configuring a Database Server 367

like -D /var/lib/pgsql/data to all of the PostgreSQL commands you use. It gets tedious and is error-prone, so set the environment variable and forget about it.

3. Create the database cluster. A database cluster refers to the data directory and supporting files and directories stored therein, which serve as a template used to create the databases managed by a single PostgreSQL server (yes, you can have multiple PostgreSQL servers, but we aren’t going to go there):

-bash-3.00$ initdb

The files belonging to this database system will be owned by user

“postgres”.

This user must also own the server process.

The database cluster will be initialized with locale en_US.UTF-8.

fixing permissions on existing directory /var/lib/pgsql/data... ok creating directory /var/lib/pgsql/data/base... ok creating directory /var/lib/pgsql/data/global... ok creating directory /var/lib/pgsql/data/pg_xlog... ok creating directory /var/lib/pgsql/data/pg_clog... ok selecting default max_connections... 100 selecting default shared_buffers... 1000 creating configuration files... ok creating template1 database in /var/lib/pgsql/data/base/1... ok initializing pg_shadow... ok enabling unlimited row size for system tables... ok initializing pg_depend... ok creating system views... ok loading pg_description... ok creating conversions... ok setting privileges on built-in objects... ok creating information schema... ok vacuuming database template1... ok copying template1 to template0... ok

Success. You can now start the database server using:

/usr/bin/postmaster -D /var/lib/pgsql/data or

/usr/bin/pg_ctl -D /var/lib/pgsql/data -l logfile start

If you didn’t set the value of the environment variable $PGDATA as recommended in Step 2, you must add -D /var/lib/pgsql/data to the initdb command line to specify the location of the database cluster.

21_599496 ch15.qxd 8/30/05 6:40 PM Page 368

368 Chapter 15

/var/lib/pgsql/data is the default, but you can use any directory.

The initialization process ensures that only the postgres user (and root, of course) has any access whatsoever to the database cluster.

4. Exit the postgres su session because the root user must perform the next step:

-bash-3.00$ exit logout

5. Start the database server. You can use the commands shown at the end of Step 3, but it is easier to use the initialization script, postgresql, which performs the same steps and also executes some sanity checks before starting the server.

# service postgresql start

Starting postgresql service: [ OK ]

With the PostgreSQL server running, you’re ready to proceed to the next part of the process, tightening up access to the server.

Modifying Access Privileges

After you have initialized the installation, you will likely want to modify the default authentication scheme. The default authentication scheme is called

trust authentication because it permits all local users to access the server using any PostgreSQL-recognized username (including the PostgreSQL superuser account). Moreover, this access can use either UNIX-domain sockets (also known as Berkeley sockets) or TCP/IP. We suggest making of the following modifications to the default access policy:

■■

Permit local access using only UNIX-domain sockets.

■■

Require local users to connect to the server using their system login accounts.

■■

■■

Require remote users (connecting via TCP/IP) to use SSL.

Use strong encryption for password checking.

The file /var/lib/pgsql/data/pg_hba.conf controls client authentication. It contains records that have one of three formats. The first format addresses authentication of local clients, that is, clients accessing the server from same machine on which the server is running (localhost). The local access format has the following general form: local database user auth [option]

21_599496 ch15.qxd 8/30/05 6:40 PM Page 369

Configuring a Database Server 369

database identifies the database to which the record applies. It can be one of all, which, you guessed it, applies this rule to all databases; sameuser, which means that the database being accessed must have the same name as the connecting user; samegroup, which means that the database being accessed must have the same name as the group name of the connecting user; or a comma-separated list of one or more names of specific PostgreSQL databases.

user identifies the user to which the authentication record applies. Like database

, user can be all (meaning all users), a username, a group name prefixed with +, or a comma-separated list of either user or group names.

auth specifies the manner in which connecting clients will be authenticated. Table 15-3 lists the possible authentication methods.

option applies options to the specified authentication method and will be either the name of file mapping IDENT-generated usernames to system usernames if you are using PostgreSQL’s ident authentication method or the name of the PAM service to use if you are using PostgreSQL’s pam authentication method.

Table 15-3 PostgreSQL Authentication Methods

METHOD DESCRIPTION

crypt ident krb4

Like the password method, but uses the crypt() library function to encrypt passwords for transmission across the network

Implements authentication using the connecting user’s identity as reported by the IDENT protocol (requires the identd daemon)

Uses Kerberos V4 for authentication, but available only for TCP/IP connections krb5 md5 pam password reject trust

Uses Kerberos V5 for authentication, but available only for TCP/IP connections

Like the password method, but uses MD5-based encryption to foil packet sniffers

Adds Pluggable Authentication Modules (PAM) support to the password method

Permits clients to connect if the supplied password, transmitted as clear text, matches the password assigned to the connecting user account

Rejects all access

Allows any user with a system login account to connect to the server using any PostgreSQL user account

21_599496 ch15.qxd 8/30/05 6:40 PM Page 370

370 Chapter 15

PostgreSQL’s default authentication method for local users is trust. The entire rule looks like the following: local all all trust

As it is, maintainers of the PostgreSQL packages for Fedora Core and RHEL have changed this default to: local all all ident sameuser

Changing the authentication method to ident for local connections means that PostgreSQL will use the IDENT protocol to determine the PostgreSQL user account. To put it another way, if the authentication method for local connections is ident, PostgreSQL uses the local system’s IDENT server to obtain the name of the user connecting to the server. Adding the authentication option sameuser means that the connecting user must have a system login account.

The following rules implement three of the restrictions for local connections suggested earlier (local access only through UNIX-domain sockets, local users connect using their system login accounts, use strong encryption): local all all md5 host all all 127.0.0.1 255.255.255.255 reject

In the first rule, the authentication method is md5, which requires strong encryption. The second rule rejects (the reject authentication method) all users connecting from the host (more about host rules in a moment) whose IP address is 127.0.0.1, that is, all users connecting from localhost via a TCP/IP

connection. Records of the local type control connection from UNIX-domain sockets, so the second rule does not affect connection originating from the local machine. In any event, connections from the local machine are explicitly permitted by the first rule, which takes precedence over the second rule.

T I P

PostgreSQL access rules do not “fall through.” Rather, rules are evaluated until a match occurs, at which point evaluation stops and the matching rule is

applied. Accordingly, the order in which access rules appear in the pg_hba.conf

is important.

Rules affecting TCP/IP connections have the following general format:

type database user ipaddr ipmask auth [option]

The database, user, auth, and option values have the same semantics as described for local connections. The type value must be one of host,

21_599496 ch15.qxd 8/30/05 6:40 PM Page 371

Configuring a Database Server 371

hostssl

, or hostnossl. host matches any connection coming in via

TCP/IP, whether it uses SSL nor not. hostssl matches only TCP/IP connections that use SSL. hostnossl matches only TCP/IP connections not using

SSL. The ipaddr (an IP address) and ipmask (an IP net mask) options enable you to control in a very finely grained manner the remote hosts that can connect to the server. For example, the ipaddr ipmask pair of 127.0.0.1 255

.255.255.255

refers to only the IP address 127.0.0.1, where as the ipaddr ipmask pair 127.0.0.0 255.255.255.0 refers to all IP addresses between

127.0.0.1 and 127.0.0.254. IP addresses must be specified in standard numeric

(or dotted quad) format; host and domain names do not work.

So, to implement the recommended restrictions for clients connecting via

TCP/IP (you must use SSL, use strong encryption), the following rules should suffice: hostnossl all all 0.0.0.0 0.0.0.0 reject hostssl all all 0.0.0.0 0.0.0.0 md5

The first rule rejects all connections from any remote host not connecting via

SSL. The second rule permits all SSL-based connections for all users to all databases and uses MD5 authentication. The second rule is still too liberal if you want to restrict access to specific hosts or domain, however. To permit access to the finance database for all users on the finance subnet, which has the IP address 192.168.2.0, the rule hostssl finance all 192.168.2.0 255

.255.255.0 md5 will do. It should replace the previous hostssl rule, so the rule set becomes: hostnossl all all 0.0.0.0 0.0.0.0 reject hostssl finance all 192.168.2.0 255.255.255.0 md5

If you want to reject all other remote connections, use add the following rule: hostssl all all 0.0.0.0 0.0.0.0 reject

Thus, the final rule set looks like the following: hostnossl all all 0.0.0.0 0.0.0.0 reject hostssl finance all 192.168.2.0 255.255.255.0 md5 hostssl all all 0.0.0.0 0.0.0.0 reject

The evaluation sequence firsts rejects all TCP/IP connections not using SSL.

The second rule permits any client passing the first test to connect to the finance database if the client has an IP address between 192.168.2.1 and

192.168.2.254 (inclusive). If a match occurs at this point, rule evaluation stops.

Otherwise, the next rule is evaluated, which rejects all other incoming TCP/IP

21_599496 ch15.qxd 8/30/05 6:40 PM Page 372

372 Chapter 15

connections, even if they use SSL. In practice, you will likely find that it is easiest to permit access to specific users and databases based on IP address or, in the case of local connections, login account names.

To make the access rule changes take affect, you need to reload the access control file. You can do this using the service utility, as shown in the following example:

# service postgresql reload

Alternatively, execute the following command as the postgres user:

-bash-3.00$ pg_ctl reload postmaster successfully signaled pg_ctl is a simple utility for starting, stopping, reloading, and checking the status of a running PostgreSQL database. For security purposes, only the user under which the PostgreSQL server runs (postgres on Fedora Core and

RHEL systems) should invoke PostgreSQL command directly in this manner.

After reloading the access control file, you’ll want to create a test database to confirm that the server is working properly.

Creating a Test Database

So far, so good. You’ve initialized the database server and tightened up access to it. The next step is to create a test database so that you can validate that the server is functioning and that your access control rules work as you intended.

Without going into the gruesome details, the initdb command you executed earlier created an initial database, named template1, which, as the name suggests, serves as a template or model for subsequent databases. Ordinarily, you never want to modify the template database because it is essentially cloned when a new database is created, so changes made to the template apply to all databases created from it. As you might guess, though, prudently chosen modifications to template1 can be used to override PostgreSQL defaults that you might dislike. The task in this chapter is getting the server up and running, so we’ll adroitly sidestep this issue and create a database using PostgreSQL’s default settings.

PostgreSQL provides a utility named createdb that you can use to create a database. Its syntax is refreshingly simple: createdb [opt ...] [dbname] [desc]

Notice that all of the arguments are optional. If executed with no arguments, createdb creates a new database named for the user executing the command.

This is not what you want in most situations. dbname specifies the name of the database you want to create. desc is a comment or description associated with

21_599496 ch15.qxd 8/30/05 6:40 PM Page 373

Configuring a Database Server 373

the database. opt supplies one or more options that either affect createdb’s behavior or that are passed to the server to specify certain characteristics of the database created. The following options most immediately concern:

■■

-D path

— Creates the database in path rather than the default location,

$PGDATA

■■

-e

— Echoes the SQL commands sent to the server to create the database

■■

-O owner

— Assigns owner rather than the user executing createdb as the database owner

The following command creates a test database named rhlnsa3 (witty, huh?) and adds a short description. You should execute this command as the postgres user:

-bash-3.00$ createdb -e rhlnsa3 “Test database for chapter 15”

CREATE DATABASE rhlnsa3;

CREATE DATABASE

COMMENT ON DATABASE rhlnsa3 IS ‘Test database for chapter 15’;

COMMENT

You can use single or double quotes around the string used to create the description. If you are unfamiliar with SQL, using the -e option to echo the

SQL commands sent to the server is useful. The actual commands sent appear with terminating semicolons (;). In the absence of the -e option, you would see only summaries of the SQL statements executed, as illustrated in the following example:

-bash-3.00$ createdb rhlnsa3 “Test database for chapter 15”

CREATE DATABASE

COMMENT

To facilitate testing, create a new database user using the createuser utility, which is a wrapper around the SQL statements necessary to add a user. The syntax is simple: createuser [-P [-E]] username

This command creates a database user named username. To assign a password, use the -P option. To have the assigned password encrypted, specify -E.

Consider the following example:

-bash-3.0.0$ createuser -P -E bubba

Enter password for new user:

Enter it again:

Shall the new user be allowed to create databases? (y/n) n

Shall the new user be allowed to create more new users? (y/n) n

CREATE USER

21_599496 ch15.qxd 8/30/05 6:40 PM Page 374

374 Chapter 15

This example creates a new database user named bubba, assigning an encrypted password as part of the process. The last two prompts ask if you want bubba to be able create new databases and create other users. bubba is only a test user, so he doesn’t get any special treatment. Recall that you are using ident authentication with the sameuser authentication option, which means that the user created, bubba in this case, must also have a login account on the system.

Testing Connectivity to the Test Database

The final step of the PostgreSQL initialization involves using the test user

(bubba) to connect to the database. While you have already established that the postgres user can connect to the server when you created the test database and the test user, it is important to make sure that normal users can also connect to the server and that the access rules you create work as you intend.

To test the database server, use the following procedure:

1. Become the user for whom you created the database user account:

$ su - bubba

Password:

[bubba]$

You have to become bubba because ident-based authentication is in use, which means you have to be the same user as you use to connect to the database.

2. Use the psql command shown in the following example to connect to the rhlnsa3 database:

[bubba]$ psql -W rhlnsa3

Password:

Welcome to psql 7.4.6, the psql interactive terminal

Type: \copyright for distribution terms

\h for help with SQL commands

\? for help on internal slash commands

\g or terminate with semicolon to execute query

\q to quit rhlnsa3=> pqsl is the PostgreSQL’s shell or command interpreter. Notice how the default prompt is the name of the database followed by =>. Depending on the activity you are performing, the second-to-last character of the prompt changes.

3. Use the following SQL commands to create a new table: rhlnsa3=> create table chapters ( rhlnsa3(> chapnum int,

21_599496 ch15.qxd 8/30/05 6:40 PM Page 375

Configuring a Database Server 375

rhlnsa3(> title varchar(80), rhlnsa3(> pages int rhlnsa3(> );

CREATE TABLE rhlnsa3=>

Notice how opening a parenthesize statement causes the shell prompt to change from => to (> to indicate that it’s waiting for matching closing parenthesis. The terminating semicolon is required.

4. Add data to the table using the following SQL statements: rhlnsa3=> insert into chapters (chapnum, title, pages) rhlnsa3-> values (15, ‘Configuring a Database Server’, 35);

INSERT 17148 1

In this case, the shell prompt became ->, indicating that it is waiting for a closing semicolon to terminate the SQL command.

5. Use the following query to retrieve the data you just added: rhlnsa3=> select * from chapters; chapnum | title | pages

---------+-------------------------------+-------

15 | Configuring a Database Server | 35

(1 row)

6. Exit the PostgreSQL shell: rhlnsa3=> \q

You can also use Ctrl+d to exit the PostgreSQL shell.

If the procedures described in the last few sections worked, your database server is up and running and working the way it should. The next section introduces a few of the PostgreSQL client programs that you will at least want to know exist.

Using the PostgreSQL Client Programs

PostgreSQL’s client programs, like MySQL’s, implement a user interface to the server. psql, as you just learned, provides the most complete and direct access to the server but requires you to know at least some SQL. Other utilities, like createdb

, createuser, and their analogs, dropdb (for deleting a database) and dropuser (for deleting a user) are wrapper scripts that invoke SQL statements for you. If you are not a database guru (or don’t want to be), you’ll probably be most comfortable using the various wrapper utilities. Table 15-4 lists some the PostgreSQL client programs with which you will want to be familiar.

21_599496 ch15.qxd 8/30/05 6:40 PM Page 376

376 Chapter 15

Table 15-4 PostgreSQL Client Programs and Utilities

PROGRAM DESCRIPTION

createdb createuser

Creates a new database in the database cluster

Creates a new user in the database cluster dropdb dropuser pg_dump pg_restore

Deletes a database from the database cluster

Deletes a user form the database cluster

Saves (dumps) the contents of a database or database object to a file

Reloads a database or database object using a file created by pg_dump psql

Provides a command interpreter for interacting with a database server

Most PostgreSQL clients share a number of options in common. For example,

-U username specifies the username to use when connecting to the server. -W indicates you should be prompted for a password. -D /path specifies the path to the PostgreSQL database cluster, which defaults to the value of the environment variable $PGDATA or the compiled in default (/var/lib/pgsql/data).

-e causes wrapper scripts like createdb and dropuser to echo to standard output (stdout) the SQL commands used. Commands that operate on or require a connection to a specific database usually accept a database name as an argument. If a database name is not specified, it defaults to the name of the user connecting to the database specified using -U username or to the connecting user’s login name if -U username is not specified.

Similarly, most PostgreSQL clients can use PostgreSQL-specific environment variables to set certain defaults. In addition to $PGDATA, which you’ve already seen, the variable $PGDATABASE stores the name of the database to use (or create or drop) unless overridden on the command line. $PGHOST specifies the name of the host on which the database server is running and so is usually used when connecting to a database running on a remote host.

$PGUSER defines the default connection parameters, which usually consists of the PostgreSQL user name.

You’ve already seen the syntax for createdb and createuser, so we won’t review it here. dropdb and dropuser drop (delete) a database or user, respectively, from the database cluster. dropdb’s syntax is: dropdb [option ...] dbname dbname identifies the database to drop and option (there can be multiple option s) accepts the options previously described and, most importantly, the

21_599496 ch15.qxd 8/30/05 6:40 PM Page 377

Configuring a Database Server 377

-i option, which asks for confirmation before actually dropping the database.

This is an important option because dropping a database deletes the data and data structures associated with the database. Unless you have previously saved the data, dropping a database is a permanent action. Because it is such a drastic action, only the database owner and the PostgreSQL superuser have privileges to drop a database. As a precaution, you should always save the database data before dropping it (use the pg_dump command, about which you’ll learn shortly).

The dropuser wrapper utility deletes a specified user from the database cluster. Its syntax is: dropuser [option ...] username

Replace username with the name of the PostgreSQL user account you want to delete. The possible values for option were described earlier and won’t be repeated here, except to add the dropuser, like dropdb, also accepts the -i option to request interactive use.

Before dropping a database, you should use the pg dump pg_dump program to save the data unless you are absolutely, positively, 100 percent certain beyond the slightest shadow of a doubt that you won’t need the data in the future. pg_dump’s syntax is: pg_dump [option ...] dbname

As usual, dbname specifies the name of the database to dump. option controls the actual dump behavior. The various options already described also work with pg_dump, but it has a number of options specific to its behavior that you’ll want to know about. pg_dump is usually used to archive and retrieve data, such as for backup and upgrade purposes, so the options discussed focus on that purpose.

A typical archive/restore operation consists of dumping the database, dropping it, recreating it, and reloading it with the dumped data. Using the -C option, pg_dump will begin the dump output with the SQL statements necessary to create the database and then connect to it. The rest of the dump will consist of COPY statements that use a PostgreSQL-specific extension for performing high-speed data loads. Use the -f filename option to specify the name of the output file. If you don’t use this option, output goes to stdout and must be redirected to a file using the shell’s > operator. To create an output file, finally, most suitable for use with pg_restore (described next), use the -Fc option, which specifies a custom output format specifically designed for use with pg_restore (-Fp outputs a plain ASCII text file with data and SQL statements and -Ft outputs a tar archive that pg_restore can read).

21_599496 ch15.qxd 8/30/05 6:40 PM Page 378

378 Chapter 15

If you want to dump only the database schema (the actual design of the database, not its data) specify the -s option. Similarly, if you are interested in only the contents of a particular table, specify -t table, where table is the name of the table that interests you.

pg_restore is pg_dump’s counterpart and restores or reloads a PostgreSQL database dump created with pg_dump. It also accepts the same command-line options as pg_dump, so your learning curve has flattened out considerably. The difference between the two is that pg_restore’s argument is the name of an input file created by pg_dump.

So, given the following pg_dump command:

-bash-3.00$ pg_dump -Fc -C rhlnsa3 > rhlnsa3.db

You can restore the contents of the tables in the database rhlnsa3 using the following pg_restore command (the rhlnsa3 database must exist) after dropping any tables in the database:

-bash-3.00$ pg_restore -d rhlnsa3.dump

Table 15-5 lists the PostgreSQL server programs you’ll want to know how to use.

You will rarely, if ever, need to invoke the postgres command directly. It is called by the postmaster command. postgres is responsible for processing queries for a single connection to the database server. When a connection starts, postmaster, which listens for incoming connection requests, starts a postgres process to handle that connection. In addition to serving as the multiuser server for a PostgreSQL databases, postmaster is also responsible for handling communication between individual postgres processes. You can also almost always rely on the PostgreSQL initialization script, postgresql, to start and stop the postmaster service, so you should hardly ever need to execute postmaster directly.

Table 15-5 PostgreSQL Server Programs and Utilities

PROGRAM DESCRIPTION

initdb pg_ctl

Creates and initializes a PostgreSQL database cluster

Controls a running database server instance postgres postmaster

Processes queries for a single connection to a PostgreSQL database (usually started by postmaster)

Starts postgres processes to handle incoming database connections and coordinates communication between postgres processes

21_599496 ch15.qxd 8/30/05 6:40 PM Page 379

Configuring a Database Server 379

Summary

Linux-based database servers are becoming as ubiquitous as Linux-based Web and email servers, so it is likely that you will need to create a database server at some point. While you don’t need to be on a first-name basis with the finer points of database administration to configure a database server, it does help to be familiar with the general process. Just installing the software isn’t usually sufficient, either. As an administrator, you usually need to be able to make sure that the database is accessible (or not as the case might be), that the initial accounts are secure, and that the server is working. This chapter showed you how to configure MySQL and PostgreSQL to a basic level of functionality. As you learned, installing them is easy, but the postinstallation configuration and testing can be tedious. The good news is that database installations are usually performed in conjunction with a DBA who provides guidelines and instructions for you to follow. You’re rarely on your own.

21_599496 ch15.qxd 8/30/05 6:40 PM Page 380

22_599496 ch16.qxd 8/30/05 6:40 PM Page 381

C H A P T E R

16

Creating a

VNC Server

IN THIS CHAPTER

■■

■■

■■

What Is VNC?

Setting Up a VNC Server

Testing the VNC

Providing network services for remote employees, whether they are road warriors barricaded in a hotel room or telecommuters working from a home office, is nothing new. As telecommuting becomes more common and broadband

Internet access more widespread, system administrators are increasingly being asked to provide remote access to their networks. Various approaches to providing LAN services to disconnected employees have been tried over the years, including remote control software virtual private networks (VPNs). The goal has always been to make it possible for remote employees to use another computer or LAN-based services as if those employees were sitting in the office. VNC gives you remote access to an existing desktop system and all of the resources that it can access. This chapter describes how use Fedora Core and RHEL to create a VNC server, enabling telecommuters and other remote employees to access a Fedora Core- or RHEL-based LAN and LAN-based services. It also shows you how to configure a Linux system as a VNC client.

What Is VNC?

Just to get the acronym out of the way, VNC stands for virtual network computing, and it provides a way to fully control one computer from any other computer or similarly capable device situated anywhere on the Internet. One of

381

22_599496 ch16.qxd 8/30/05 6:40 PM Page 382

382 Chapter 16

the virtues of VNC solutions over other methods is that VNC is cross-platform.

You can access and control a Linux host from a Windows PC, something not possible with products like PCAnywhere. Another VNC advantage is that the protocol is optimized for Internet transmission, so it is actually possible and not glacially slow to run X applications across the Internet.

In addition to providing remote users access to LAN-based systems and services, VNC also has clear uses for help desk technicians, other technical support professionals, and system administrators. If you ever worked at a help desk, you know how difficult it is to get the “helpees” on the other end of the telephone to tell you what the screen looks like, what applications are running, and even to coherently describe the problem they’re having. You also know how hard it is to make sure that the person you’re helping types the commands you want typed or executes the problem resolution procedure properly.

Using VNC, you have immediate access to the user’s system and can remotely diagnose and troubleshoot the problem at hand, all without having to leave your desk. VNC is a real boon for system administrators for the same reasons.

Even if out of the office or at a remote site, the administrator always has access to management and monitoring tools that can make detecting and fixing a troublesome server a trivial undertaking.

Unlike older, less capable remote control software, VNC supports multiple incoming connections to the same VNC server, so it is possible for several users to connect to the same system and work collaboratively on a project, such as a presentation. Alternatively, you can use a single VNC server as an access concentration point from which properly authorized users can connect to other systems. Another difference between VNC and other remote control protocols is that VNC, described as “remote display protocol” or an RFB

(remote framebuffer), is an open and nonproprietary protocol, whereas the other products (from Symantec, Citrix, Insignia Solutions, and Microsoft) are closed protocols that are closely tied to the Windows GUI.

What VNC is not is a VPN, or virtual private network. Speaking broadly, a

VPN is a network configuration in which a main internal network has remote nodes (such as telecommuting employees) that use a VPN running over (perhaps it is better to say across) the Internet to access the main internal network.

To achieve this, a secure (encrypted) tunnel is created between the main network and the remote nodes, and IP traffic is routed through that tunnel. VNC, on the other hand, while it can be used across a VPN and uses the Internet to transport packets back and forth, is usually used to provide access to a single system and to allow a remote user full control over that system. More succinctly, VPN makes a remote system part of the main network; VNC gives a remote user control over one system on the main network.

For more information about VNC, two of the best resources are the excellent

VNC overview at uk.research.att.com/pub/docs/att/tr.98.1.pdf

22_599496 ch16.qxd 8/30/05 6:40 PM Page 383

Creating a VNC Server 383

and the RealVNC Web site (realvnc.com/). There is a connection between

AT&T and RealVNC. Researchers at the AT&T UK research labs created VNC.

RealVNC was formed by some of the AT&T researchers as a venture to commercialize VNC technology. The VNC software is licensed under the GPL, so

RealVNC’s business model depends on providing support, service, and valueadded software.

Setting Up a VNC Server

In this context, a VNC server is the machine you want to access remotely. So, if you’re at home and want to connect to the Linux system on your desk at work, the system at work is the server; the system at home is the VNC client. Figure

16-1 illustrates this arrangement.

To set up a VNC server, you’ll need to install the vnc-server and vnc packages. The commands shown below will show you if they are installed:

$ rpmquery vnc-server vnc-server-4.1.1-10

$ rpmquery vnc vnc-4.1.1-10

If these packages are not installed, install them before proceeding.

Starting the VNC server is simplicity itself: execute the Perl script vncserver as a mortal user. vncserver is a wrapper script that handles the persnickety details of starting Xvnc, the X Window System VNC server. Speaking more precisely, Xvnc creates a VNC desktop on the server system to which VNC clients can connect. There is a configuration step that must be performed by the root user, but starting the server does not require any special privileges. The first time you start vncserver, you have to set the password that connecting clients must issue, as shown in the following example:

$ vncserver

You will require a password to access your desktops.

Password:

Verify:

New coondog.example.com:1 (bubba)’ desktop is coondog.example.com:1

Creating default startup script /home/bubba/.vnc/xstartup

Starting applications specified in /home/bubba/.vnc/xstartup

Log file is /home/bubba/.vnc/coondog.com:1.log

22_599496 ch16.qxd 8/30/05 6:40 PM Page 384

384 Chapter 16

VNC Server VNC Client

INTERNET

Corporate

Firewall

Figure 16-1 Typical VNC client and server configuration.

Home

Firewall

The output is important. The first line after setting the password indicates that Xvnc has created a new display, :1 on the host coondog.example

.com

. You will need this information when you connect from the client system. vncserver asks for a password only the first time you start it. You can change the password later using the command vncpasswd or by removing the file $HOME/.vnc/passwd.

The next two lines tell you that a startup script, /home/bubba/.vnc

/xstartup

, has been created and that the script has been executed, that is, the applications it specifies are running on the Xvnc display. This means that when you connect to the VNC server, the client will have those applications already running. This also means that if you want to customize the desktop provided by the server, you can edit the xstartup file. Finally, vncserver tells you where to find the log file it creates, which will simplify troubleshooting the VNC server problems if you encounter any. When vncserver completes, a simple, unadorned VNC desktop is ready to accept connections.

Configuring Your Firewall for VNC

Well, your VNC server is almost ready to accept connections. VNC listens on port 5500 plus the X display number for incoming VNC client sessions. On a properly secured system, these ports are blocked at the firewall. You have to punch a hole in the firewall for that port so that VNC clients can get through to the server. This configuration step requires root access because you need to use the Security Level Configuration tool to modify your system’s firewall setup (you are running a firewall, right?).

1. To start the Security Level Configuration tool, select Red Hat ➪ System

Settings ➪ Security Level or type system-config-securitylevel at a command prompt. Figure 16-2 shows the Security Level Configuration tool’s main screen.

22_599496 ch16.qxd 8/30/05 6:40 PM Page 385

Creating a VNC Server 385

Figure 16-2 The Security Level Configuration tool.

The firewall configuration shown in Figure 16-2 is tight: no external access of any sort is permitted on this machine. You’re about to change this. In the Other ports: (1029:tcp) text box, type 5901:tcp. By default,

VNC uses ports numbered 5900 plus the display number. In this example, the display number is :1, so the port number is 5901. If you were using display number :21, the port number would be 5912. The :tcp portion of the port number tells the firewall to open port 5901 for TCP connections because the remote framebuffer protocol uses TCP, not UDP.

2. After you have entered the appropriate port number (see Figure 16-3), click OK to save your change and close the Security Level Configuration tool. Click Yes when the tool warns you that you are about to overwrite your existing firewall configuration.

VNC clients can now access the VNC server, so the server configuration is complete.

22_599496 ch16.qxd 8/30/05 6:40 PM Page 386

386 Chapter 16

Figure 16-3 Opening TCP port 5901 with the Security Level Configuration tool.

Customizing the VNC Server

Sure, the server configuration is complete, but the default desktop (jump ahead to Figure 16-5) is ugly, unless you like the twm window manager and the plain gray background. Remember that xstartup file, /home/bubba/

.vnc/xstartup

? You can edit that to change the default desktop. Listing

16-1 shows the default xstartup file:

#!/bin/sh

# Uncomment the following two lines for normal desktop:

# unset SESSION_MANAGER

# exec /etc/X11/xinit/xinitrc

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup

[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources

xsetroot -solid grey vncconfig -iconic & xterm -geometry 80x24+10+10 -ls -title “$VNCDESKTOP Desktop” & twm &

Listing 16-1 The default xstartup file.

22_599496 ch16.qxd 8/30/05 6:40 PM Page 387

Creating a VNC Server 387

As you learned in Chapter 9, X Window System startup files configure your

X environment and start certain X programs each time you log in. In this case, xstartup does the following:

1. Executes the file /etc/vnc/xstartup if it exists and is executable.

2. Loads any X resources stored in the file .Xresources if it exists and is readable.

3. Invokes xsetroot to set the background color to solid gray.

4. Starts the vncconfig program minimized.

5. Starts an 80x24 xterm with a specific title.

6. Starts twm, the Tab Window Manager.

If you want your usual desktop, the one you get when you are sitting in front of the system, do what the instructions suggest and uncomment the following two lines:

# unset SESSION_MANAGER

# exec /etc/X11/xinit/xinitrc

You should also comment out the last four lines. The modified file should resemble Listing 16-2.

#!/bin/sh

# Uncomment the following two lines for normal desktop: unset SESSION_MANAGER exec /etc/X11/xinit/xinitrc

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup

[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources

#xsetroot -solid grey

#vncconfig -iconic &

#xterm -geometry 80x24+10+10 -ls -title “$VNCDESKTOP Desktop” &

#twm &

Listing 16-2 xstartup modified to display your standard desktop.

The modified xstartup file starts your usual desktop because it invokes the system xinitrc file, which starts the standard X initialization process.

You might want to stick with the default VNC server configuration, though.

Running X over a network connection is always going to be slower than running it directly unless you have a very fat pipe and no network congestion. The default VNC configuration runs the twm window manager, which is considerably faster than X desktop environments like KDE and GNOME. twm is also

22_599496 ch16.qxd 8/30/05 6:40 PM Page 388

388 Chapter 16

faster than many modern window managers too. The point is that the less eye candy transmitted over the wire, the faster your VNC setup will be. Yes, twm might make your eyes bleed, and it definitely lacks features that many have come to expect from your window manager. However, if you are working remotely, you might not need the application integration and the eye candy as much as you need a responsive “desktop.” You can also customize twm by editing (or creating) a twmrc file, which might make it a little easier on your eyes.

Testing the VNC

Testing your VNC setup is simple. First, make sure that it works locally by starting a VNC client on the same system as the VNC server. If the VNC server you started in the section “Setting Up a VNC Server” isn’t running, restart it:

$ vncserver

New ‘luther.kurtwerks.com:1 (kwall)’ desktop is luther.kurtwerks.com:1

Starting applications specified in /home/kwall/.vnc/xstartup

Log file is /home/kwall/.vnc/luther.kurtwerks.com:1.log

Next, in a terminal window, start the VNC client, or viewer, by executing the command vncviewer :n, replacing n with the display number vncserver reported when it started (1, in the example). You will see the password prompt shown in Figure 16-4.

$ vncviewer :1

VNC Viewer Free Edition 4.1.1 for X - built Apr 27 2005 02:25:46

Copyright (C) 2002-2005 RealVNC Ltd.

See http://www.realvnc.com for information on VNC.

Sat May 21 01:01:32 2005

CConn: connected to host localhost port 5901

CConnection: Server supports RFB protocol version 3.8

CConnection: Using RFB protocol version 3.8

Figure 16-4 The VNC authentication dialog box.

22_599496 ch16.qxd 8/30/05 6:40 PM Page 389

Creating a VNC Server 389

Type the password you provided when you configured the VNC server and press Enter. Assuming that you are using the default VNC server configuration (the one that uses twm), the resulting screen should resemble Figure 16-5.

Figure 16-5 doesn’t look terribly impressive, but the purpose of this exercise is to satisfy yourself that the server is working. You should be able to start applications, surf the Web (assuming that the server is connected to the Internet), and use the remote computer just as if you were sitting in front of it. Figure 16-6, for example, shows the Fedora Project Web site in a Mozilla browser session started from the VNC client.

Figure 16-5 Viewing the default VNC desktop in a VNC client.

Figure 16-6 Using Mozilla in the VNC client.

22_599496 ch16.qxd 8/30/05 6:40 PM Page 390

390 Chapter 16

You can also start the VNC client by selecting Red Hat ➪ Accessories ➪

VNC Viewer. If you use the menu, you will have to specify the VNC server to which to connect, as shown in Figure 16-7.

The server specification shown in Figure 16-7 included the display number.

If you don’t include this value, you won’t get a connection. You can use either the IP address, as shown in the figure, or the hostname. In fact, if you use the hostname, you can use the FQDN or the alias, if one is defined in /etc/hosts.

After establishing that the server is working, close the client session by pressing

F8 while the viewer has the focus and selecting Exit Viewer from the pop-up menu. (See Figure 16-8.)

Now, test the configuration from a remote machine. Figure 16-9 shows a

VNC client session running on Microsoft Windows XP. The client software is the RealVNC for Windows, which is the same product as used on Fedora Core and RHEL systems.

Figure 16-7 Specifying the target VNC server.

Figure 16-8 The VNC viewer pop-up menu.

22_599496 ch16.qxd 8/30/05 6:40 PM Page 391

Creating a VNC Server 391

Figure 16-9 Using a Linux VNC server from Microsoft Windows.

To get the full effect of VNC, especially when you use the viewer from a

Windows system, consider Figure 16-10, which shows a VNC session to the server configured in the first section of this chapter. In this case, the server was started using the modified xstartup in Listing 16-2, which displays the standard system desktop (KDE, in this case) rather than the faster, nimbler, and uglier twm.

To reiterate the point made earlier, running X across a network, especially the Internet, is going to be a slower affair than running it directly. On a LAN such as a home network (the environment in which the Figures 16-9 and 16-10 were taken), the performance hit will be minimal, and you might not notice or mind the difference. Across the Internet, you will find it intolerably slow running something like KDE, GNOME, or the more, shall we say, feature-rich window managers. Whether you use KDE with all the trimmings or something leaner like twm, you will definitely appreciate being able to access your desktop system from a remote location.

22_599496 ch16.qxd 8/30/05 6:40 PM Page 392

392 Chapter 16

Figure 16-10 Running KDE on Microsoft Windows via VNC.

When you are done running the VNC server, you can kill the running process by passing the -kill option to vncserver:

$ vncserver -kill :1

Killing Xvnc process ID 30790

Replace :1 with the display number on which the VNC server was running.

Summary

Providing road warriors and telecommuters access to LAN-based services is an increasingly important requirement that system administrators are asked to meet. VNC is one way to meet that requirement. With minimal configuration on the server side and no configuration on the client side, you can provide remote access to one or more Linux systems using VNC. As always, poking a hole in your firewall to permit external access poses a security risk, so you have to weigh that risk against the advantages and decide whether VNC is the way you want to go. As you saw in this chapter, the advantages of remote access to your desktop system are hard to dispute.

23_599496 ch17.qxd 8/30/05 6:41 PM Page 393

C H A P T E R

17

Providing Additional

Network Services

IN THIS CHAPTER

■■

■■

Configuring a Time Server

Providing a Caching Proxy Server

Any system administrator can testify that requests for new or enhanced services pop up constantly. Sometimes they arrive in a trickle; other times a fire hose delivers them. One commonly requested service is a time server, a service that provides the authoritative clock against which all other systems on the

LAN sync their clocks. Perhaps the boss wants people to be able to share information on the company intranet and asks you to create a way to post Web documents to the intranet Web server. This chapter describes setting up two nonessential LAN-based services that select groups of intranet users (or you) might find useful. These services fall into the nonessential category because they provide functionality that is nice to have but without your LAN is still amply serviceable.

The nonessential services described in this chapter include an NTP-based time server and a caching proxy server. Naturally, these two topics hardly exhaust the possible list of conveniences users (and managers) can and do request. Some of the topics that might seem appropriate for this chapter are covered elsewhere in the book. For example, Chapter 16 describes how to set up a

VNC server to give remote users access to their desktops. Building a Web server for your company intranet is no different from building a Web server that faces the Internet, a topic covered in Chapter 23. Likewise, Chapter 24 shows you how to configure some of the Web-based services users typically want, such as mailing lists, Web-based email, site search functionality, and RSS feeds.

393

23_599496 ch17.qxd 8/30/05 6:41 PM Page 394

394 Chapter 17

More to the point, we had to limit the topics we covered, just as administrators have to limit the services they provide. And that point might be as important as the specifics of creating a time server or setting up a proxy server. You have to know when to say “No” to feature requests. In some cases, a requested feature might pose more of a security risk than you are willing to take. In other cases, a network enhancement might stress your network infrastructure or utilize network, system, and CPU resources better used for other purposes. In still other cases, you might simply lack the personnel or time to manage any more services. Whatever the case, you must be able and willing to say no to such requests, if only to preserve your sanity.

Configuring a Time Server

For this chapter’s purposes, a time server is a daemon that runs on one machine and to which other systems (in this case, clients on your LAN) synchronize their system clocks. In the common case, you synchronize your time server’s clock against one or more reference time servers that are situated outside your LAN.

In some cases, the time server synchronizes its time against a specially designed clock. This hardware clock is a separate, single-purpose hardware device that maintains extremely accurate time. (More about these details shortly.)

The motivation for a time server is to keep the system time consistent throughout the LAN so that time-sensitive operations work reliably. In development shops, the make utility uses files timestamps to determine which components of a software project need to be rebuilt. If you have an inaccurate system clock, the timestamps on files will be inconsistent, causing project builds to fail or to behave unpredictably. Similarly, source code version control systems often rely on file and directory timestamps to track changes to files maintained in the source code repository. NFS is also sensitive to timekeeping irregularities. If the system clock on a client machine is significantly faster or slower than the system clock on the NFS server, you will run into problems saving files. Irregularities in system clocks between client systems and the server can adversely affect the mechanisms content management systems use to update and maintain complex Web sites.

To take one example from our own experience, we have an NFS server from which users mount home directories and project-specific work directories.

Everything was working smoothly until we started seeing errors during project builds. The errors initially pointed to a problem with the server’s system clock. After we reset the system clock and synced it to an external time server, most users reported no further problems and project builds worked normally again, but some users continued to experience timestamp-related write errors on files mounted from the server. It took a couple of days for us to work out

23_599496 ch17.qxd 8/30/05 6:41 PM Page 395

Providing Additional Network Services 395

that the only users continuing to have these problems were users whose systems had flaky system clocks that lost anywhere from 15 seconds to several minutes each day. After configuring these client systems to coordinate their system clocks with the NFS server’s clock, the problem went away and has not returned. Eventually, we set up a time server for the entire LAN and configured all systems to synchronize to that time server.

Selecting a Time Server Solution

If you’ve decided (or have been told) that you need a time server, your options fall into three categories: hardware, software, or both. As mentioned a moment ago, the hardware solution involves installing a high-resolution clock in your facility and then configuring client systems to synchronize their system clocks against that dedicated device. If you have a bottomless pit of money for a budget, you can install an atomic clock, such as a cesium fountain clock, to keep ridiculously accurate time. In the great majority of cases, though, hardware clocks aren’t quite so high end. Instead, these lower-end clocks are equipped with a radio or satellite receiver that monitors one of several radio or satellite broadcast frequencies specifically allocated to carrying a time signal. These time signals are broadcast by the United States Naval Observatory (USNO), the National Institute of Standards and Technology (NIST), or another official organization of the United States government. (Most countries provide similar services.) You can buy high-quality hardware clocks for $1000. In fact, depending on your needs, you can get good, high-resolution, dedicated hardware clocks for a few hundred dollars.

N OT E

For the record, USNO and NIST have multiple atomic clocks, so they keep ridiculously accurate time on your behalf and do so with your tax dollars. To learn more about the NIST timekeeping service, visit the NIST’s Time & Frequency

Division Web site at www.boulder.nist.gov/timefreq/service/its.htm.

The USNO operates a comparable site at http://tycho.usno.navy.mil/.

The most common time server solution, especially for small(ish) networks and organizations, is strictly software-based. The simplest approach is to use the date program to set your system clock to the time broadcast by another system. The kid-tested, mom-approved, and syadmin-preferred method, though, is to use the Network Time Protocol, or NTP. NTP is an open standard that defines how Internet time servers work and how clients can communicate with these time servers to maintain accurate time. How accurate? If you believe the

NTP documentation, the best precision is about 232 picoseconds, or 2.32

×

10

–10 seconds, or 0.000000000232 seconds. If you need greater precision than 232 picoseconds, get that cesium clock.

23_599496 ch17.qxd 8/30/05 6:41 PM Page 396

396 Chapter 17

N OT E

David Mills wrote the NTP implementation universally used on Linux systems. Mills has done an excellent job of documenting his work. For an overview of time synchronization issues in general, see “Executive

Summary: Computer Network Time Synchronization” at Mills’ Web site,

eecis.udel.edu/~mills/exec.html

. For more information about NTP,

the authoritative Web site is ntp.org.

NTP consists of a daemon (ntpd), a small set of utility programs (ntpq, ntpdc, ntpdate, ntptrace, tickadj, ntptime, ntiptime, ntp-kegen, and ntpdsim), and the all-important configuration file, /etc/ntp.conf. The NTP daemon is dual-purpose. It acts as a server, listening for time synchronization requests and providing the time in response, and as a client, communicating with other time servers to get the correct time and adjust the local system accordingly.

Table 17-1 briefly describes the utility programs.

Configuring the Time Server

Setting up your time server requires a small amount of preparation, implementation, and verification. You’ll need to perform the following tasks:

1. Install the NTP software.

2. Locate suitable time servers to serve as reference clocks.

3. Configure your local time server.

4. Start the NTP daemon on the local time server.

5. Make sure that the NTP daemon responds to requests.

Table 17-1 NTP Utility Programs

PROGRAM DESCRIPTION

ntpdate ntpdc

Sets the system date and time via NTP

Controls the NTP daemon, ntpd ntp-keygen ntpq ntpsim ntptime ntptrace tickadj

Generates public and private keys for use with NTP

Queries the NTP daemon

Provides NTP simulation for development and testing

Displays the time variables maintained by the Linux kernel

Traces a chain of NTP servers back to the primary source

Sets certain time variables maintained by the Linux kernel

23_599496 ch17.qxd 8/30/05 6:41 PM Page 397

Providing Additional Network Services 397

Installing the NTP software is simple. Use the rpmquery command to make sure that the ntp package is installed:

$ rpmquery ntp ntp-4.2.0.a.20040617-4

The version number you see might be slightly different. If the ntp package isn’t installed, install it using the installation tool of your choice before proceeding.

Selecting Reference Clocks

For your time server to keep and thus to serve accurate time, your local time server needs to synchronize its time against one or more master or reference clocks. NTP is a distributed application, meaning that servers and clients are dispersed, that any given client can request a time check from any given server

(modulo access restrictions), and that the application continues to function in spite of the failure or inaccessibility of one or even many of the servers. NTP is also hierarchical and organizes time servers into several strata to reduce the load on any given server or set of servers. Stratum 1 servers are referred to as

primary servers, stratum 2 servers as secondary servers, and so on. There are far more secondary servers than primary servers. Secondary servers sync to primary servers, and clients sync to secondary or tertiary servers.

NTP also provides for syncing to pool servers, a large class of publicly accessible secondary servers maintained as a public service for use by the Internetconnected computing community at large. The NTP pool time servers, organized into the subnet pool.ntp.org, use DNS round robin to assign randomly selected open access time servers to NTP clients (recall that an NTP server can also be an NTP client). The rationale for random server selection is to distribute the client load more or less equally across all servers participating in the pool and to ensure that clients are syncing to an appropriately distributed set of time servers.

The upshot for you is simple:

■■

Use one or more secondary servers as your local server’s reference clock.

■■

Use the pool servers if possible.

Accordingly, this section configures an NTP server to use the pool servers and also shows you how to configure your local time server to use explicitly selected secondary servers.

To use the pool servers, NTP is ready to run after you install the ntp package. Listing 17-1 shows ntpd’s configuration file, /etc/ntp.conf, stripped of most comments and white space.

23_599496 ch17.qxd 8/30/05 6:41 PM Page 398

398 Chapter 17

restrict default nomodify notrap noquery restrict 127.0.0.1

# --- OUR TIMESERVERS ----- server pool.ntp.org

server pool.ntp.org

server pool.ntp.org

# --- GENERAL CONFIGURATION --server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift broadcastdelay 0.008

keys /etc/ntp/keys

Listing 17-1 The default NTP configuration file.

The first two entries, beginning with the restrict directive, are, not surprisingly, restrictions on the listed IP addresses or hostnames. The first entry uses the keyword default, which means an IP address and mask of 0.0.0.0. The option flags, nomodify, notrap, and noquery, prevent the listed IP address from modifying, logging, or querying the NTP service on the server. The second rule, restrict 127.0.0.1, permits all NTP activity over the loopback interface. All activity is permitted because there are no option flags specified. To deny all activity, you would use the ignore flag, but you shouldn’t do this on the loopback interface because doing so would prevent certain NTP administrative functions (issued using the ntpdc command) from working properly.

The next three entries, beginning with the server directive, identify the time servers you want to use as reference clocks. In this case, ntpd is being configured to use the pool servers. Notice that the names are all pool.ntp.org.

Even though the names are the same, the NTP server pool is configured to use

DNS round robin, so three hostname lookups on the same name will return three different IP addresses. You can try this yourself to verify that round robin is working. Issue the command host pool.ntp.org at the command prompt and, unless your DNS client is broken, you should see output resembling the following:

$ host pool.ntp.org pool.ntp.org has address 213.219.244.16

pool.ntp.org has address 216.27.185.42

pool.ntp.org has address 62.220.226.2

pool.ntp.org has address 69.37.143.241

pool.ntp.org has address 81.169.154.44

pool.ntp.org has address 82.219.3.1

pool.ntp.org has address 139.140.181.132

pool.ntp.org has address 146.186.218.60

23_599496 ch17.qxd 8/30/05 6:41 PM Page 399

Providing Additional Network Services 399

pool.ntp.org has address 195.18.140.242

pool.ntp.org has address 203.217.30.156

pool.ntp.org has address 209.126.142.251

pool.ntp.org has address 212.23.29.225

pool.ntp.org has address 212.41.248.75

pool.ntp.org has address 212.254.25.164

pool.ntp.org has address 213.10.208.72

Normally, a hostname resolves to one and only one IP address, but when

DNS round robin behavior is enabled, a single hostname can resolve to multiple IP addresses, the purpose being to equalize the load on any single system.

The general configuration section sets broad operational policies that control ntpd’s overall behavior. The line server 127.127.1.0 instructs the NTP daemon to use the local clock (referred to as an undisciplined local clock) if no external reference clocks are accessible. You can use any address in the range

127.127.1.0 to 127.127.1.255, although the convention is to use 127.127.1.0. The line fudge 127.127.1.0 stratum 10 limits the use of the local lock by assigning it a very low place in the time server hierarchy, the intent being to prevent the local clock from interfering with other, likely more accurate time sources elsewhere on network and to enable (or, perhaps, compel) ntpd to look pretty hard for other time sources before using the undisciplined local clock. In its normal operation, ntpd listens for broadcasts from other time servers when trying to find a reference clock. If it finds a time server declaring itself at a higher stratum than 10, ntpd will use the higher-stratum clock instead of the undisciplined local clock.

The directive driftfile /var/lib/ntp/drift specifies the name of the file that stores the oscillation frequency of the local clock. NTP uses this frequency, which varies slightly over time, to make appropriate adjustments to the system time. The broadcastdelay directive sets the number of seconds

(0.008 in this case) used to calculate the network latency or delay between the local server and a remote reference server. On a LAN, values between 0.003

and 0.007 seconds are suitable, but when two servers must communicate across the Internet, it is often necessary to use a longer delay value.

The last line, keys /etc/ntp/keys, tells NTP where to find the cryptographic keys used to encrypt exchanges between client and server machines.

The purpose for encrypting the data exchange is to prevent an unauthorized reference server accidentally or deliberately sending time signals to your local time server. Another reason to use encryption is when you enable remote NTP administration and want to make sure that only properly authorized and authenticated systems can perform remote administration.

NTP version 4 (NTPv4) supports asymmetric encryption, more commonly known as public key encryption, using a method or protocol referred to as

autokey but the default configuration on Fedora Core and RHEL systems as installed doesn’t use it without some configuration work. If you wish to use

23_599496 ch17.qxd 8/30/05 6:41 PM Page 400

400 Chapter 17

server-side encryption, the following procedure creates a basic autokey setup.

You should use the following procedure on the system that will be configured as an NTP server. The next section, “Configuring an NTP Client,” describes configuring client authentication. Although advisable, it isn’t strictly necessary to set up encryption. Of course, wearing seat belts while driving is advisable, but isn’t strictly necessary.

1. Add the following lines to /etc/ntp.conf: broadcast 224.0.1.1 autokey crypto pw serverpassword keysdir /etc/ntp

Replace serverpassword with a password of your choosing.

2. Generate the key files and certificates using the following commands:

# cd /etc/ntp

# ntp-keygen -T -I -p serverpassword

Using OpenSSL version 90701f

Random seed file /root/.rnd 1024 bytes

Generating IFF parameters (512 bits)...

IFF 0 60 81 1 49 111 2 1 2 3 1 2

Generating IFF keys (512 bits)...

Confirm g^(q - b) g^b = 1 mod p: yes

Confirm g^k = g^(k + b r) g^(q - b) r: yes

Generating new iff file and link ntpkey_iff_ntpbeast.example.com- \

>ntpkey_IFFpar_ntpbeast.example.com.3318548048

Generating RSA keys (512 bits)...

RSA 0 24 112 1 11 135 3 1 4

Generating new host file and link ntpkey_host_ntpbeast.example.com- \

>ntpkey_RSAkey_ntpbeast.example.com.3318548048

Using host key as sign key

Generating certificate RSA-MD5

X509v3 Basic Constraints: critical,CA:TRUE

X509v3 Key Usage: digitalSignature,keyCertSign

X509v3 Extended Key Usage: trustRoot

Generating new cert file and link ntpkey_cert_ntpbeast.example.com->ntpkey_RSA- \

MD5cert_ntpbeast.example.com.3318548048

The output wraps (indicated by \ in the listing) because of page layout constraints.

3. If ntpd is running, restart it:

# service ntpd restart

Shutting down ntpd: [ OK ]

Starting ntpd: [ OK ]

23_599496 ch17.qxd 8/30/05 6:41 PM Page 401

Providing Additional Network Services 401

If ntpd is not running, start it:

# service ntpd start

Starting ntpd: [ OK ]

4. Use the following chkconfig commands to make sure that ntpd starts in at boot time and in all multiuser run levels:

# chkconfig --level 0123465 ntpd off

# chkconfig --level 345 ntpd on

At this point, NTP’s autokey encryption is enabled, and you’ve also made sure that NTP services will start and stop appropriately at boot time.

Configuring an NTP Client

Configuring an NTP client requires fewer steps than configuring a server does.

You select the server to use as a reference clock, start the NTP daemon, ntpd, and you’re done. The GUI-addicted can use the Date/Time Properties tool.

Either start it from the menu (Red Hat ➪ System Settings ➪ Date & Time) or type system-config-date at a command prompt. Either way, you should see the screen shown in Figure 17-1.

If NTP is already running on your system, the Date & Time tab will be disabled (grayed out). Click the Network Time Protocol tab to configure NTP. To enable NTP, place a check mark in the Enable Network Time Protocol check box. Doing so enables the NTP Servers pane, as shown in Figure 17-2.

Figure 17-1 The Date/Time Properties tool.

23_599496 ch17.qxd 8/30/05 6:41 PM Page 402

402 Chapter 17

Figure 17-2 The Network Time Protocol tab.

Fedora Core and RHEL ship with two servers configured: clock.redhat

.com

and clock2.redhat.com. To use one of these servers, select it from the

Server drop-down box and click the Add button. If you want to add a different server, type the name or IP address of the server you want to use and click the

Add button to add it to the list. Figure 17-3 shows the added servers pool

.ntp.org

and ntpbeast.example.com. To delete a server, highlight in the list and click the Delete button.

To configure advanced NTP options, click the Show advanced options arrow. These options allow you to use the system clock (the undisciplined local clock described in the previous section) as a reference clock (enabled by default) and to use NTP broadcast (disabled by default). NTP broadcast causes the NTP daemon to listen for remote servers rather than configuring clients to use a specific server.

After you have made your configuration changes, click the OK button to close the Date/Time Properties tool. If you see a dialog box indicating that the tool is connecting to an NTP server, just be patient; this dialog box is strictly informational and disappears quickly.

C A U T I O N

If you use the Date/Time Properties tool to configure your NTP

client, any hand edits you might have made to /etc/ntp.conf will be lost. The

lesson here is either not to use the graphical tool or to make a backup copy of

/etc/ntp.conf

before

using the GUI tool.

23_599496 ch17.qxd 8/30/05 6:41 PM Page 403

Providing Additional Network Services 403

Figure 17-3 Adding NTP servers.

One reason you might not want to use the Date/Time Properties tool is that you cannot perform advanced customization of NTP. Moreover, if you want to use the pool servers and provide the name pool.ntp.org, the tool replaces that name with the first IP address that resolves to the hostname. The problem is that the Date/Time Properties tool does not take into account that pool.ntp.org

uses DNS round robin. As a result, if you choose to use the NTP server pool, you will have to edit /etc/ntp.conf by hand. It might be simpler and less aggravating to edit the configuration file directly. The additional configuration steps described next require you to edit /etc/ntp.conf directly.

If you configured your NTP server to use autokey encryption, you will also need to configure any NTP clients you have to use autokey encryption. The following procedure walks you through doing so.

1. Add the following lines to /etc/ntp.conf on the client: crypto pw clientpassword keysdir /etc/ntp server timeserver autokey

Replace clientpassword with the password you want to use on the client. Replace timeserver with the name or IP address of the system you configured as the server in the previous section.

23_599496 ch17.qxd 8/30/05 6:41 PM Page 404

404 Chapter 17

2. Generate the client keys and certificate:

# cd /etc/ntp

# ntp-keygen -H -p clientpassword

We don’t show the output of this command to conserve space.

3. Import the key created in the section on server configuration using some sort of encrypted mechanism, such as sftp or scp. The following example uses scp:

# cd /etc/ntp

# scp user@timeserver:/etc/ntp/ ntpkey_IFFkey_timeserver.3318548048 .

# ln -s ntpkey_IFFkey_timeserver.3318548048 ntpkey_iffkey_timeserver

Replace user with the name of a user that has scp privileges on the machine you are using as the time server. Under normal circumstances, this can be any user with a login account on the time server.

4. If ntpd is running, restart it:

# service ntpd restart

Shutting down ntpd: [ OK ]

Starting ntpd: [ OK ]

If ntpd is not running, start it:

# service ntpd start

Starting ntpd: [ OK ]

5. Execute the command ntpq -p to make sure that the NTP client can communicate with the designed server. The output should resemble the following:

# ntpq -p ntpbeast.example.com

remote refid st t when poll reach delay offset jitter

============================================================================== ntpbeast.example 192.168.0.1 1 u 209 1024 377 37.200 7.199 0.226

Replace ntpbeast.example.com in the command with the name (or

IP address) of the time server you are using.

As a final test, you can use the ntpstat command to query the time server from the host machine to ensure that you can retrieve the time. The output will show the server to which ntpd synchronizes, the clock’s precision, and the interval on which ntpd resynchronizes:

# ntpstat synchronised to NTP server (192.168.0.1) at stratum 3 time correct to within 70 ms polling server every 128 s

23_599496 ch17.qxd 8/30/05 6:41 PM Page 405

Providing Additional Network Services 405

After ntpd has been running for a while, you can grep the system log for

NTP-related log entries to see ntpd’s activity. The following listing briefly illustrates what you might see:

# grep ntpd /var/log/messages

Feb 28 07:56:56 luther ntpd[3549]: ntpd [email protected] Mon Oct 11 09:10:20

EDT2004 (1)

Feb 28 07:56:56 luther ntpd: ntpd startup succeeded

Feb 28 07:56:56 luther ntpd[3549]: precision = 1.000 usec

Feb 28 07:56:56 luther ntpd[3549]: Listening on interface wildcard, 0.0.0.0#123

Feb 28 07:56:56 luther ntpd[3549]: Listening on interface wildcard, ::#123

Feb 28 07:56:56 luther ntpd[3549]: Listening on interface lo, 127.0.0.1#123

Feb 28 07:56:56 luther ntpd[3549]: Listening on interface eth0, 192.168.0.4#123

Feb 28 07:56:56 luther ntpd[3549]: kernel time sync status 0040

Feb 28 07:57:16 luther ntpd[3549]: frequency initialized -67.149 PPM from \

/var/lib/ntp/drift

Feb 28 07:58:23 luther ntpd[3549]: synchronized to 192.168.0.1, stratum 2

Feb 28 07:58:22 luther ntpd[3549]: time reset -0.461319 s

Feb 28 07:58:22 luther ntpd[3549]: kernel time sync disabled 0041

Feb 28 08:01:35 luther ntpd[3549]: synchronized to 192.168.0.1, stratum 2

Feb 28 08:09:04 luther ntpd[3549]: kernel time sync enabled 0001

One line of output wraps due to page layout constraints. In this log snippet, you can see ntpd’s startup, a report of the interfaces on which it is listening, and, in the final six lines, the synchronization activity. For example, the line that reads frequency initialized -67.149 PPM from /var/lib/ntp/drift indicates that ntpd read the drift file to set the clock frequency. The following lines shows ntpd synchronizing to the clock at 192.168.0.1, subtracting 0.461319 seconds from the system clock, and then reconfirming the synchronization about three minutes later. This type of activity will continue throughout the day.

Playing Nicely and Wisely with NTP

Playing nicely with NTP means that you should adhere to the recommended guidelines for selecting an external time server as a reference clock. The rule of thumb is that if your network has less than 100 systems, you should use a stratum 2 server rather than a stratum 1 server. This guideline exists to limit the ever-increasing load on the stratum 1 servers. Rather than syncing 100 client systems to an external reference server, the preferred practice is to set up a time server inside your firewall (you do have firewall, right?), synchronize it with an external reference clock, and then synchronize your LAN clients with your internal time server. If you have a large network, that is, one with more than

100 NTP clients, it might be prudent to invest in a dedicated hardware clock and use that as your time server. Such a measure would reduce your reliance on an external resource and limit the load placed on public time servers. If you

23_599496 ch17.qxd 8/30/05 6:41 PM Page 406

406 Chapter 17

wanted to be a really good netizen, you could even make your hardware time server part of the NTP public access server pool — see the NTP Web site at http://www.ntp.org

for all the particulars.

Playing wisely with NTP means choosing at least three external reference clocks (we usually select four) and making sure that the reference clocks are dispersed geographically and in terms of network connections. The geographic dispersal is easy enough to achieve by selecting one from each compass point that you don’t occupy. For example, if you are located in Pittsburgh, Pennsylvania, which is situated in the northeastern United States, choose reference clocks from the southeast, southwest, and northwest regions of the United States.

Network dispersal is somewhat more difficult to achieve because you want to try to locate reference clocks that use different Internet backbones or backbone providers. The theory is that if one backbone or a segment of one provider’s backbone fails (because the fiber-optic cable is cut by a backhoe, say), access to that time server will be impaired. NTP is engineered to select an alternative server, but if all your servers use that same severed backbone, you’re hosed. So, for example, if your primary network access uses UUNet, good geographic dispersal requires finding reference clocks that use, say,

Sprint, MCI, or AT&T. As a practical matter, you can use the traceroute command to examine the network paths packets follow to reach a given time server and then compare those paths, confirming that there are as few routing points in common between each time server as possible. It is a tedious undertaking, but if your network and the services it provides rely on accurate, consistent time services, it is well worth the effort.

Providing a Caching Proxy Server

What is a caching proxy server and why should you use one? A caching proxy

server is software (and potentially hardware) that stores (caches) frequently requested Internet objects such as Web pages, Java scripts, and downloaded files closer (in network terms) to the clients that request those objects. When a new request is made for a cached object, the proxy server provides the object from its cache instead of allowing the request to go to the source. That is, the local cache serves the requested object as a proxy or substitute for the actual server. The motivation for using a caching proxy server is two-fold: to provide accelerated Web browsing by reducing access time for frequently requested objects and to reduce bandwidth consumption by caching popular data locally, that is, on a server that exists between the requesting client and the

Internet. The HTTP acceleration feature speeds up Web browsing because cached pages need not be re-retrieved unless the original page has been updated since it was last cached.

23_599496 ch17.qxd 8/30/05 6:41 PM Page 407

Providing Additional Network Services 407

N OT E

Caching proxy servers are sometimes used to create content filters to block attempts to access certain sites or content. Quite aside from the

Orwellian aspect of content filters, using a proxy server as a content filter misuses the proxy server. Limiting access to certain sites is easier to accomplish by blocking packets destined for banned sites. Moreover, because proxy servers utilize system resources, especially RAM, for caching data, the resources allocated to content filters are better applied to caching and retrieving data.

Nevertheless using a proxy as a single point through which to apply and simplify site-blocking is quite common. Such site-blocking proxy servers squander resources only on the system on which they’re running, which can be an efficient approach if your site uses a single HTTP proxy for hundreds of desktops.

The Web proxy discussed in this chapter is called Squid. There is no intrinsic connection between the name Squid and the function of the proxy server.

It’s just a name that stuck. The Squid FAQ explains the name this way:

“Harris’ Lament says, ‘All the good [names] are taken.’ We needed to distinguish this new version from the Harvest cache software. Squid was the code name for initial development, and it stuck (Squid FAQ, squid-cache.org

/Doc/FAQ/FAQ-1.html#ss1.3

).” Squid provides the basic caching and proxy functions just described. It also caches DNS lookups, to speed up subsequent DNS queries, performs nonblocking DNS queries, and implements neg-

ative caching, which means that Squid remembers when a request was made for an object (or for a DNS resource) that doesn’t exist and doesn’t try to retrieve it or find the nonexistent object in its cache. In addition to these proxy and caching services, Squid also has full SSL support, includes extensive access control, and features a rich logging system that you can use to fine-tune the caching behavior.

Finally, Squid can work as a transparent proxy. An “ordinary” (opaque?) proxy requires Web clients to specify the hostname and port of the proxy, which then forwards requests to the requested server. This has obvious disadvantages, the biggest one being that you have to configure all the Web clients to use the proxy. With transparent proxying, Web clients think they are communicating with the requested server when in fact they are communicating with the proxy. A transparent proxy still intercepts requests, but Web clients neither notice nor care.

Squid is included in both Fedora Core and RHEL, but depending on the type of installation you performed, it might not be installed. The following rpmquery command will show you if Squid is installed (you only need the

Squid package):

$ rpmquery squid squid-2.5.STABlE8-1.FC3.1

23_599496 ch17.qxd 8/30/05 6:41 PM Page 408

408 Chapter 17

The version number might be slightly different by the time you read this text. If Squid is not installed, you’ll obviously need to install it before proceeding. The configuration process includes the following steps:

1. Verifying the kernel configuration

2. Configuring Squid

3. Modifying the Netfilter configuration

4. Starting Squid

5. Testing the configuration

The following subsections provide the details for each of these steps.

Verifying the Kernel Configuration

This section is titled “Verifying the Kernel Configuration” because the kernel features you need, such as IP forwarding and Netfilter (iptables) support, are already in place on Fedora Core and RHEL systems. The most you should need to do is load a kernel module or enable IP forwarding. Nonetheless, knowing the kernel modifications that have to be made is useful if you decide at some point to discard the stock Fedora or RHEL kernel and roll your own.

The most important kernel feature you need is Netfilter support because

Netfilter will handle the actual proxying of browser requests. Specifically, you need to enable Netfilter and the modules that support:

■■

■■

Connection tracking

IP tables

■■

■■

Full NAT (Network Address Translation)

Support for the REDIRECT target

For completeness’ sake, you need support for the /proc file system and sysctl support for manipulating tunable runtime kernel options. These two options are pretty much de jure these days and they are definitely present in the stock Fedora and RHEL kernels.

The first thing to do is enable IP forwarding on the system that will run

Squid. IP forwarding enables the kernel to send, or forward, packets that arrive on one network interface to another, an essential capability for proxying. The following sysctl command will show you if IP forwarding is enabled:

# sysctl -n net.ipv4.ip_forward

1

23_599496 ch17.qxd 8/30/05 6:41 PM Page 409

Providing Additional Network Services 409

This command queries the kernel to see whether IP forwarding (actually

IPv4 forwarding) is enabled. If the displayed value is 1, IP forwarding is enabled. If the output is 0, IP forwarding is not enabled and you need to enable it using the following command:

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

If you need to enable IP forwarding and you want to start Squid automatically at boot time, edit the file /etc/sysctl.conf, changing the line that reads net.ipv4.ip_forward = 0 so that it reads net.ipv4.ip_forward = 1

This will enable IP forwarding at boot time. Now that IP forwarding is turned on, you need to configure Squid.

Configuring Squid

The Squid configuration file on Fedora Core and RHEL systems is

/etc/squid/squid.conf

. The initialization script that controls Squid is

/etc/rc.d/init.d/squid

, which reads default values from /etc

/sysconfig/squid

. For your initial experimentation with Squid, only modify the Squid configuration file. It would easily consume several chapters to describe Squid’s configuration and tuning adequately, so to get you up and running quickly, this section focuses on the bare minimum. You definitely want to spend some quality time with the configuration file’s comments, because they are complete, understandable, and do a fine job of telling you more than you probably want to know about Squid’s care and feeding. Table 17-2 lists the configuration settings with which you concern yourself in the short term.

Table 17-2 Key Squid Configuration Parameters

PARAMETER DEFAULT DESCRIPTION

VALUE

cache_effective_group cache_effective_user squid squid

Identifies the group Squid runs as

Identifies the user Squid runs as httpd_accel_host

None Defines the hostname of the real

HTTP server (if using acceleration)

(continued)

23_599496 ch17.qxd 8/30/05 6:41 PM Page 410

410 Chapter 17

Table 17-2 (continued)

PARAMETER

httpd_accel_with_proxy

DEFAULT DESCRIPTION

VALUE

off

Controls whether Squid runs as both an accelerator and a proxy httpd_accel_port httpd_accel_uses_ host_header httpd_access

80 off deny all

Defines the port number of the real

HTTP server (if using acceleration)

Enables Squid to function as a transparent proxy

Defines who can access the Squid server

As Table 17-2 shows, cache_effective_user and cache_effective_ group identify the user ID (UID) and group ID (GID), respectively, under which Squid runs. The default values, squid, are the defaults configured in the Squid package shipped in Fedora Core and RHEL. You needn’t change them.

httpd_accel_with_proxy

, which defaults to off, controls whether

Squid runs as a cache (or accelerator) and proxy or just as proxy. When set to off

, Squid functions only as a proxy. If set to on, Squid works as both a cache

and a proxy. If you are using Squid’s caching functionality, you’ll need to set httpd_accel_port to 80 and use httpd_accel_host to define the name the host running Squid. As it happens, the default port number of httpd_accel_port is 80, so you shouldn’t need to change this.

httpd_accel_host lacks a default value, so you’ll need to change this value. If you want a transparent proxy server, set httpd_accel_uses_ host_header to on. The default value, off, means that clients have to configure their Web clients to use a proxy server, which can be quite inconvenient for users and a pain for administrators to manage, especially across a LAN that is geographically dispersed or if some users are, shall we say, technically challenged.

The final value to configure is httpd_access, which controls who can access the Squid server and, therefore, who can surf the Web through the proxy. The default configuration is deny all, which prevents any user from accessing the proxy. As you can imagine, this policy is draconian. For experimentation purposes, set it to allow all, which permits all users to access the server. Yes, this is just as extreme as deny all, but the idea is to enable people to surf the Web. Make sure to learn how to use Squid’s access control list (ACL) features to fine-tune the access policy.

23_599496 ch17.qxd 8/30/05 6:41 PM Page 411

Providing Additional Network Services 411

The following listing shows the changes to make to /etc/squid

/squid.conf

: cache_effective_user squid cache_effective_group squid httpd_accel_host squid.example.com httpd_accel_with_proxy on httpd_accel_port 80 httpd_accel_uses_host_header on httpd_access allow all

Replace squid.example.com with the name of the system on which you are running Squid. To save needing to do so later, initialize Squid’s cache using the command squid -z:

# squid -z

2005/03/02 22:54:59| Creating Swap Directories

Modifying Netfilter

Technically, modifying your netfilter firewall rules is an optional step. If you aren’t using netfilter to maintain a firewall or to provide your LAN access to the Internet, you don’t need to do anything with netfilter in order to get Squid to work. Presumably, however, you’re running netfilter because you don’t want Bad Things To Happen. If you don’t fear crackers and other bad guys and so aren’t running a netfilter firewall, skip this section.

If you’re still reading, execute the following command:

# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 \

-j REDIRECT --to-port 3128

Chapter 34 describes netfilter in detail, so don’t feel as if you need to understand what this rule means. Simply stated, this rule sends HTTP requests to

Squid, which services the request instead of the destination host (the external

Web site). For the curious, an explanation of the specifics: This command updates the NAT or network address translation table (-t nat), appending a rule to the prerouting chain (-A PREROUTING). IP packets handled by the prerouting chain are modified as soon as they arrive and are not otherwise processed. The rule applies to TCP protocol packets (-p tcp) arriving on the network interface eth0 (-i eth0) that are destined for port 80 (--dport 80). The modification that occurs is that packets going to port 80 are redirected (-j REDIRECT) to port

3128 (--to-port 3128), which is the port on which Squid listens.

23_599496 ch17.qxd 8/30/05 6:42 PM Page 412

412 Chapter 17

Use the command iptables -t nat -L to verify that the rule is in effect:

# sudo /sbin/iptables -L -t nat

Chain PREROUTING (policy ACCEPT) target prot opt source destination

REDIRECT tcp -- anywhere anywhere tcp dpt:http redir\ ports 3128

The output wraps, as indicated by the \, due to page layout constraints. As you can see, the PREROUTING chain has been modified to redirect HTTP packets to port 3128. Now you’re ready to start Squid.

Starting Squid

To start Squid, use your old friend service:

# service squid start

Starting squid: . [ OK ]

If you wish, you can use the chkconfig command to set Squid to start and stop automatically:

# chkconfig --level 0123456 squid off

# chkconfig --level 345 squid on

The first command disables Squid in all run levels. The second command causes Squid to start when the system enters run levels 3, 4, or 5.

Testing the Configuration

To test the configuration, first configure your Web browser to use the proxy you’ve just set up. If you use Mozilla Firefox, select Edit ➪ Preferences to open

Mozilla’s Preferences dialog box. (See Figure 17-4.)

On the General tab, click Connection Settings to open the Connection Settings dialog box. Click the Manual proxy configuration radio button and type the hostname or IP address of the proxy server in the HTTP Proxy text box.

Type 3128 in the accompanying Port text box. The completed settings might resemble Figure 17-5.

Click OK to close the Connection Settings dialog box and OK again to save your changes and close the Preferences dialog box. Now, you should be able to type in a URL as you normally would and see the resulting page.

Nothin’ to it, right?

23_599496 ch17.qxd 8/30/05 6:42 PM Page 413

Providing Additional Network Services 413

Figure 17-4 Firefox’s Preferences dialog box.

Figure 17-5 Firefox’s Connection Settings dialog box.

23_599496 ch17.qxd 8/30/05 6:42 PM Page 414

414 Chapter 17

Summary

For LANs that need to keep accurate time or if having 50 LAN clients each with a slightly different idea of what time it is offends your sense of order, the

Network Time Protocol, NTP, is for you. NTP is easy to configure, brain-dead simple to use, and remarkably accurate and reliable. Perhaps the hardest part is deciding which remote time servers to use as reference clocks. Another useful, albeit infrequently requested, service is a caching proxy server. If you have limited bandwidth, Squid’s caching capabilities can reduce bandwidth consumption, especially for sites that are more static than dynamic. Squid can also be used (or misused, perhaps) to limit who can access the Web.

24_599496 ch18.qxd 8/30/05 6:46 PM Page 415

C H A P T E R

18

Optimizing

Network Services

IN THIS CHAPTER

■■

■■

■■

■■

■■

Getting the X Window System

Optimizing NFS

Optimizing NIS

Optimizing Samba Networking

Getting More from a Database Server

This chapter offers some tips for optimizing the performance of network services running on Fedora Core and RHEL systems. For example, X Window system desktops run faster when you reduce the amount of eye candy because giving up eye-popping graphics results in less bandwidth consumption when you run X applications across a network. Print queues can be configured to send large print jobs to high-speed printers. NFS disk farms can be designed to spread the load across multiple disks. The information in this chapter is only a starting point, however, and does not address larger issues of performance tuning, such as establishing a baseline, identifying performance goals, and ongoing performance monitoring. Rather, this chapter concerns itself with specific steps you can take to address known causes of slow performance.

Chapter 32 goes into more of the theory behind performance tuning. As you read the tips and ideas in this chapter, bear in mind that you always have to balance your efforts along three axes: performance, usability, and security.

Indeed, when it comes to server or application tuning, the pithy epigram might be, “Convenient, secure, fast. Pick any two.”

415

24_599496 ch18.qxd 8/30/05 6:46 PM Page 416

416 Chapter 18

Optimizing the X Window System

Optimizing the X Window system is not easy. The core X protocol, despite what its detractors say, is actually pretty well tuned. Of course, as Keith

Packard and Jim Gettys point out in their Usenix paper, “X Window System Network Performance,” (see http://keithp.com/~keithp/talks

/usenix2003/html/net.html

), protocol improvements are under way that should make X more efficient at the wire level. Nonetheless, the gardenvariety system administrator usually lacks the time, not to mention the desire, to hack X at the level described in Packard’s and Gettys’ paper.

What exactly does “performance” mean vis-à-vis the X Window system?

Depending on whom you ask, the phrase “X performance” might mean one or more of:

■■

Drawing and refresh speed, which refers to the time taken to render complex graphics (including 3-D graphics) on-screen

■■

■■

■■

Startup and initialization time, which refers to how long it takes the X

Window System as a whole and, more pertinently, X applications to start and become ready to accept user input

Application responsiveness, which refers to the user’s perception of how quickly or slowly an application responds to mouse and keyboard input

Client-server communication speed, which refers to the round-trip time between an X client and an X server

For the most part, this section addresses the first three measurements of performance. The fourth metric, client-server communication speed, is difficult to address without either rewriting the X application in question or making significant changes in your network infrastructure. There are, naturally, some steps you can take to improve the performance of X or, more specifically, the

Xorg system running on Fedora Core or RHEL.

■■

The biggest improvement comes from beefing up the hardware on which you are running X. There is simply no way around the fact that a faster CPU, a faster GPU (graphics processing unit) that supports hardware acceleration, more RAM, and more video RAM do more than anything else to speed up X. Naturally, hardware upgrades are not always an option, but they are the best option you have.

■■

Use a lightweight window manager. The eye candy and functionality provided by desktop environments such as GNOME and KDE carry a heavy price tag in terms of overall system performance. If, like us, you use X mostly as a platform for running xterms, a Web browser, and other graphical applications, you might not even miss the integration between applications that the desktop environments provide.

24_599496 ch18.qxd 8/30/05 6:46 PM Page 417

Optimizing Network Services 417

■■

Consider reducing the color depth at which you run X.org. Obviously, if you need millions of colors for heavy-duty image processing or video editing, 16-bit color will result in poor-quality images. An awful lot of the computing that takes place on a Fedora Core and RHEL systems is text processing, programming, and email. Twenty-four-bit and 32-bit color are computationally intensive; 16-bit color is much less demanding.

■■

Reduce the amount of eye candy on your desktop. A solid-color background is much less memory-intensive than a full-color wallpaper image. Transparent backgrounds in terminal emulators are cool but usually impose overhead on the windowing system to keep the background properly rendered and up to date. Shaped windows and borders are aesthetically pleasing but somewhat expensive in terms of resources.

■■

Run a local font server. Doing so makes the fonts you want available locally, so they do not have to be sent across the network. Similarly, you can free up memory and speed up the server’s font handling by getting rid of fonts (that is, not loading them in /etc/X11/xorg.conf) that you do not use. For example, on a laptop computer, you can probably disable the 100-dpi fonts because you cannot run the X server at a high enough resolution to get any benefit from the better-quality fonts. Similarly, if you don’t use the CID fonts and Cyrillic fonts, don’t load them.

■■

Actively seek out lightweight X-based applications. We no longer use

Mozilla, for example, because we have found that Firefox, the browseronly replacement for Mozilla, provides everything we need in a Web browser.

■■

Make sure that the X server is up-to-date. The X.org project is working to separate drivers from the rest of the system, which will enable you to download and install an updated driver for your card without having to refresh the entire X.org installation. Drivers sometimes improve dramatically from release to release, so stay informed about the driver for you card.

■■

Unload modules you do not use. The standard X.org installation, for example, loads the RECORD and XTRAP extensions. Edit /etc/X11

/xorg.conf

and comment out the lines that read:

Load “record”

Load “xtrap”

■■

Granted, these are only two modules with negligible memory and CPU impact, but every little bit helps.

If you are motivated enough, consider recompiling X or at least the X applications you use most often for your specific system.

24_599496 ch18.qxd 8/30/05 6:46 PM Page 418

418 Chapter 18

■■

Run X at a lower nice value, thereby increasing its priority relative to other processes. By increasing X’s priority over other processes, you get a more responsive system. One way to do this is to start X using the command nice -n -10 X :0. You need root access to use the nice command to increase a process’s priority. If you run X using one of the display managers (xdm, gdm, or kdm), modify the Xservers file

(/etc/X11/xdm/Xservers

). Find the line that resembles the following:

:0 local /usr/X11R6/bin/X

Change the line so that it looks like the following, and then exit and restart X:

:0 local nice -n -10 /usr/X11R6/bin/X

T I P

Counterintuitively, lowering a process’s nice value increases its priority relative to other processes. Think of it this way: the lower a process’s nice value, the less nice it is to other processes.

■■

If you run X for long periods of time, memory gets tied up as cache.

Occasionally restarting X refreshes potentially stale caches and also frees up memory that might have been lost to leaks.

Don’t try all of these suggestions at once because doing so will make it difficult, if not impossible, to pinpoint the change or changes that had the most affect. Rather, make one change and then test and record the result. Add each change incrementally, making sure to test and record the result, if any. At the end of the process, compare the results of your efforts to the pretuning performance to obtain a measure of how things have changed. The principle involved is to have a known baseline against which to measure the impact a given tuning measure makes.

Optimizing NFS

The subject of performance tuning deserves its own book, and, indeed numerous books exist on the general topic of performance tuning. Nevertheless, we can provide some general guidelines for improving NFS’s performance and offer a few tips for maintaining a responsive NFS environment. The suggestions are far from exhaustive, and you must also take into account the needs and requirements of your network. To make the point that we make throughout this chapter, test your assumptions and tuning methods against baseline performance metrics taken from an untuned system. Comparing pre- with posttuning performance is the only way to ensure that your efforts make a positive difference.

24_599496 ch18.qxd 8/30/05 6:46 PM Page 419

Optimizing Network Services 419

NFS is sensitive to network performance, more specifically to network congestion and bandwidth problems. As a general rule, if NFS performance starts to degrade, you can be reasonably certain that heavy network traffic is the culprit. However, NFS traffic, especially at the server, tends to be “bursty,” characterized by periods of relative quiescence broken up with sharp upward spikes in activity. As a result, tuning efforts need to take into account such uneven access patterns to ensure optimal performance under load and during less strenuous periods.

Here are a few general suggestions you can apply to improve a system’s performance overall and the performance of an NFS server in particular. While most of these tips address a server system, they also have beneficial effects on a client system. Bear in mind that the impact of any changes will be more noticeable in large, heavily used NFS installations than in small installations where the total number of clients and servers is counted in single digits.

■■

Using a journaling file system offers two clear advantages for an NFS server. First, in the event of a crash, journaling file systems recover much more quickly than nonjournaling file systems. If you value your data, use a journaling file system on an NFS server. Second, journaling file systems need only update the journal to maintain data integrity, so an NFS server running a journaling file system “completes” I/O much faster because only the journal needs to be updated. After updating the journal, the server can safely issue an I/O completed reply to the clients. Meanwhile, the actual file system update occurs when the server is less busy.

■■

Spread NFS exported file systems across multiple disks and, if possible, multiple disk controllers. The purpose of this strategy is to avoid disk

hot spots, which occur when I/O operations concentrate on a single disk or a single area of a disk. Similarly, distribute disks containing NFS exported file systems across multiple disk controllers. This measure reduces the amount of I/O traffic on any single controller, which improves the overall performance of the I/O subsystem.

■■

Replace IDE disks with serial ATA disks. If you have the budget for it, use FibreChannel disk arrays. FibreChannel, although markedly more expensive than IDE, serial ATA, and even SCSI, offers even faster performance. However, in small shops and for small servers, using

FibreChannel is akin to killing gnats with a howitzer.

■■

If your NFS server is using RAID, use RAID 1/0 to maximize write speed and to provide redundancy in the event of a disk crash. RAID 5 seems compelling at first because it ensures good read speeds, which is important for NFS clients, but RAID 5’s write performance is lackluster, and good write speeds are important for NFS servers. Write performance is

24_599496 ch18.qxd 8/30/05 6:46 PM Page 420

420 Chapter 18

critical because Linux’s NFS implementation now defaults to synchronous mode (and has since about kernel version 2.4.7), meaning that NFS operations do not complete until the data is actually synced to disk.

C R O S S - R E F E R E N C E

For more information about configuring NFS, particularly how to disable synchronous I/O, see Chapter 12.

■■

■■

■■

■■

■■

Consider replacing 10-Mbit Ethernet cards with 100-Mbit Ethernet cards throughout the network. Although only slightly more expensive than their 10-Mbit cousins, 100-Mbit cards offer considerably more throughput per dollar. The faster cards result in better network performance across the board, not just for NFS. Of course, to reap the benefits of 100-

Mbit cards, they need to be used on clients and servers, and the gateways, routers, and switches must be capable of handling 100-MB speeds.

In situations in which performance is the paramount concern, Gigabit

Ethernet (1000 Mbit) is available, although expensive. Other highperformance network options, such as Myrinet and SONET (Synchronous Optical Networking), exist as well but are typically used as cluster interconnect solutions rather than as the underlying protocols for general purpose LANS or intranets.

Replace hubs with switches. Network hubs, while less expensive than switches, route all network traffic across the same data channel. During periods of heavy activity, this single data channel can easily become saturated. Switches, on the other hand, transmit network packets across multiple data channels, reducing congestion and packet collisions and resulting in faster overall throughput.

If necessary, dedicate one or more servers specifically to NFS work.

CPU or memory-intensive processes, such as Web, database, and compute servers, can starve an NFS server for needed CPU cycles or memory pages.

An increasingly inexpensive alternative is adding a NAS, or networkattached storage, device to the network. A NAS device is effectively a large box of disks attached to the network by assigning the NAS its own IP address. NAS devices speed up file access because file I/O is moved off the departmental or workgroup server and because NAS devices usually have special-purpose high-speed I/O chips. Parking

NFS exports on a NAS can improve NFS performance significantly.

■■

A common NFS optimization is to minimize the number of writeintensive NFS exports. Automounted homes are useful, expected,

24_599496 ch18.qxd 8/30/05 6:47 PM Page 421

Optimizing Network Services 421

■■ and therefore hard to eliminate, but for other exports it might be optimal to stop sharing heavily used project directories and require people to access the remote system that houses them via SSH or Telnet to minimize network traffic.

In extreme cases, resegmenting the network might be the answer to

NFS performance problems. Resegmenting the network to isolate NFS traffic on its own network segment reduces network saturation and congestion and allocates dedicated bandwidth to NFS traffic.

A good place to start evaluating NFS performance is to use the nfsstat command, which prints the NFS statistics maintained by the kernel. You can use nfsstat output to establish baseline performance metrics; to measure the effects, if any, of configuration changes; and to diagnose specific NFS performance problems. nfsstat’s general syntax is: nfsstat [-acnrsz] [-o facility]

Table 18-1 explains nfsstat’s options.

By default, nfsstat displays statistics for both NFS and the underlying

RPC service. Use the -n option to display on NFS statistics or the -r option to print only RPC statistics. Likewise, nfsstat displays client and server statistics unless you specify -c for client statistics (which makes little sense because the client does not maintain statistics in the current implementation) or -s to for server statistics. The following listing displays NFS statistics only for an

NFS server:

$ /usr/sbin/nfstat -n -s

Server nfs v2: null getattr setattr root lookup readlink

0 0% 0 0% 0 0% 0 0% 0 0% 0 0% read wrcache write create remove rename

0 0% 0 0% 0 0% 0 0% 0 0% 0 0% link symlink mkdir rmdir readdir fsstat

0 0% 0 0% 0 0% 0 0% 0 0% 0 0%

Server nfs v3: null getattr setattr lookup access readlink

0 0% 10861 43% 297 1% 6305 25% 95 0% 0 0% read write create mkdir symlink mknod

4151 16% 912 3% 621 2% 0 0% 0 0% 0 0% remove rmdir rename link readdir readdirplus

1236 4% 0 0% 0 0% 615 2% 0 0% 0 0% fsstat fsinfo pathconf commit

9 0% 9 0% 0 0% 91 0%

24_599496 ch18.qxd 8/30/05 6:47 PM Page 422

422 Chapter 18

Table 18-1 nfsstat Command Options

OPTION DESCRIPTION

-a

Prints all (NFS, RPC, and network) statistics for NFS clients and servers

-c

-n

-r

-s

Prints NFS client statistics

Prints only NFS statistics

Prints only RPC statistics

Prints only NFS server statistics

-z

Resets the kernel’s NFS statistics counters to zero (not currently supported)

-o facility

Displays statistics for the specified facility

Notice that the statistics for NFS version 2 are all zeroes. This is so because this particular server is running NFS version 3. The displayed information shows the type of operation performed (arranged by RPC call), such as getattr

, read, or write, the number of such operations performed, and the distribution of each operation. For example, 10,861 getattr operations have been performed, which represents 43 percent of all NFS server operations.

The facility argument for the -o option enables you to fine-tune the type of information nfsstat displays. facility can have one of the following values:

■■

■■

■■

fh

— Displays utilization data on the server’s file handle cache, including the total number of lookups and the number of cache hits and misses

net

— Shows network layer statistics, such as the number of received packets or number of TCP connections

nfs

— Displays NFS protocol statistics categorized by RPC call

■■

rc

— Prints utilization data on the server’s request reply cache, including the total number of lookups and the number of cache hits and misses

■■

rpc

— Prints general RPC information

For additional information about improving the performance of NFS, see the Linux NFS-HOWTO on the NFS Web page at http://nfs.source

forge.net/nfs-howto/

. The NFS-HOWTO dedicates an entire section to performance tuning the Linux NFS implementation. Another valuable source of general performance tuning information, not only for NFS but also for all varieties of Linux issues, is the Linux Performance Tuning Web site at http://linuxperf.nl.linux.org/

.

24_599496 ch18.qxd 8/30/05 6:47 PM Page 423

Optimizing Network Services 423

Optimizing NIS

How do you know when you have an NIS performance problem? If you issue a command that touches NIS-maintained information (such as yppasswd) that takes longer than you expect to complete, NIS might have problems.

Other symptoms of NIS stumbling include error messages with phrases like

“Busy try again later” or “Not responding.” Another sign of NIS problems is slow login times or apparent system hangs when you are logged in.

Frankly, with NIS+ for Linux no longer in development and traditional NIS in maintenance mode, not much can be done to improve NIS’s performance.

Nevertheless, the following tips should help you avoid common problems with NIS’s speed.

■■

Make sure that your problem is with NIS and not with NFS-mounted exports. This is especially true when you are using automounted home directories, because problems that seem to be caused by NIS (such as slow login times) might actually be the result of problems mounting an exported home directory from a busy NFS server.

■■

Do not use recursive netgroups. A recursive netgroup is an NIS group defined in terms of other NIS groups. Recursive groups are quite convenient for administrators because they limit the maintenance burden, but resolving group names is time-consuming and thus slows down the server.

In large NIS installations, set up slave servers to reduce the load on the master server. Slave servers work best in situations in which the NIS maps are relatively static.

■■

Partition big NIS domains into smaller so-called subdomains. The idea here is to reduce the number of authoritative maps served by any single master server. This reduces the overall load on any one NIS server and minimizes the size of NIS maps that have to be pushed around.

As awful as doing so may sound, the best way to optimize NIS’s performance might be to replace it with something else, such as LDAP.

Optimizing Samba Networking

Probably the most important consideration for optimizing Samba performance is file transfer speed between the Samba server and clients. There are options that can be set in the /etc/samba/smb.conf file that will increase file transfer performance between the client and server. You can try them to determine if your performance increases after implementing them.

24_599496 ch18.qxd 8/30/05 6:47 PM Page 424

424 Chapter 18

■■

socket options

— These are controls on the networking layer of the operating system that enable tuning of the connection. For a complete list of options, refer to the smb.conf man page. A good choice for tuning your local network is to use socket options = IPTOS_LOWDELAY

TCP_NODELAY

.

■■

dns proxy

— This option should be set to no unless your Samba server is acting as a WINS server. Setting this option to no prevents the server from doing unnecessary name lookups and increases system performance.

■■

■■

debug level

— This option should be set to 2 or less. Setting the debug level higher than 2 causes the server to flush the log file after each operation, a time-consuming process indeed.

level2 oplocks

— This option provides for caching of downloaded files on the client machine. Setting this option to true can increase system performance.

Getting More from a Database Server

Like the topic of performance tuning in general, database performance tuning would also require book-length treatment for fuller coverage. The following tips and references will get you started:

■■

Use a different scheduler

— The Linux kernel supports four different process schedulers, each of which excel at handling certain types of workloads. Although you will want to test the results, the preferred and recommended scheduler to use for database systems is the so-called cfq scheduler. To use it, pass the following boot parameter to the kernel at boot time: elevator=cfq

■■

Use raw disk partitions

— Oracle supports storing data on raw or unformatted disk partitions. The advantage of using raw partitions is that Oracle’s I/O processes bypass the kernel’s data caches and buffers, significantly speeding up disk I/O.

■■

Add memory

— Up to the limit supported by the underlying RDBMS and the kernel, database servers almost always benefit from adding

RAM and/or swap.

24_599496 ch18.qxd 8/30/05 6:47 PM Page 425

Optimizing Network Services 425

■■

Follow RDBMS vendor recommendations

— For the most up-to-date database server tuning techniques and suggestions, the RDBMS vendors are likely the best source of information. The following links will take you to the server optimization tips for the database server software discussed in this book:

■■

MySQL — ”Optimizing the MySQL Server”: http://dev.mysql

.com/doc/mysql/en/optimizing-the-server.html

■■

PostgreSQL — ”PostgreSQL Hardware Performance Tuning”: www.postgresql.org/files/documentation/books

/aw_pgsql/hw_performance

■■

Oracle — ”Tuning the Oracle 9i Database on Linux”: www.oracle

.com/technology/oramag/webcolumns/2003/techarticles

/scalzo_linux03.html

Summary

This chapter gave you some hints for improving the performance of Fedora

Core and RHEL networking services. Although not strictly necessary on a server system, you learned some steps to take to speed up the X Window system. All of these suggestions boiled down to eliminating or at least reducing graphical eye candy. We also highlighted the performance issues that can arise with NFS and the measures you can implement to solve some of these problems. NIS can also be fixed, although the best “fix” is often to replace NIS with

LDAP because LDAP is actively developed, whereas NIS is largely in maintenance mode. The Samba optimization tips largely centered around reducing the number and frequency of round trips to the server. Finally, we offered some suggestions to get better out of a database server, which mostly involved addressing I/O bottlenecks and using a different kernel process scheduler.

Candidly, performance tuning requires a book all its own; we hope we have given you a good start.

24_599496 ch18.qxd 8/30/05 6:47 PM Page 426

25_599496 pt03.qxd 8/30/05 7:12 PM Page 427

PA R T

Three

Internet Services

Chapter 19:

What Are Internet Services?

Chapter 20:

Configuring BIND: The Domain Name System

Chapter 21:

Configuring Mail Services

Chapter 22:

Configuring FTP Services

Chapter 23:

Configuring a Web Server

Chapter 24:

Providing Web Services

Chapter 25:

Optimizing Internet Services

25_599496 pt03.qxd 8/30/05 7:12 PM Page 428

26_599496 ch19.qxd 8/30/05 7:12 PM Page 429

C H A P T E R

19

What Are

Internet Services?

IN THIS CHAPTER

■■

■■

■■

■■

■■

■■

Learning about Secure Services

Avoiding Less Secure Internet Protocols

Using Your Linux Machine as a Server

Configuring the xinetd Server

Comparing xinetd with Standalone

Configuring Linux Firewall Packages

An Internet Service can be defined as any service that can be accessed through

TCP/IP-based networks, whether an internal network (intranet) or external network (Internet). Actually, TCP and IP are two of the protocols that are included in a group of protocols sometimes known as the Internet protocols.

Since the two most frequently used or discussed protocols of the suite are TCP and IP, the entire suite is often referred to as just TCP/IP. Internet services can be provided through either secure or nonsecure TCP/IP connections. Common services are Telnet, FTP, SMTP, HTTP, ICMP, ARP, DNS, SSH, scp, sftp, and others.

The significance of TCP/IP as the basis for these services cannot be overlooked. TCP/IP provides a platform- and operating-system-independent protocol for these services. Any computer, running any operating system, can communicate with any other computer on the network if they both use

TCP/IP protocols for establishing and maintaining the connection and formatting and transmitting the data.

The availability of a wide range of Internet services makes Linux machines versatile workhorses that can fulfill many different functions in a company’s network. This chapter covers the wide range of common services that come standard with every Red Hat system.

429

26_599496 ch19.qxd 8/30/05 7:12 PM Page 430

430 Chapter 19

C R O S S - R E F E R E N C E

Chapter 11 explains the TCP/IP suite of protocols.

Chapter 21 discusses mail transfer and SMTP. Chapter 22 explains setting up and using FTP. Chapter 23 covers HTTP and setting up an HTTP server.

Learning about Secure Services

Common services, such as Telnet and FTP, were written in the days when everyone trusted everybody else on the Internet. These services send all their traffic in plain text, including passwords. Plain-text traffic is extremely easy to eavesdrop on by anyone between the traffic’s source and destination. Since the

Internet has exploded in popularity, running insecure services such as these is not a good idea. That’s why secure replacements have been developed. These replacements provide stronger authentication controls and encrypt all their traffic to keep your data safe. You should always run secure services instead of nonsecure services.

SSH

Secure Shell, also known as SSH, is a secure Telnet replacement that encrypts all traffic, including passwords, using a public/private encryption key exchange protocol. It provides the same functionality of Telnet, plus other useful functions, such as traffic tunneling.

This is what it looks like to SSH into a machine for the first time:

[[email protected] vnavrat$ ssh [email protected]

The authenticity of host ‘woolf.xena.edu (123.456.789.65)’ can’t be established.

RSA key fingerprint is b2:60:c8:31:b7:6b:e3:58:3d:53:b9:af:bc:75:31:63.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added ‘woolf.xena.edu,123.456.789.65’

(RSA) to the list of known hosts.

[email protected]’s password:

Welcome to woolf

Unauthorized usage prohibited. Please check your quotas.

vnavrat:~>

SSH asks you if you want to accept and trust the host key being sent to you as being the real key. This question is asked only once when you log in to a machine for the first time. After this first login, SSH behaves exactly like

Telnet — you start SSH, it asks for your password, and then you see a regular terminal screen.

26_599496 ch19.qxd 8/30/05 7:12 PM Page 431

What Are Internet Services?

431

In addition to providing terminal access, SSH tunnels almost any other protocol through it. So, it is possible to tunnel POP, RCP, and other protocols through

SSH to turn them into encrypted, more secure protocols. With enough imagination and practice, you can make almost anything more secure with SSH.

Following is an example of how to tunnel your mail through SSH to keep your password and mail encrypted and secure during transit. In this example, you use

POP3 to retrieve your mail from the remote machine buffy.xena.edu. Normally you would tell your POP3 software to connect from your localhost to port

110 (the POP port) of buffy.xena.edu.

But in this example the first step is to configure your POP mailer to connect to port 16510 of your own machine, and put in the password for your account on buffy.xena.edu

. The second step is to set up the SSH tunnel, which encrypts and forwards the traffic over the network to terry.muhlenberg.edu’s

POP port.

To set up the SSH tunnel, type the following at the command line: ssh -N -L 16510:127.0.0.1:110 [email protected]

And voilà! You are now sending and receiving your mail through an encrypted SSH tunnel.

scp

Secure Copy, also known as scp, is part of the SSH package. It is a secure alternative to RCP and FTP, because, like SSH, the password is not sent over the network in plain text. You can scp files to any machine that has an ssh daemon running.

The syntax of scp is scp [email protected]:file1 [email protected]:file2

To see an example of copying a file named camcontrol.doc to remote host main from local host terry see Listing 19-1.

[[email protected] ~]$ scp camcontrol.doc [email protected]:/home/terry [email protected]’s password: camcontrol.doc 100% 117KB 117.0KB/s 00:00

Listing 19-1 Using the scp command to copy a file from the local PC to a remote PC.

And to copy a file named nasatoc.doc from remote host main to your current directory on local host terry, see Listing 19-2.

26_599496 ch19.qxd 8/30/05 7:12 PM Page 432

432 Chapter 19

[[email protected] ~]$ scp main:/home/terry/nasatoc.doc .

[email protected]’s password: nasatoc.doc 100% 20KB 20.0KB/s 00:00

Listing19-2 Using the scp command to copy a file from the remote PC to a local PC.

If you have KDE installed on your system, you can use the Konqueror browser and the fish protocol to establish an SSH connection to a remote PC.

Then you can drag and drop the files or directories you want to copy between the remote and local machine. Follow the steps here:

1. Open the Konqueror browser, enter fish://<name or IP address

of remote PC>

into the browser location field and press Enter. If this is the first time you are connecting to the remote host, you will be prompted about the connection, as shown in Figure 19-1. Click Enter to accept the information.

2. When prompted, enter the username and password and click OK to connect. Figure 19-2 shows the contents of my home directory on my home PC.

3. To copy or move files or directories from the remote PC to the local PC, select the files or directories you want to copy or move, right-click the selected items and either copy to or move the selected items from the pop-up menu, and browse to where you want to place them.

Figure 19-1 Using fish to make an SSH connection to a remote PC.

26_599496 ch19.qxd 8/30/05 7:12 PM Page 433

What Are Internet Services?

433

Figure 19-2 Using fish to display the directory contents of a remote PC.

sftp

Secure File Transfer Program, also known as sftp, is an FTP client that performs all its functions over SSH.

The syntax for sftp is: sftp [email protected]:file file

For example, Listing 19-3 shows copying the file tcres.pdf from the remote PC main to the localPC.

[[email protected] ~]$ sftp [email protected]:tcres.pdf tcres.pdf

Connecting to main...

[email protected]’s password:

Fetching /home/terry/tcres.pdf to tcres.pdf

/home/terry/tcres.pdf 100% 222KB 73.9KB/s 00:03

Listing 19-3 Using sftp to transfer files between a remote and local PC.

26_599496 ch19.qxd 8/30/05 7:12 PM Page 434

434 Chapter 19

Less Secure Services

These are nonsecure services that should not be used, since they trust that the network is absolutely secure. Their secure equivalents should be used instead.

Using these services should be discouraged, because all their traffic is sent over the network in plain text. This means that anyone with a common sniffer such as tcpdump can see every keystroke that is typed in the session, including your users’ passwords.

Telnet

Telnet is a protocol and application that enables someone to have access to a virtual terminal on a remote host. It resembles text-based console access on a

UNIX machine.

Telnet is an application that’s available almost everywhere. Because of this distribution, most beginning UNIX users use Telnet exclusively to communicate with other UNIX and NT machines. Since all Telnet traffic, including passwords, is sent in plain text, the Secure Shell (ssh) command should be used instead, if at all possible. SSH provides an equivalent interface to Telnet, with increased features, and most importantly, encrypted traffic and passwords.

This is what it looks like when you log into a machine with Telnet:

[[email protected] ~]$ telnet terry

Trying 127.0.0.1...

Connected to xena.

Escape character is ‘^]’.

Welcome to terry.muhlenberg.edu

login:

FTP

FTP is a ubiquitous file transfer protocol that runs over ports 20 and 21. For transferring software packages from anonymous FTP repositories, such as ftp.redhat.com

, FTP is still the standard application to use. However, for personal file transfers, you should use scp. scp encrypts the traffic, including passwords. Once you have successfully logged on to an FTP server, you can type help for a list of available commands. Two important commands to remember are put to move a file from your machine to the remote machine, and get to pull a file from the remote server to your machine. To send multiple files you can use mput, and to retrieve multiple files you can use mget. ls or dir gives you a listing of files available for downloading from the remote site.

26_599496 ch19.qxd 8/30/05 7:12 PM Page 435

What Are Internet Services?

435

C R O S S - R E F E R E N C E

To learn more about FTP commands, see Chapter 22.

rsync

rsync is an unencrypted file transfer program that is similar to RCP. It includes the added feature of allowing just the differences between two sets of files on two machines to be transferred across the network. Because it sends traffic unencrypted, it should be tunneled through SSH. Otherwise, don’t use it. The rsync server listens on port 873.

rsh

rsh is an unencrypted mechanism for executing commands on remote hosts.

Normally you specify a command to be run on the remote host on rsh’s command line, but if no command is given, you are logged into the remote host using rlogin. rsh’s syntax is rsh remotehostname remotecommand

rlogin

rlogin is a remote login program that connects your terminal to a remote machine’s terminal. rlogin is an nonsecure protocol, because it sends all information, including passwords, in plain text. It also enables an implicit trust relationship to exist between machines, so that you can use rlogin without a password.

finger

finger enables users on remote systems to look up information about users on another system. Generally finger displays a user’s login name, real name, terminal name, idle time, login time, office location, and phone number. You should disable finger outside of your local network, because user information gathered from it could be used to compromise your system. The finger daemon listens on port 79.

talk and ntalk

talk and ntalk are real-time chat protocols. The talk server runs on port 517 and the ntalk server runs on port 518. To send someone else a talk request, type

26_599496 ch19.qxd 8/30/05 7:12 PM Page 436

436 Chapter 19 talk

or ntalk [email protected]. If that person’s server is running a talk or ntalk daemon and the person is logged in, he or she will see an invitation to chat with you. talk and ntalk aren’t as popular as they once were, since instant messenger clients have become very popular.

Using Your Linux Machine as a Server

The following sections give you an overview of what common server protocols are available on Linux.

HTTP

The most common Web server used on Linux is Apache. Apache is started out of a system’s rc scripts. Apache is easily configurable, and its configuration files live in /etc/httpd/conf/. While Apache can be set to listen to many different network ports, the most common port it listens on is port 80.

C R O S S - R E F E R E N C E

For more information on installing and configuring the Apache Web server, see Chapter 23.

sshd

The secure shell daemon (sshd) is started out of the system’s rc scripts. Its global system configuration files are in /etc/ssh, and users’ SSH configuration files are in $HOME/.ssh/. The SSH server listens on port 22.

T I P sshd can be configured to run on an alternative port. Running SSH on a port other than 22 comes in handy if port 22 is being blocked by a firewall.

Running SSH on a different port also adds a small measure of security through obscurity. Automatic scanners used by hackers will miss that SSH is running on your machine if they don’t find it running on the standard port they expect.

ftpd

The FTP daemon uses ports 20 and 21 to listen for and initiate FTP requests. Its configuration files ftpaccess, ftpconversions, ftpgroups, ftphosts, and ftpusers, are located in the /etc directory.

C R O S S - R E F E R E N C E

You can find more information on setting up the FTP daemon in Chapter 22.

26_599496 ch19.qxd 8/30/05 7:12 PM Page 437

What Are Internet Services?

437

DNS

The Domain Name Service (DNS), which maps IP addresses to hostnames, is served by the named program on port 53. Its configuration file is named.conf

in the /etc directory.

C R O S S - R E F E R E N C E

To read more about setting up DNS on your Linux machine, see Chapter 20.

Configuring the xinetd Server

xinetd is a replacement for inetd that adds more security and functionality.

inetd is the old workhorse of the Linux networking world, and xinetd is an improvement on an important program that has been around for several years.

It incorporates new features that have been desired by system administrators for a few years now.

xinetd starts at system boot time, and waits and listens for connections to come in on the ports to which they are assigned in their conf files. After a connection request is made, if the service requested requires that a new server be spawned, then xinetd spawns a new server and keeps listening for new connection requests on the service port.

One of the most notable improvements of xinetd over inetd is that anyone can start network services. With inetd, only root can start a network service, and that restriction leads to a host of security problems.

xinetd supports encrypting plain-text services such as the ftp command channel by wrapping them in stunnel.

xinetd also enables you to do access control on all services based on different criteria, such as remote host address, access time, remote hostname, and remote host domain. In the past this kind of access control could be accomplished only with tools like tcpwrappers, or firewall software. Even then, tcpwrappers could only reliably control TCP traffic.

xinetd also takes the extra security step of killing servers that aren’t in the configuration file and those that violate the configuration’s access criteria. It can help prevent denial of service (DOS) attacks by limiting normal functions that can cripple the machine if there are too many of them occurring at the same time.

For example, xinetd can limit the number of incoming connections to the whole machine or from a single host to prevent network overflow attacks. It can limit the number of processes that are forked by a network service. To prevent the machine from being slowed to a crawl because of the incoming network traffic, xinetd can also stop a service if it is driving the machine’s load up too high.

Log capabilities have also been improved in xinetd. For each service it runs, it can log the remote user and host address, the length of time the service has been running, and failed access control attempts.

26_599496 ch19.qxd 8/30/05 7:12 PM Page 438

438 Chapter 19

xinetd is flexible enough to enable you to utilize increased security measures such as chrooted environments.

You may notice that the xinetd.conf file (see Listing 19-4) is much shorter than inetd.conf, making it easier to read through and customize. The last line says that all the files in the /etc/xinetd.d directory are read into the xinetd.conf

file as well. Each service started by xinetd gets its own dedicated file in the /etc/xinetd.d directory. This way you can tell, with a glance at the xinetd.d

file listing, what services are being started by it. You can easily enable or disable a service by setting the value of disable = to either yes or no.

#

# Simple configuration file for xinetd

#

# Some defaults, and include /etc/xinetd.d/ defaults

{ instances = 60 log_type = SYSLOG authpriv log_on_success = HOST PID log_on_failure = HOST cps = 25 30

} includedir /etc/xinetd.d

Listing 19-4 The xinetd.conf file.

The last line of the xinetd.conf file shown in Listing 19-4 shows the directory location of the individual configuration files for the services that use xinetd. Listing 19-5 shows the Krb5-telnet configuration file that is located in the /etc/xinet.d directory.

# default: off

# description: The kerberized telnet server accepts normal telnet sessions, \

# but can also use Kerberos 5 authentication.

service telnet

{ flags = REUSE socket_type = stream wait = no user = root server = /usr/kerberos/sbin/telnetd log_on_failure += USERID disable = yes

}

Listing 19-5 The xinetd config file entry required to set up a Kerberos 5 Telnet daemon.

26_599496 ch19.qxd 8/30/05 7:12 PM Page 439

What Are Internet Services?

439

If you use a Telnet server on your system, you should be aware that by default telnetd does not start up with xinetd. To start a Telnet daemon in xinetd, you should use the groups = yes option within the xinetd.conf file and change the disabled = line from yes to no.

Comparing xinetd and Standalone

Which services are standalone, and which are started from xinetd? Sometimes it can get confusing keeping track of how to start a certain service, or keep it from running in the first place. To control a service, you need to know what spawns it.

Here is a general listing of what services are spawned from superservers, such as xinetd, and which are started on their own from rc scripts or root. The key differences between things that run standalone and those started by the xinetd server is the amount of config information required and availability — that is, whether the associated service needs to be constantly available and instantly responsive, or whether that service only needs to be available in response to occasional incoming requests. Services like a Web server could certainly be run by xinetd, but the overhead of starting and stopping it repeatedly would make your system incredibly slow and perhaps even crash it.

xinetd-Started Services

The following services are started from xinetd. Each of these services should ideally have its own file in the /etc/xinetd.d directory.so You should look in that directory to find the appropriate file and open the file to change whether it is enabled or disabled.

■■

chargen

— Random character generator that sends its traffic over TCP

■■

daytime-udp

— Gives you the time over UDP

■■

finger

— User information lookup program

■■

kshell

— Restricts user access to the shell

■■

rlogin

— Service similar to Telnet, but enables trust relationships between machines

■■

swat

— Samba Web Administration tool

■■

time

— Gives you the time

■■

chargen-udp

— Random character generator that sends its traffic over udp

■■

echo

— Echoes back all characters sent to it over TCP

■■

gssftp

— Kerberized FTP server

26_599496 ch19.qxd 8/30/05 7:12 PM Page 440

440 Chapter 19

■■

rsh

— Remote shell

■■

■■

talk

— A talk (real-time chat) server

time-udp

— Gives you the time over UDP

■■

■■

comsat

— Notifies users if they have new mail

echo-udp

— Echoes back all characters sent to it over UDP

■■

■■

klogin

— Kerberos’s answer to rlogin

ntalk

— A talk (real-time chat) server

■■

■■

rsync

— Remote file transfer protocol

telnet

— Telnet server

■■

■■

wu-ftpd

— An FTP server

daytime

— Gives you the time over TCP

■■

■■

eklogin

— Encrypting kerberized rlogin server

krb5-telnet

— Kerberized Telnet server

■■

■■

rexec

— Provides remote execution facilities

sgi_fam

— File-monitoring daemon

■■

tftp

— Trivial File Transfer Program

Standalone Services

These services are started from the rc scripts specifically written for them in the rc directories. You can enable or disable these services from those directories.

■■

apache

— Web server

■■

■■

sshd

— SSH server

sendmail

— Mail server

■■

■■

qmail

— Mail server

postfix

— Mail server

■■

■■

thttpd

— Semilightweight Web server

boa

— Lightweight Web server

■■

■■

named

— DNS server

xfs

— X font server

■■

■■

xdm

— X display manager

portmap

— Maps RPC services to ports

■■

■■

rpc.quotad

— Serves quota information

knfsd

— Userspace portion of the NFS daemon

26_599496 ch19.qxd 8/30/05 7:12 PM Page 441

What Are Internet Services?

441

■■

rpc.mountd

— NFS mount server

■■

rpc.ypbind

— NIS server

■■

squid

— Web proxy server

■■

nessusd

— Penetration-testing server

■■

postgresql

— Database server

■■

mysql

— Database server

■■

oracle

— Database server

C R O S S - R E F E R E N C E

See Chapters 6 and 8 for more information about xinetd and standalone servers.

Configuring Linux Firewall Packages

Linux provides a few different mechanisms for system security. One of these mechanisms is Linux’s firewall package. The primary firewall package available is iptables. iptables is a packet filtering firewall.

C R O S S - R E F E R E N C E

To read more about iptables and Linux system security, see Chapter 34.

iptables is Fedora’s and Red Hat’s built-in IP firewall administration tool.

Using iptables enables you to run a personal firewall to protect your Linux machine. If the Linux machine is a routing gateway for other machines on your network, it can act as a packet-filtering network firewall if more than one network interface is installed.

C R O S S - R E F E R E N C E

For more information on setting up a Linux firewall, see Chapter 34.

Summary

As a general rule, you should endeavor to use programs that encrypt their network traffic, instead of using those that use unencrypted protocols.

If you must use a plain-text protocol, such as POP or rsync, wrapping it in

SSH or SSL keeps your passwords and data safe from network listeners. SSH is versatile enough to wrap around almost anything.

26_599496 ch19.qxd 8/30/05 7:12 PM Page 442

442 Chapter 19

In general, most services are started from xinetd. If a service you’re looking into is not started from xinetd, it is probably being started from the machine’s rc scripts.

Linux’s network capabilities have grown a great deal in the past couple of years. Currently, a properly configured Red Hat server can function as many different network devices — anything from an AppleTalk or Samba server to an

LDAP server or firewall. Once you get a grasp of how the servers are started and configured in general, the possibilities of what you can do are nearly endless.

27_599496 ch20.qxd 8/30/05 7:28 PM Page 443

C H A P T E R

20

Configuring BIND:

The Domain Name System

IN THIS CHAPTER

■■

■■

■■

■■

■■

■■

■■

■■

Understanding DNS

Installing the Software

Understanding Types of Domain Servers

Examining Server Configuration Files

Configuring a Caching DNS Server

Configuring a Secondary Master DNS Server

Configuring a Primary Server

Checking Your Configuration

This chapter provides information about the Domain Name System (DNS), which is used for name address resolution. In this chapter, you learn how the

Domain Name System works for finding hosts on TCP/IP networks. You also learn about different types of DNS servers and how to configure them for your own network. After configuring your servers, you’ll learn about some diagnostic tools that can be used to check the configuration and performance of your DNS.

Understanding DNS

Name address resolution is, simply stated, the conversion of people friendly names into computer friendly numbers. Remember from Chapter 11 that each interface on the network has an IP address. This address is expressed as a group of numbers referred to as a dotted quad group. These groups of numbers present no problem to the computers in the network, but it is difficult for

443

27_599496 ch20.qxd 8/30/05 7:28 PM Page 444

444 Chapter 20

humans to remember many groups of numbers. So, you need to be able to enter names and then have these names converted into numbers. Each time you type a Web site’s address into your browser, the Domain Name System

(DNS) goes to work. You enter names that are easy for you to remember, and the names are resolved into numbers that computers find easy to understand.

Enabling efficient human/machine interaction is the function of name address resolution. In this chapter you learn how to install and configure the Domain

Name System, which provides this name address resolution.

First, take a look at domain names and their organization using the domain name tactechnology.com. The first part of this domain name, tactechnology, is the name of the company, institution, or organization. The next part, after the period (dot in today’s vernacular) is called the top-level domain (TLD). In addition to the com top-level domain, you will find many others. Table 20-1 shows other top-level domains in the United States.

Table 20-1 United States Top-Level Domains

TOP-LEVEL DOMAIN MEANING

com edu

A TLD typically used to register a business

A TLD assigned to an educational institution gov mil net org

A TLD given to a U.S. government agency

A TLD used by a branch of the U.S. military

A TLD used by a network affiliated organization

A TLD used by a noncommercial organization int us biz info name museum coop aero pro travel

An TLD assigned to an international organization

The U.S. domain, with each listing as a lower level

Another TLD used for businesses

A TLD that can be used for any type of organization

A TLD used to register sites for individuals

A TLD used to register a museum

A TLD assigned to a cooperative organization

A TLD used by the air transport industry

A TLD not yet active but assigned to professions

A TLD that should be available in late 2005 used by travel related companies

27_599496 ch20.qxd 8/30/05 7:28 PM Page 445

Configuring BIND: The Domain Name System 445

Top-level domains in other countries include a two-letter suffix, such as fr for France or su for Switzerland. Not all of the top-level domains are the same as the top-level U.S. domains, but a company in France could be http://www.frenchcompany.com.fr

.

Large domains may be further broken down into subdomains. For example, the tactechnology site is www.tatctechnology.com. Perhaps the accounting department runs their own Web server. To find their Web server, tactechnology contains the subdomain acct.tactechnology.com. An individual computer in the accounting department also has a hostname, for example, payables. The complete name for this computer is then payables.acct.tactechnology

.com

, and you can find its IP address by using the DNS to look it up.

When you type in a hostname, your system uses its resources to resolve names into IP addresses. One of these files is /etc/nsswitch.conf

(nsswitch means name service switch), which contains a line telling the system where to look for host information. Figure 20-1 shows the /etc

/nsswitch.conf

file and the hosts line.

The information following the word hosts tells the system to first look at the local files, and then to use the Domain Name Service (DNS) to resolve the names into IP numbers. One of the local files searched is the /etc/hosts file.

C R O S S - R E F E R E N C E

See Chapter 11 for more information about the

/etc/hosts

file.

Figure 20-1 The nsswitch.conf file tells the resolver routines where to look for IP addresses.

27_599496 ch20.qxd 8/30/05 7:28 PM Page 446

446 Chapter 20

The hosts file contains IP addresses and hostnames that you used on your sample network. So, why couldn’t you use this file for name resolution? Well, you could on a small internal network that you controlled and that did not have very many IP addresses. But, the hosts file is not a manageable solution on a large network, because it is an impossible task to keep it up to date. You could not have control over every IP address.

After the system looks in the hosts file and fails to find the address, the next file checked is /etc/resolv.conf. This file contains the IP addresses of computers that are known as domain name servers, and these are listed in

/etc/resolv.conf

as just name servers. Figure 20-2 shows the /etc/resolv

.conf

file on one of the computers I use at work.

Figure 20-2 The /etc/resolv.conf file points to domain name servers used to resolve IP addresses.

You could list up to three name servers, but one is all that is required. It is a good idea to list a second name server, thus enabling a connection to the second one of the name servers in case the first name server is down or not reachable.

Don’t list more than three name servers, because any over three are ignored.

Installing the Software

So far you have learned about name address resolution and the structure of domains in the United States. Now you will learn about the Domain Name

System servers that resolve the name into IP numbers. The most common DNS server used in current Fedora Core and Red Hat Enterprise Linux distributions is BIND, or the Berkeley Internet Name Daemon. The latest release of BIND

27_599496 ch20.qxd 8/30/05 7:28 PM Page 447

Configuring BIND: The Domain Name System 447

can be obtained from the Internet Software Consortium at www.isc.org. A very convenient and easy way to install the latest version of BIND is to look for the distribution specific package. Check the Web site for your distribution to locate the RPM for BIND.

The RPM version of BIND is included with the Red Hat installation

CD-ROMs. The RPM file can be installed at the command line by using the rpm command.

C R O S S - R E F E R E N C E

See Chapter 30 for instructions on installing and upgrading packages.

Understanding Types of Domain Servers

A top-level domain server, one that provides information about the domains shown in Table 20-1, is typically referred to as a root name server. A search for www.muhlenberg.edu

looks to the root name server for .edu for information. The root name server then directs the search to a lower-level domain name server until the information is found. You can see an example of this by using the dig command to search for the root name server for .edu, as shown in Figure 20-3.

The figure shows the root name server that provides information for the

.edu

domain. You can continue the search for the second-level domain by adding the name of the domain you are looking for, as shown in Figure 20-4.

Figure 20-3 A search for the top-level root name servers for .edu.

27_599496 ch20.qxd 8/30/05 7:28 PM Page 448

448 Chapter 20

Figure 20-4 A search for the second-level domain shows the authoritative name server.

After you have found the domain you are looking for, information about that domain is provided by its local domain name servers. The three types of local domain name servers are master, or primary, slave, or secondary, and caching-only servers.

■■

Master

— The master contains all the information about the domain and supplies this information when requested. A master server is listed as an authoritative server when it contains the information you are seeking and it can provide that information.

■■

Slave

— The slave is intended as a backup in case the master server goes down or is not available. This server contains the same information as the master and provides it when requested if the master server cannot be contacted.

■■

Caching

— A caching server does not provide information to outside sources; it is used to provide domain information to other servers and workstations on the local network. The caching server remembers the domains that have been accessed. Use of a caching server speeds up searches since the domain information is already stored in memory, and the server knows exactly where to go rather than having to send out a request for domain information.

Where does the information that the master and slave servers provide come from? The server(s) have been configured to provide it when asked. In the next section, you learn how to configure a server to provide domain name information.

27_599496 ch20.qxd 8/30/05 7:28 PM Page 449

Configuring BIND: The Domain Name System 449

Examining Server Configuration Files

Before you begin to configure your servers, you need to take a closer look at the files you need to configure. The number of files you will use depends on the type of BIND server you want to use. You need five files to set up the named server. Three files are required regardless of the configuration as a master, slave, or caching-only server, and two additional configuration files are used on the master server. There is also the script that is used to start the servers after they are configured, for a total of six possible files.

The three required files are:

■■

named.conf

— Found in the /etc directory, this file contains global properties and sources of configuration files.

■■

named.ca

— Found in /var/named, this file contains the names and addresses of root servers.

■■

named.local

— Found in /var/named, this file provides information for resolving the loopback address for the localhost.

The two additional files required for the master domain server are:

■■

zone

— This file contains the names and addresses of servers and workstations in the local domain and maps names to IP addresses.

■■

reverse zone

— This file provides information to map IP addresses to names.

The following script is used to start the BIND server:

■■

/etc/rc.d/init.d/named

— This is the BIND server initialization file used to start BIND. A sample file is installed with the RPM from the

Installation CDs.

You begin with the /etc/named.conf file. An example of this file is shown in Listing 20-1.

//

// named.conf for Red Hat caching-nameserver

// options { directory “/var/named”; dump-file “/var/named/data/cache_dump.db”; statistics-file “/var/named/data/named_stats.txt”;

/*

Listing 20-1 The /etc/named.conf file for a caching-only server installed by the default installation of BIND. (continued)

27_599496 ch20.qxd 8/30/05 7:28 PM Page 450

450 Chapter 20

* If there is a firewall between you and nameservers you want

* to talk to, you might need to uncomment the query-source

* directive below. Previous versions of BIND always asked

* questions using port 53, but BIND 8.1 uses an unprivileged

* port by default.

*/

// query-source address * port 53;

};

//

// a caching only nameserver config

// controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; };

}; zone “.” IN { type hint; file “named.ca”;

}; zone “localdomain” IN { type master; file “localdomain.zone”; allow-update { none; };

}; zone “localhost” IN { type master; file “localhost.zone”; allow-update { none; };

}; zone “0.0.127.in-addr.arpa” IN { type master; file “named.local”; allow-update { none; };

}; include “/etc/rndc.key”;

Listing 20-1 (continued)

The named.conf file

Look at this file in more detail beginning with the lines starting with //. These are comment lines, and anything following them is ignored. Commands are passed to the file in the form of statements. Several of these statements are

27_599496 ch20.qxd 8/30/05 7:28 PM Page 451

Configuring BIND: The Domain Name System 451

shown in the sample file, but you actually can use seven configuration statements. These are listed here with a brief explanation of their function.

■■

options

— Lists global configurations and defaults

■■

include

— Gets information from another file and includes it

■■

acl

— Specifies IP addresses used in an access control list

■■

logging

— Specifies log file locations and contents

■■

server

— Specifies properties of remote servers

■■

zone

— Specifies information about zones

■■

key

— Specifies security keys used for authentication

Information about the statement is contained within curly braces and terminated by a semicolon: {information about server};.

Options

The options statement is typically the first section of named.conf, and it contains information about the location of the files used by named. You can use only one options statement, but you can have more than one value for that statement. In the sample file shown in Listing 20-1, the options statement shows the path to the location where additional configuration files used by named are located. By specifying the directory where other files are located, you make it unnecessary to list the entire path to the file; you just list the name of the file for any files shown in the remainder of named.conf. Options statements use the following syntax: options { value “property”;

}

The list of values that can be used in the options statement is quite long.

These values are shown, listed alphabetically, in Table 20-2.

Table 20-2 Options Values and Their Meanings

VALUE MEANING

allow-query allow-transfer

Accepts queries only from hosts in the address list (by default queries are accepted from any host).

Usage: allow-query {“address-list”};.

Zone transfers are accepted only by hosts in the address list (by default transfers are allowed to all hosts).

Usage: allow-transfer {“address list”};.

(continued)

27_599496 ch20.qxd 8/30/05 7:28 PM Page 452

452 Chapter 20

Table 20-2 (continued)

VALUE

auth-nxdomain coresize datasize

MEANING

The server responds as an authoritative server (defaults to yes).

Usage: auth-nxdomain “yes or no”; (choose one).

check-names

Hostnames are checked for compliance with the RFC.

Usage: check-names “master or slave or response warn or fail or ignore”;

(choose one from each group).

cleaning-interval

Specifies the time period before expired resource records are removed by the server (defaults to 60 minutes).

Usage: cleaning-interval “number”; (specify number in minutes).

Specifies largest size for core dump files.

Usage: coresize “size”; (specify size in bytes).

Limits server memory usage.

Usage: datasize “size”; (specify size in bytes).

deallocate-onexit directory dump-file fake-iquery fetch-glue files forward

Detects memory leaks (default is no).

Usage: deallocate-on-exit “yes or no”;

(choose one).

Path of the directory where server configuration files are located.

Usage: directory “path to directory”; (specify path).

If named receives a SIGINT signal, it dumps the database to the file specified here (defaults to named_dump.db).

If set to yes, the server sends a fake reply to inverse queries rather than an error (default is no).

Usage: fake-iquery “ yes or no”; (choose one).

If set to yes, the server obtains the glue records for a response (default is yes).

Usage: fetch-glue “yes or no”; (choose one).

Limits number of concurrently open files (default is unlimited).

Usage: files “number”; (specify number).

If set to first, the servers listed in the forwarders option are queried first, and then the server tries to find the answer itself. If set to only, just the servers in the forwarders list are queried.

Usage: forward “first or only”; (choose one).

27_599496 ch20.qxd 8/30/05 7:28 PM Page 453

Configuring BIND: The Domain Name System 453

Table 20-2 (continued)

VALUE

forwarders host-statistics interfaceinterval listen-on max-transfertime-in memstatisticsfile multiple-cnames named-xfer notify pid-file query-source

MEANING

Shows IP addresses of servers to forward queries (default is none).

Usage: forwarders “IP addresses of servers”;

(specify IP addresses).

If set to yes the server keeps statistics on hosts (default is no).

Usage: host-statistics “yes or no”; (choose one).

Specifies interval for searching the network for new or removed interfaces (default is 60 minutes).

Usage: interface-interval “time”; (specify time in minutes).

Specifies port and interfaces on which server listens for queries (default is port 53).

Usage: listen-on “port {address list}”; (specify port number and address list).

Specifies time server waits for completion of inbound transfer (default is 120 minutes).

Usage: max-transfer-time-in “time”; (specify time in minutes).

When deallocate-on-exit is set, specifies the file where memory statistics are written (defaults to named.memstats

).

Usage: memstatistics-file “path to file”;

(specify path and filename).

When set to yes, enables multiple CNAME usage (default is no).

Usage: multiple-cnames “yes or no”; (choose one).

Specifies path to the named-xfer program.

Usage: named-xfer “path to file”; (specify path).

When zone files are updated, this option, when set to yes, sends DNS NOTIFY messages (default is yes).

Usage: notify “yes or no”; (choose one).

Name of file holding process ID.

Usage: pid-file “path to file”; (specify path and filename).

Specifies port and IP address used to query other servers.

Usage: query-source “address port”; (specify IP address and port).

(continued)

27_599496 ch20.qxd 8/30/05 7:28 PM Page 454

454 Chapter 20

Table 20-2 (continued)

VALUE

recursion stacksize statisticsinterval topology transfer-format transfers-in transfers-out transfers-per-ns

MEANING

The server recursively searches for query answers (default is yes).

Usage: recursion “ yes or no”; (choose one).

The amount of stack memory the server can use.

Usage: stacksize “number”; (specify the amount of memory).

The time interval for logging statistics (default is 60 minutes).

Usage: statistics-interval “time”; (specify the time in minutes).

Sets server preference for remote servers.

Usage: topology {“address list”};.

When set to one-answer, only one resource record per message is sent. When set to many-answers, as many records as possible are transmitted in each message

(default is one).

Usage: transfer-format “one-answer manyanswers”;

(choose one).

Maximum concurrent inbound zone transfers (default is 10).

Usage: transfers-in “number”; (specify the number).

Maximum concurrent outbound transfers.

Usage: transfers-out “number”; (specify the number).

Limits inbound transfers from a single server (default is two).

Usage: transfers-per-ns “number”; (specify the number).

Include

The include statement lists the path and name of any files that you want to be included with the named.conf file. Use the same syntax used in the options statement to specify the path.

27_599496 ch20.qxd 8/30/05 7:28 PM Page 455

Configuring BIND: The Domain Name System 455

Acl

This option lets you specify a list of IP addresses in an access control list. Only hosts on this list have access to the server.

Logging

The logging statement is where you specify your server’s logging options. The logging statement contains two additional items, the channel and the category.

The channel is where you specify the location of the logged information.

Logged information can be written to a file, sent to the syslog, or thrown away by specifying the appropriate command. Choosing to send the information to a file gives you several additional choices for handling the information. You can set the number of versions to keep, the size of the files, and whether the severity of the information and the time and category are included with the other information in the file.

The syntax for the logging statement is similar to the syntax for the option statement. The following commands send the information to a file. Items in italics indicate information you need to enter.

logging { channel channel_name { file path to file versions specify number or unlimited size specify size in bytes }

}

If you want to send the information to the syslog, the syntax is:

logging {

channel channel_name {

syslog (choose where to send from following choices)

(kern,user,mail,daemon,auth,syslog,lpr,news,uucp,cron,\ authpriv,ftp,local0 thru local7)

To discard the information, choose null as the destination.

logging {

channel channel_name { null;}

}

Next, you can set the severity level for the information written to the file or syslog. This section follows the sections shown previously for file or syslog.

You also indicate here whether you want the time, category, and severity

27_599496 ch20.qxd 8/30/05 7:28 PM Page 456

456 Chapter 20

included. If you are discarding the information, you don’t need to set these parameters.

severity choose from critical,error,warning,notice,info,debug\ level,dynamic

print-time choose yes or no

print-severity choose yes or no

print-category choose yes or no

};

The category is where you specify the type of information to log. This value follows the severity and print parameters and takes the following syntax:

category

category name {

channel name; channel name;

};

You can choose from over 20 categories. These are shown, alphabetically, in

Table 20-3.

Table 20-3 Logging Categories

CATEGORY TYPE OF INFORMATION LOGGED

cname config

Information about CNAME references

Information about configuration files db default eventlib insist

Information about databases

The default if nothing is selected

Information about event system debugging

Details about failures from internal consistency checking lame-servers load maintenance ncache notify os packet panic parser queries

Information about LAME servers

Information about zone loading

Information about maintenance

Information about negative caching

Information about tracing the NOTIFY protocol

Information about operating system problems

Dumps of all sent and received packets

Information about faults that shut down the server

Information about processing configuration commands

Information about all received DNS queries

27_599496 ch20.qxd 8/30/05 7:28 PM Page 457

Configuring BIND: The Domain Name System 457

Table 20-3 (continued)

CATEGORY TYPE OF INFORMATION LOGGED

response-checks

Information about response-checking results security

Information about security status of server statistics update xfer-in xfer-out

Information about server statistics

Information about dynamic updates

Information about inbound zone transfers

Information about outbound zone transfers

Using the categories from the logging statement, you can obtain a large quantity of information about your server. This information can be useful if you are having problems with your DNS. You can enable logging for the area that you think is causing your problem and then read the appropriate log to find any messages that might indicate an error with your configuration.

server

In the server statement you can set the properties of a remote server. You can specify whether to send queries to the remote server from the local server, and you can set the method used for transferring information. The syntax for this statement is the same as for other statements. The following are valid values:

■■

bogus

— Specify yes or no. No is the default and indicates that queries are sent to the remote server. Yes means that the remote server is not queried.

■■

transfer

— Specify the number of transfers you want to allow.

■■

transfer-format

— Specify whether you want one-answer or manyanswers.

■■

keys

— Specify key ID (currently not implemented).

zones

The remainder of the listings in /etc/named.conf shown in Listing 20-1 are zone statements. These zone statements refer to files that are called zone files.

Additional options for zone statements exist, of course. Each zone statement begins with the word zone followed by the domain name and the data class.

The four data classes are in, hs, hesiod, and chaos. If no type is specified, the default is in, for Internet.

27_599496 ch20.qxd 8/30/05 7:28 PM Page 458

458 Chapter 20

Next follows the type option which specifies whether the server is a master, is a slave/stub, or is the hints file. A stub server loads only NS records, not the entire domain. The hints file is used to initialize the root cache and contains a list of root servers.

Next is the name of the zone file for the specified zone. This is a pointer to the file containing the data about the zone. You look at a zone file in detail a little later in this chapter.

The other options for the zone statements are listed here, along with an explanation of their function:

■■

■■

■■

■■

■■

■■

■■

allow-query

— Accepts queries only from hosts in the address list

(by default queries are accepted from any host).

allow-transfer

— Zone transfers are accepted only by hosts in the address list (by default transfers are allowed to all hosts).

allow-update

— Hosts in the address list are allowed to update the database.

also-notify

— Servers in the address list are sent a notify message when the zone is updated.

check-names

— Hostnames are checked for compliance with the RFC.

max-transfer-time-in

— Specifies the time the slave waits for a zone transfer.

notify

— When zone files are updated, this option, when set to yes, sends DNS NOTIFY messages (default is yes).

These options are the same as those shown in the options statement section and have the same function here. When listed in the options section, they apply to all zones, but if listed with a specific zone, they apply only to that zone. Settings listed in a specific zone section override those globally set in the options statement.

Zone Files

Zone files contain resource records (RR) about IP addresses. A typical zone file is shown in Listing 20-2.

@ IN SOA

42 ; serial

3H ; refresh

15M ; retry

1W ; expiry

1D ) ; minimum

IN NS localhost localhost IN A 127.0.0.1

localhost root (

Listing 20-2 A zone file is used to provide information about a DNS server.

27_599496 ch20.qxd 8/30/05 7:28 PM Page 459

Configuring BIND: The Domain Name System 459

A zone file can contain many types of RRs, which are listed in the order in which they generally appear in the zone files, and explained next.

SOA — Start of Authority

The start of authority (SOA) is the first line in the zone file. The SOA identifies the name server as the authoritative source for information about that domain.

Each zone file has only one SOA, and it contains the following data:

@ IN SOA main.tactechnology.com. mail.tactechnology.com. (/

2000052101 ; Serial

8h ;Refresh

2h ;Retry

1w ;Expire

1d) ;Minimum TTL

The first character in the SOA line is a special symbol that means “to look at this domain.” IN means Internet. SOA means Start of authority.

In this example, the authoritative server for this domain is main

.tactechnology.com.

, and mail.tactechnology.com. is the e-mail address of the administrator. Note the trailing period after the domain names.

If these are not included, the domain name is appended to the entry.

The opening parenthesis enables the first line to be extended so that anything between the opening and closing parenthesis is considered one line.

The information within the parenthesis is passed to other name servers, secondary masters that use this information to update their records. The line containing 2000052101 ; Serial is the serial number of the file. Secondary servers compare this number with their stored information. If the numbers are the same, the information has not changed, and it is not necessary to download this file. If the serial numbers are different, the file is downloaded to update the information in the secondary server. The serial number can be any number desired as long as it can be incremented to indicate a revision to the file. The semicolon indicates that what follows to the end of the line is a comment.

■■

Refresh

— The amount of time the server should wait before refreshing its data.

■■

Retry

— The amount of time the server should wait before attempting to contact the primary server if the previous attempt failed.

■■

Expire

— Means that if the secondary master is unable to contact a primary master during the specified period, the data expires and should be purged.

■■

TTL

— Specifies the time to live for the data. This parameter is intended for caching name servers and tells them how long to hold the data in their cache.

27_599496 ch20.qxd 8/30/05 7:28 PM Page 460

460 Chapter 20

All of the information contained by the SOA may be placed on one line, but it is usually written as shown previously. The order of the items is significant in the SOA header. Following the SOA header information are lines containing additional server information. Two of these lines, containing the abbreviations

NS and A are shown in Listing 20-2. These abbreviations are explained here:

■■

NS

— Name servers in this domain.

■■

■■

A

— The IP address for the name server.

PTR

— Pointer for address name mapping.

■■

■■

■■

CNAME

— Canonical name, the real name of the host.

MX

— The mail exchange record. The MX record specifies the mail servers for the domain. If more than one MX server is present priority is determined by the address with the lowest number receiving the highest priority.

TXT

— Text information. You can enter descriptive information here.

■■

■■

WKS

— Well-known service. You can enter descriptive information here.

HINFO

— Host Information usually shows type of hardware and software.

The Reverse Zone File

In the previous example you looked at a sample zone file that uses the domain name. This method is called forward address resolution, since it uses a name to find an IP number and is the most common use of name resolution.

You can also find a name from an IP number, and this is called reverse address resolution. All you need to do is enter the IP address, and the server returns the domain name. Reverse address resolution requires the use of a reverse zone file. Listing 20-3 shows a sample reverse zone file.

@ IN SOA localhost. root.localhost. (

1997022700 ; Serial

28800 ; Refresh

14400 ; Retry

3600000 ; Expire

86400 ) ; Minimum

IN NS localhost.

1 IN PTR localhost.

Listing 20-3 A typical reverse lookup zone file.

27_599496 ch20.qxd 8/30/05 7:28 PM Page 461

Configuring BIND: The Domain Name System 461

Configuring a Caching DNS Server

Now you know which files need to be configured and what information that needs to be placed in them. You are ready to set up your own domain name servers. In this section you set up a caching server. As stated earlier, three files are used in all three types of server configurations. In a caching-only server, these three files make up the entire configuration. Fortunately for us, the default installation of BIND used on Red Hat Enterprise Linux creates the configuration files needed for a caching name server, but it is always a good idea to look at the files to be sure that they are correct.

Begin by verifying the zone information in /etc/named.conf. When you installed the BIND package, the /etc/named.conf file was created and it contained zone information for your localhost, but you need to check it to be sure. You are looking for two zone lines: one indicated by a “.”, referencing the file named.ca, and one shown as “0.0.127.in.addr.arpa”, referencing named.local.

Next, you need to check the configuration of the /var/named/named.local

file. This file contains the domain information for the localhost and is typically created when BIND is installed. You usually don’t have to make any changes to

/var/named/named.local

. This domain is a reverse domain in that it is used to map the loopback address 127.0.0.1 to the localhost name.

You need to check the /etc/nsswitch file to be sure it contains the following line: hosts: files dns

You need to check the /etc/resolv.conf file to make sure that the IP address (127.0.0.1) of your localhost is listed as a name server.

Finally, you need to check that your /etc/host.conf contains the word bind

.

After you have completed all of the previous steps, it is time to start the named daemon and check your work.

Type service named start at a command prompt, press Enter, wait for the prompt to return, and then type rndc status. Press Enter. You will see output similar to this: number of zones: 8 debug level: 0 xfers running: 0 xfers deferred: 0

SOA queries in progress: 0 query logging is off server is up and running

You have successfully configured and started your caching name server.

27_599496 ch20.qxd 8/30/05 7:28 PM Page 462

462 Chapter 20

Configuring a Secondary Master DNS Server

Next, you set up a secondary master or slave server for your domain. The procedure is similar to, and not much more difficult than, what you have already done. You already have three of the files in place and only need to slightly modify the /etc/named.conf file and add two more files to complete the slave configuration.

On the server you want to be the slave, go to the /etc/named.conf file and add two more zones, one for the forward lookup of your server and one for the reverse lookup. For the forward lookup, you need to add the following.

(For this example, the master server is called main.tactechnology.com, and the slave is p200.tactechnology.com. Be sure to use your own domain name and IP address instead of the examples shown.) zone “tactechnology.com” { notify no; type slave; file “tactech.com”; masters { 192.168.1.1; };

};

For the reverse lookup, you add this section: zone “1.168.192.in-addr.arpa” { notify no; type slave; file “tac.rev”; masters { 192.168.1.1; };

};

After modifying the /etc/named.conf file, the configuration of the slave server is complete and you can move on to configuring the master server.

Configuring a Primary Master Server

The /etc/named.conf file on the master server also needs to be modified.

Assuming that you already set up this server as a caching-only server, you just need to add the following lines to /etc/named.conf. (This example uses the names you defined earlier; be sure to use your own names and IP addresses.) zone “tactechnology.com” { notify no; type master; file “tactech.com”;

};

27_599496 ch20.qxd 8/30/05 7:28 PM Page 463

Configuring BIND: The Domain Name System 463

For the reverse lookup you add this section: zone “1.168.192.in-addr.arpa” { notify no; type master; file “tac.rev”;

};

Notice that you used the same names for the files on the master server as the slave server. This is because these files are downloaded by the slave in a zone file transfer and stored on the slave in the files shown by the file option. You did not create the files on the slave but created them on the master server.

N OT E

The filenames, hostnames, and IP addresses I use here are just examples for the purpose of this explanation. Be sure to use filenames, hostnames, and IP addresses appropriate to your organization.

You now need to create the zone files that are referenced by the /etc

/named.conf

file. First you create the file /var/named/tactech.com by beginning with the Start of Authority section (SOA). For an explanation of the information contained in zone files, refer to the zone file section earlier in this chapter.

@ IN SOA main.tactechnology.com.mail.tactechnology.com. ( /

200005203 ; Serial/

8h; Refresh/

2h; Retry/

1w; Expire/

1d); Minimum TTL/

Next you add name server and mail exchange information:

NS

NS

MX

MX main.tactechnology.com./ terry.tactechnology.com./

10 main;Primary Mail Exchanger/

20 p200;Secondary Mail Exchanger/

Finally, you add information about your localhost, and mail, FTP, and Web server. You can also add information about every workstation on your network.

Next, you set up the reverse lookup zone file, which is called tac.rev.

Again, you need to start with the SOA header as shown:

@ IN SOA main.tactechnology.com. mail.tactechnology.com.(

200005203;Serial

8h ; Refresh

2h ; Retry

1w ; Expire

1d) ; Minimum TTL

27_599496 ch20.qxd 8/30/05 7:28 PM Page 464

464 Chapter 20

Next, you add the information about your name servers and their IP addresses.

NS main.tactechnology.com.

1 PTR main.tactechnology.com.

2 PTR p200.tactechnology.com.

If you have done everything as explained here, your name server should be working properly after you restart it. You made some changes to the

/etc/named.conf

file, so before you can check what you did, you need to restart the named daemon.

N OT E

The named daemon must be restarted whenever you make changes to

/etc/named.conf

. To restart named, you just need to enter the following command:

service named restart

Checking Your Configuration

After you finish configuring your master DNS server, you can check your configuration to be sure that it’s working. You can use several tools to do your check. I talk about two of them here. Just be sure to substitute your domain and IP information when you run the commands. If your system is set up correctly, you should obtain similar results.

The Host Program

host enables you to find an IP address for the specified domain name. All that is required is the domain name of the remote host, as shown here with the command on the first line and the output from the command on the second line:

[[email protected] root]# host tactechnology.com

tactechnology.com has address 12.129.206.112

You can also search for resource record types by using the –t option and the type of resource record that you want to search. For example, if you want to find information about the mail server for a domain, enter the following command and receive the following output:

[[email protected] named]# host -t mx tactechnology.com

tactechnology.com mail is handled by 10 mail.tactechnology.com.

27_599496 ch20.qxd 8/30/05 7:28 PM Page 465

Configuring BIND: The Domain Name System 465

The dig Program

dig can be used for debugging and obtaining other useful information. The basic syntax is: dig (@server) domain name (type)

Items shown in parentheses are optional. Listing 20-4 shows an example of using dig to request information about the DNS servers at my school.

[[email protected] named]# dig muhlenberg.edu

; <<>> DiG 9.2.2-P3 <<>> muhlenberg.edu

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50760

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:

;muhlenberg.edu. IN A

;; ANSWER SECTION: muhlenberg.edu. 86400 IN A 192.104.181.5

;; AUTHORITY SECTION: muhlenberg.edu. 86400 IN NS hal.muhlenberg.edu.

;; ADDITIONAL SECTION: hal.muhlenberg.edu. 86400 IN A 192.104.181.5

;; Query time: 5 msec

;; SERVER: 192.104.181.5#53(192.104.181.5)

;; WHEN: Thu Sep 9 14:37:54 2004

;; MSG SIZE rcvd: 82

Listing 20-4 Using dig to search for IP addresses.

dig can also be used to do reverse lookups by using the –x switch and specifying the IP address, as shown in Listing 20-5. The first line in the listing is the command entered at the command prompt, and the remaining lines are the output from the command.

[[email protected] named]# dig -x 192.104.181.5

; <<>> DiG 9.2.2-P3 <<>> -x 192.104.181.5

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26961

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

Listing 20-5 Using dig to search for domain names. (continued)

27_599496 ch20.qxd 8/30/05 7:28 PM Page 466

466 Chapter 20

;; QUESTION SECTION:

;5.181.104.192.in-addr.arpa. IN PTR

;; ANSWER SECTION:

5.181.104.192.in-addr.arpa. 86400 IN PTR hal.muhlberg.edu.

;; AUTHORITY SECTION:

181.104.192.in-addr.arpa. 86400 IN NS hal.muhlberg.edu.

181.104.192.in-addr.arpa. 86400 IN NS stimpy.nwip.muhlberg.edu.

;; ADDITIONAL SECTION: hal.muhlberg.edu. 86400 IN A 192.104.181.5

stimpy.nwip.muhlberg.edu. 86400 IN A 192.104.181.207

;; Query time: 6 msec

;; SERVER: 192.104.181.5#53(192.104.181.5)

;; WHEN: Thu Sep 9 14:39:46 2004

;; MSG SIZE rcvd: 170

Listing 20-5 (continued)

Both of the listings provide information about the exact same servers. In

Listing 20-4, I used a domain name for the search, and I received the IP addresses associated with the domain name. In Listing 20-5, I searched using an IP address, and I received the host and domain name of the servers.

Summary

This chapter provided a brief but concise overview of the Domain Name System using a small, simple network as an example. You looked at name address resolution and found out how names that are easy for people to remember are converted to numbers that computers can understand. You obtained the BIND software package and installed it on your system and located the files that have to be configured for BIND to work. After configuring the files, you set up a caching name server and tested its operation. You then configured a slave and master name server and looked at some of the diagnostic utilities available for the BIND package.

28_599496 ch21.qxd 8/30/05 7:28 PM Page 467

C H A P T E R

21

Configuring

Mail Services

IN THIS CHAPTER

■■

■■

■■

■■

■■

■■

Email Explained

Introducing SMTP

Configuring Sendmail

Using the Postfix Mail Server

Serving email with POP3 and IMAP

Maintaining Email Security

Using electronic mail, you can send messages to and receive messages from other computer users anywhere in the world. Email, as it is more commonly known, is a very powerful and useful tool. In this chapter you learn how email works and then configure your systems to put email to work for you.

Email Explained

An email message, just like a letter sent through regular mail, begins with a sender and ends with a recipient. Between sender and recipient are many postal workers who ensure that the letter is properly handled. Even though the sender and recipient never see these workers, they perform essential functions in moving the mail. Email works in a similar fashion, and although there are not many people between the sender and receiver, programs perform the same function. These programs use network protocols to do the job of ensuring that the message goes from sender to receiver. In this chapter you configure email to run across TCP/IP protocols.

C R O S S - R E F E R E N C E

Chapter 11 explains the TCP/IP protocol suite.

467

28_599496 ch21.qxd 8/30/05 7:29 PM Page 468

468 Chapter 21

Before configuring an email client or server, you need to understand how email works and the programs to use or make available to your users. Several key components are essential for email to work properly, and as a system administrator it is your responsibility to configure the following items.

■■

Programs:

■■

A mail user agent for users to be able to read and write email

■■

A mail transfer agent to deliver email messages between computers across a network

■■

■■

A mail delivery agent to deliver messages to users’ mailbox files

■■

A mail-notification program to tell users that they have new mail

(optional)

The SMTP protocols for packaging email and transferring email messages between MTAs

Other communication and mail-storage components include TCP/IP ports through which programs communicate, mail queues in which to store email during various phases of the delivery process, and mailbox files, which are the final destinations for delivered email messages.

This chapter explains these items in greater detail in later sections. The next section tracks email messages through the process from sending to delivery to illustrate how the various components work together. After learning how the components work, you configure these components to build a fully functioning email system for your server and clients.

Tracing the Email Delivery Process

In classic UNIX style, email creation, transmission, and delivery consist of several discrete tasks, each of which is handled by a program designed specifically for that task. The value of this segmented method is that you can replace one element, such as the program used to compose email, without affecting the functionality of the entire system. The usual email delivery process involves three components, a mail user agent, a mail transfer agent, and a mail delivery agent.

Mail User Agent (MUA)

To be able to send mail, you or your users need a program called a mail user

agent, commonly abbreviated as MUA and widely referred to as a mail client.

The MUA provides users an interface for reading and writing email messages.

Two types of MUAs are available: those that have a graphical user interface

(GUI), such as Mozilla Thunderbird or KMail, and those that have a command

28_599496 ch21.qxd 8/30/05 7:29 PM Page 469

Configuring Mail Services 469

line interface (CLI), such as Mutt or elm. Whether your MUA is a GUI or CLI, the functionality is the same. After composing an email message, the MUA sends it to a mail transfer agent (MTA), which transmits the message across the network.

Mail Transfer Agent (MTA)

A mail transfer agent, usually abbreviated as MTA, is the program that sends the message across the network. MTAs work without any intervention by the user. In fact, most users are unaware of the MTA; they just see their mail client.

The MTA reads the information in the To: section of the email message and determines the IP address of the recipient’s mail server. Then the MTA tries to open a connection to the recipient’s server through a TCP/IP port, typically port 25. DNS, the Domain Name System, plays a role in mail deliver, too.

MTAs query a domain’s DNS mail exchanger, or MX, record, to determine the host that is responsible for receiving mail for that domain. If the MTA on the sending machine can establish a connection to the destination MTA, it transmits the message using the Simple Message Transfer Protocol (SMTP).

In some cases, the message might not be immediately deliverable, so the sending MTA will store in a local queue and attempt retransmission after a set amount of time. In other cases, the receiving MTA might refuse delivery, causing the message to bounce and be returned to the sender’s MUA. Assuming that all goes well, the receiving MTA adds header information to the message.

This header contains information for tracking the message and ensuring that it is delivered. Finally, the receiving MTA passes the message to yet another program, the mail delivery agent, for delivery to the recipient’s mailbox.

N OT E

The default MTA installed on your Fedora Core or RHEL system is called

Sendmail. You can change this, as described later in this chapter.

Mail Delivery Agent (MDA)

After the MDA (sometimes referred to as a local delivery agent, or LDA) receives the message from the MTA, it stores the new message in the recipient’s mailbox file. The mailbox file, known traditionally as the mail spool, is almost always identified by the recipient’s username. One popular MDA on Fedora Core and

RHEL systems is named procmail. Ordinarily, the location of the user’s mailbox file is /var/spool/mail/username. In some cases, the user’s mailbox file will be a file or directory in the user’s home directory. Procmail isn’t the only possible MDA. Users who rely on POP or IMAP clients to retrieve their email ordinarily don’t use procmail. Rather the POP or IMAP client is itself the MDA.

28_599496 ch21.qxd 8/30/05 7:29 PM Page 470

470 Chapter 21

WHY IS IT CALLED BIFF?

Mail notification tools are called biffs because the original BSD mail

notification tool was a utility named biff. The BSD biff utility was in turn

named after a dog that chased frisbees in the halls at the University of

California (Berkeley) during the development of 4.2BSD. A legend claimed

that the dog would also bark whenever the mailman arrived, but biff’s

author denies this (see the biff entry in the Jargon File (version 4.4.7)), http://catb.org/~esr/jargon//html/B/biff.html

.

The next step in the process is optional. Some users (and many MUAs) provide some sort of visual or audible notification that new mail has arrived. Classically, these programs were known as biffs, for example, the eponymously named biff; xbiff, an X-based version; and tknewsbiff, a Tk-based biff that tells when new Usenet news arrives. Some biffs play a sound when new mail arrives, others display an icon of a full mailbox, and still others increment an on-screen counter showing the number of new or unread messages.

Even the lowly shell invokes the biff mail notifier, checking your mailbox file once a minute. If new mail has arrived, the shell displays a message just before it displays the next system prompt. It won’t interrupt a program you’re running. You can adjust how frequently the mail notifier checks and even which mailbox files to watch. See the biff man page (man biff) for the specifics.

The last step of email delivery occurs when the message recipient reads the message using her own MUA. Kind of anticlimactic, eh?

Introducing SMTP

In the section describing the MTA, you learned that messages are sent between

MTAs using SMTP. SMTP is the TCP/IP protocol for transferring email messages between computers on a network. SMTP specifies message movement between MTAs by the path the message takes. It is sometimes described as a

store-and-forward protocol because messages transmitted via SMTP don’t necessarily go directly from the sender’s MTA to the recipient’s MTA. Rather, network conditions and other considerations (not relevant here) might cause email messages to pass through other MTAs on other network computers.

These intermediate MTAs briefly store the message before forwarding it to another MTA or to a gateway that sends it to an MTA on another network.

The SMTP protocol can transfer only ASCII text. It can’t handle fonts, colors, graphics, or attachments. If you want to be able to send these items, you need to add another protocol to SMTP, MIME. MIME stands for Multipurpose Internet Mail Extensions. MIME is implemented on top of the SMTP protocol and

28_599496 ch21.qxd 8/30/05 7:29 PM Page 471

Configuring Mail Services 471

enables you to add colors, sounds, and graphics to your messages and still deliver them via SMTP. For MIME to work, you must have a MIME-compliant

MUA (most are).

If it isn’t clear yet, SMTP (with or without MIME) has a major shortcoming: it assumes that the sending and receiving MTAs are always connected to the

Internet. What happens when this assumption fails, say, for users who have dial-up Internet access? Enter POP, the Post Office Protocol.

Understanding POP3

Two other protocols are part of the email process: Post Office Protocol version

3, known as POP3, and Internet Message Access Protocol version 4, known as

IMAP4. POP3 was developed to solve the problem of what happens to messages when the recipient is not connected to the network. POP3 runs on a server that is connected to a network and that continuously sends and receives mail. The POP3 server stores any messages it receives until the message recipients request them.

Without POP3 (or IMAP), and MUA and MTA can’t communicate. That is, if you want to read your mail, you need POP3 (or IMAP) to retrieve messages that arrive at your MTA while you’re offline. POP3 uses the MTA’s storage to hold messages until they are requested. When users want to check their email, they connect to the POP3 server and retrieve messages that were stored by the server. After retrieval, the messages are stored locally (that is, locally to the

MUA) and you can use the MUA on your PC to read them at your leisure. Of course, your MUA has to understand the POP3 to be able to communicate with the POP3 server, but most MUAs speak fluent POP3 these days so this is rarely a problem. The messages you retrieve to your PC are then typically removed from the server.

What happens if users don’t want to remove their email from the server and instead want to access their email from any given PC? Why, they use Internet

Message Access Protocol, of course!

Understanding IMAP4

The Internet Message Access Protocol version 4 (IMAP4) provides much more sophisticated email-handling functionality than SMTP or POP3 do. IMAP4 has more features. IMAP4 enables you to store email on a networked mail server, just as POP3 does. The difference is that POP3 requires you to download your email before your MUA reads it, whereas IMAP4 enables your email to reside permanently on a remote server, from which you can access your mail. And you can do so from your office, your home, your PDA, your cell phone, or anywhere else. Your MUA must understand IMAP4 to retrieve messages from an

IMAP4 server.

28_599496 ch21.qxd 8/30/05 7:29 PM Page 472

472 Chapter 21

WHEN EMAIL PROBLEMS HAPPEN

Email gets lost in transport about as often as the dog eats your homework. This achievement is quite impressive when you consider the volume of email sent each day. On occasion, email messages get garbled or misrouted, just as a post office sometimes does with snail mail. Email can become garbled or lost due to lightning storms and other events that disrupt power supplies. Any network that is using unshielded 10Base-T cable is more susceptible to email interruptions because the cabling is not protected against atmospheric power disturbances such as lightning. Luckily, this issue is becoming less important as cabling standards improve. However, it is always a good idea to install a surge protector on your system to protect yourself from damage caused by fluctuations in the power supply.

Power failure and electrical interference notwithstanding, however, most email problems are the result of user or system administrator error. For example, the user may type an incorrect email address. Misconfiguring an email server causes email problems. Make sure that mailboxes sit in the right directory for your distribution.

If you add file system quotas to mailboxes, be aware that at some point, users may not be able to receive new messages until they (or you) clean up the mail files. Quotas are especially an issue for IMAP users. POP3 and file system quotas intersect at the user’s home directory, where as IMAP4 and file system quotas meet at the mail spool on the server. If a POP3 user goes over quota, simply deleting unnecessary files will allow additional email to be downloaded.

If an IMAP4 user goes over quota, it might not even be possible for that user to connect to the server to delete messages. Worse, until the quota issue is solved, the over-quota user’s mail will bounce because the mailbox is full.

C A U T I O N

POP3 and IMAP4 don’t interoperate. While there are email clients and servers that speak both protocols, you can’t use a POP3 client to communicate with an IMAP4 server or an IMAP4 client to communicate with a

POP3 server. When you configure an email server, you must decide whether your users need POP3 or IMAP4 functionality (or both). IMAP4 servers usually require much more disk space than POP3 servers because the email remains on the mail server unless the users or system administrator delete it.

Configuring Sendmail

A number of mail transport agents are available for Red Hat Enterprise Linux, including Sendmail, Postfix, and Qmail. The most widely used MTA is Sendmail, which is the default MTA on Fedora Core and RHEL systems. Postfix is

28_599496 ch21.qxd 8/30/05 7:29 PM Page 473

Configuring Mail Services 473

growing in popularity and is considerably easier to configure, so you will learn how to make it the default MTA in the section titled “Configuring Postfix.”

Before you begin configuring Sendmail, be sure it’s installed. It probably is, because the installation program installs Sendmail. But just to be sure, check it out. The following example shows how to check using the rpmquery command. The output shows not only that Sendmail is installed, but which version of Sendmail is installed:

# rpmquery -a | grep sendmail sendmail-cf -8.13.4-1.1

sendmail-doc-8.13.4-1.1

sendmail-devel-8.13.4-1.1

sendmail-8.13..4-1.1

The version numbers you see might be slightly different.

You’ll need at least the sendmail package. If you intend to perform any sort of Sendmail reconfiguration, you’ll want the sendmail-cf package, too. If you want to know more about Sendmail than this chapter tells you, the sendmaildoc package is handy. Unless you are doing Sendmail development work, though, you probably won’t need the sendmail-devel package. If Sendmail isn’t installed install it before proceeding. If Sendmail is installed, make sure that it starts at boot time. You can use the following chkconfig command to verify this:

# chkconfig --list sendmail sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off

In the example, the sendmail service, which controls the Sendmail MTA, will start in run levels 2, 3, 4, and 5 and stop in run levels 0, 1, and 6. If you don’t see this type of output, use the following chkconfig command to correct it:

# chkconfig --levels 0123456 sendmail off

# chkconfig --levels 2345 sendmail on

Finally, ensure that Sendmail is running and start it if it isn’t. You have several ways to check whether Sendmail is running. Pick your favorite. The following command uses ps and pidof to query the process table for running

Sendmail instances:

# ps uw -p $(pidof sendmail)

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 3706 0.0 0.6 8652 3292 ? Ss 22:45 0:00 sendmail: accepti ng connections smmsp 3714 0.0 0.5 7704 2580 ? Ss 22:45 0:00 sendmail: Queue r [email protected]:00:00 for /var/spool/clientmqueue

28_599496 ch21.qxd 8/30/05 7:29 PM Page 474

474 Chapter 21

Notice that the TTY fields are ?, indicating that the sendmail processes are not associated with a terminal. This usually means that the process is running as daemon, which is the case with Sendmail. If you don’t see output indicating that Sendmail is running, execute the following command to start Sendmail:

# service sendmail start

Starting sendmail: [ OK ]

Starting sm-client: [ OK ]

Another technique you can use is to telnet to localhost, port 25. If Sendmail is running, you’ll see something resembling the following:

# telnet localhost 25

Trying 127.0.0.1...

Connected to localhost.localdomain (127.0.0.1).

Escape character is ‘^]’.

220 bookbeast.example.com ESMTP Sendmail 8.13.1/8.13.1; Sat, 12 Mar 2005 22:51:

43 -0500

QUIT

Type QUIT to exit the session. This output means that Sendmail is running and responding to incoming SMTP sessions. On the other hand, if the output looks like the following, Sendmail isn’t running and you need to start it using the command shown earlier.

# telnet localhost 25

Trying 127.0.0.1...

telnet: connect to address 127.0.0.1: Connection refused telnet: Unable to connect to remote host: Connection refused

Once you know that Sendmail is installed and running, you are ready to start configuring it.

Configuring Sendmail

Many system administrators think that Sendmail is difficult to configure. If you look at its configuration file, /etc/mail/sendmail.cf, this might seem to be the case. However, Fedora Core and RHEL install a default Sendmail configuration file that works for most sites.

If you need to edit the configuration file at all, you may need to make only a couple of minor changes. Here are the key lines a Red Hat system administrator might want to edit in /etc/mail/sendmail.cf. The line in question begins with the uppercase letters DS and occurs near line 100. The following example specifies the host named mailbeast.example.com as a mail relay host.

28_599496 ch21.qxd 8/30/05 7:29 PM Page 475

Configuring Mail Services 475

# “Smart” relay host (may be null)

DS

Change the line to define the name of the mail relay host. The mail relay host is the name of the computer that sends and receives mail on your network.

There should not be any space between DS and the hostname.

# “Smart” relay host (may be null)

DSmailbeast.example.com

Fortunately, you do not have to be a Sendmail expert to perform most configuration chores. For all but the most unusual or extreme mail system configurations, all you need is a copy of the predefined configuration files in

/etc/mail

, sendmail.mc. The basic procedure is to modify sendmail.mc

for your own needs, regenerate /etc/mail/sendmail.cf using the m4 macro processor, as explained in a moment, and then test your configuration.

This method enables you to make incremental changes, minimizing the risk of major problems. Fedora Core and RHEL ship with a generic Sendmail configuration file (/etc/mail/sendmail.cf).

N OT E

Be sure to install the sendmail-cf package if it is not already

installed because it contains the m4 macro files needed for configuring

Sendmail using the m4 method described in the next section.

The m4 Macro Processor

What is a macro? A macro is a symbolic name for a long string of characters, much like a keyboard macro is a shorthand way to type a long series of keystrokes. Sendmail rules are generated from the macros in Sendmail macro files.

The location of the generic Sendmail macro file for Red Hat is /etc/mail

/sendmail.mc

. In addition, Sendmail’s own macro files are stored in a set of subdirectories in /usr/share/sendmail-cf. The rules in the Sendmail macro file generate the default Sendmail configuration file, /etc/mail

/sendmail.cf

. The m4 utility is a macro processor that reads the macro file and generates the configuration file.

An example of a macro in /etc/mail/sendmail.mc is the OSTYPE macro that identifies the operating system. Remember that Sendmail runs on many different operating systems, not just UNIX and Linux. On a Linux system, if you look at Sendmail’s macro file, you see the following line, which tells Sendmail which operating system it’s running on so that Sendmail runs properly:

OSTYPE(`linux’)dnl

28_599496 ch21.qxd 8/30/05 7:29 PM Page 476

476 Chapter 21

On Linux, the OSTYPE macro comes predefined so that you don’t need to worry about it. The dnl token introduces an m4-style comment, which causes m4 to stop processing input until it encounters the end of the line.

The good news, though, is that you needn’t worry about the intricacies of m4. The sendmail-cf package installs a Makefile in /etc/mail that you can use to regenerate your sendmail.cf file. If you really want complete, technical information about the macro file and how it works, read the

/usr/share/sendmail.cf/README file.

N OT E

The default sendmail configuration does not listen to the network

for incoming connections. Be sure to read the comment in /etc/mail

/sendmail.mc

for a description of setting this parameter.

Understanding and Managing the Mail Queue

Sometimes email messages don’t go out immediately and instead remain in one of the originating MTA’s outgoing mail queues. The reasons for the delay can vary. Perhaps your network is down. Maybe your intranet’s connection to the Internet is sporadic. The recipient’s MTA might be unavailable. Whatever the reason, users can continue to compose email with their MUAs. When they send their messages, Sendmail puts the message into the mail queue and keeps trying to send the message at intervals defined in the Sendmail configuration file or passed as a command-line parameter to the Sendmail daemon when it starts. You can find out what these intervals are by checking the initialization script that starts Sendmail.

The following listing shows the file /etc/sysconfig/sendmail.

DAEMON=yes

QUEUE=1h

The line beginning with QUEUE defines the retry interval to retry as one hour

(1h). You can specify the interval in h (hours), m (minutes), or s (seconds).

Recent versions of Fedora Core and RHEL set the variable QUEUE to 1h. Some distributions hard-code the interval right into the Sendmail invocation, for example, sendmail -q1h.

Setting Up Aliases to Make Life Easier

Mail aliases are useful for creating distribution lists and for making access to users more convenient. For example, if people have trouble spelling someone’s name, you can create an alias with alternate spellings, so if someone misspells

28_599496 ch21.qxd 8/30/05 7:29 PM Page 477

Configuring Mail Services 477

the name, the mail still reaches the intended recipient. You can also alias a nonexistent user to a real user. For example, you could set up an alias, bubba, which redirects all mail intended for bubba to the real user kurt. The aliases file is usually /etc/aliases. The following example contains entries for the following:

■■

System aliases for mailer-daemon and postmaster, which are required by RFCs for proper mail system operation.

■■

Redirections for pseudoaccounts such as lp, shutdown, and daemon.

Most of these are all aliased to root by default, but you can change them.

■■

User aliases, such as bubba.

■■

Distribution lists, such as authors.

# Basic system aliases -- these MUST be present.

mailer-daemon: postmaster postmaster: root

# General redirections for pseudo accounts.

daemon: root lp: root sync: root shutdown: root usenet: news ftpadm: ftp ftpadmin: ftp ftp-adm: ftp ftp-admin: ftp

# trap decode to catch security attacks decode: root

# Person who should get root’s mail root: kurt

#Users bubba: kurt

#Distribution lists terry,kurt: authors

To create an entry in the aliases file, use your favorite editor. Each entry consists of the username, followed by a colon, followed by some sort of white space, followed by the alias. Multiple usernames can be specified on the left

28_599496 ch21.qxd 8/30/05 7:29 PM Page 478

478 Chapter 21

side of the colon to create a primitive distribution list. After you save the file, you must run the newaliases command to make the changes take effect. This step is necessary because Sendmail looks at the binary file /etc/aliases.db to read alias information. The newaliases command reads your aliases text file and updates the binary file.

Using Other Sendmail Files and Commands

Glancing through your Sendmail configuration file shows that Sendmail uses several files and directories. The following list describes some of them.

■■

■■

/usr/sbin/sendmail

— The sendmail daemon executable image

mailq

— Shows the contents of the mail queue:

# mailq

/var/spool/mqueue is empty

Total requests: 0

■■

■■

/var/spool/mqueue

— The directory that holds the mail queue

/var/spool/mail

— The directory that holds users’ mail spools (the mailbox file), for example:

# ls -l /var/spool/mail/*

-rw-rw---- 1 terry mail 0 Jun 21 23:53 /var/spool/mail/terry

-rw-rw---- 1 kurt mail 554 Mar 14 21:48 /var/spool/mail/kurt

-rw------- 1 root root 6416 Jan 26 04:02 /var/spool/mail/root

T I P

For security, be sure that all mailbox files are readable and writable only

by their owners or the mail group.

■■

■■

■■

■■

/etc/mail/access

— Lists usernames, email addresses, domain names, and IP addresses not permitted to send mail to your system

(Yes, this file is counterintuitively named.)

/etc/mail/relay-domains

— Lists hosts (by name, partial names, or IP addresses) that are permitted to relay email through your system

/etc/mail/local-host-names

— Lists other names for your system

/etc/mail/virtusertable

— Maps email addresses to usernames on the system

28_599496 ch21.qxd 8/30/05 7:29 PM Page 479

Configuring Mail Services 479

Using the Postfix Mail Server

After you read this section, you might decide that Sendmail is far too complex and baffling, or at least more complicated than Postfix. While Sendmail might surpass Postfix in terms of configurability and features, this is only true of corner cases, that is, of extremely obtuse or unusual mail system configurations.

Postfix is used every day at sites that handle thousands and tens of thousands of messages per day, so Postfix probably provides all of the functionality you’ll need with a fraction of the frustration and aggravation that accompanies learning arcane configuration hieroglyphics.

The best part is that Postfix is fully compatible with Sendmail at the command level. For example, the command to regenerate the Postfix alias database is newaliases, the same name that Sendmail uses; the primary Postfix daemon is named sendmail, just like Sendmail. The similarity is deliberate, for Postfix was designed to be a high-performance, easier-to-use replacement for Sendmail. A single example might illustrate why it is easier to configure and use. As you learned in the previous section, the (unintuitive) Sendmail syntax for defining a mail relay host is:

DSrelay.example.com

Postfix’s syntax is eminently clearer: relayhost = relay.example.com

If this admittedly simple example doesn’t convince you that Postfix is easier to configure and use, consider this: it is Sendmail, not Postfix, that needs a meta-configuration-language (the m4 macros described earlier) to generate or modify configuration files.

Switching to Postfix

By default, Fedora Core and RHEL use Sendmail. Switching to Postfix is simple, but before doing so, stop Sendmail:

# service sendmail stop

You want to stop Sendmail before changing anything so that no incoming mail gets stuck in Sendmail’s queues before it is delivered. Of course, you should make sure that Postfix is installed:

$ rpmquery postfix postfix-2.2.2-2

28_599496 ch21.qxd 8/30/05 7:29 PM Page 480

480 Chapter 21

Install Postfix before proceeding. Otherwise, to make Postfix your MTA, click Main Menu ➪ Preferences ➪ More Preferences ➪ Mail Transport Agent

Switcher or execute the command system-switch-mail at a command prompt. Either way, you should see the dialog box shown in Figure 21-1.

Click the Postfix radio button and then click OK to save your change and close the dialog box. After the change is applied, you will see the confirmation message shown in Figure 21-2.

Click OK to proceed. The Mail Transport Agent Switcher does most of the heavy lifting for you, so most of what you need to do is tweak and fine-tune the Postfix configuration, as described in the next section.

Configuring Postfix

Postfix’s primary configuration file is /etc/postfix/main.cf. You will need to check or edit at least the following variables:

■■

The mydomain variable specifies your domain name: mydomain = example.com

■■

The myhostname variable identifies the local machine’s fully qualified domain name: myhostname = coondog.example.com

■■

The myorigin variable identifies the domain name appended to unqualified addresses (that is, usernames without the @example.com

goober attached): myorigin = $mydomain

■■

This causes all mail going out to have your domain name appended.

Thus, if the value of mydomain is possum_holler.com and your username is bubba, then your outgoing mail will appear to come from [email protected]_holler.com

.

The mydestination variable tells Postfix what addresses it should deliver locally. For a standalone workstation, which is a system that is connected directly to the Internet and that has some sort of domain name resolution running, you want mail to that machine and to localhost

(and/or localhost.$mydomain and/or localhost

.locadomain

) delivered locally, so the following entry should suffice: mydestination = $myhostname, localhost, localhost.$mydomain

Postfix supports a larger number of configuration variables than the four just listed, but these are the mandatory changes you have to make.

28_599496 ch21.qxd 8/30/05 7:29 PM Page 481

Configuring Mail Services 48