Linux Administration : A Beginner's Guide {McGraw Hill Professional; 5th Ed.} Soyinka Guide, 5 Edition
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 689
Linux Administration:
A Beginner’s Guide
Fifth Edition
WALE SOYINKA
New York Chicago San Francisco
Lisbon London Madrid Mexico City
Milan New Delhi San Juan
Seoul Singapore Sydney Toronto
Copyright © 2009 by The McGraw-Hill Companies. All rights reserved. Manufactured in the United States of America. Except as permitted under the United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by
any means, or stored in a database or retrieval system, without the prior written permission of the publisher.
0-07-154625-1
The material in this eBook also appears in the print version of this title: 0-07-154588-3.
All trademarks are trademarks of their respective owners. Rather than put a trademark symbol after every occurrence of a trademarked
name, we use names in an editorial fashion only, and to the benefit of the trademark owner, with no intention of infringement of the
trademark. Where such designations appear in this book, they have been printed with initial caps.
McGraw-Hill eBooks are available at special quantity discounts to use as premiums and sales promotions, or for use in corporate training programs. For more information, please contact George Hoare, Special Sales, at george_hoare@mcgraw-hill.com or (212) 9044069.
TERMS OF USE
This is a copyrighted work and The McGraw-Hill Companies, Inc. (“McGraw-Hill”) and its licensors reserve all rights in and to the
work. Use of this work is subject to these terms. Except as permitted under the Copyright Act of 1976 and the right to store and retrieve
one copy of the work, you may not decompile, disassemble, reverse engineer, reproduce, modify, create derivative works based upon,
transmit, distribute, disseminate, sell, publish or sublicense the work or any part of it without McGraw-Hill’s prior consent. You may
use the work for your own noncommercial and personal use; any other use of the work is strictly prohibited. Your right to use the work
may be terminated if you fail to comply with these terms.
THE WORK IS PROVIDED “AS IS.” McGRAW-HILL AND ITS LICENSORS MAKE NO GUARANTEES OR WARRANTIES AS
TO THE ACCURACY, ADEQUACY OR COMPLETENESS OF OR RESULTS TO BE OBTAINED FROM USING THE WORK,
INCLUDING ANY INFORMATION THAT CAN BE ACCESSED THROUGH THE WORK VIA HYPERLINK OR OTHERWISE,
AND EXPRESSLY DISCLAIM ANY WARRANTY, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McGraw-Hill and its licensors do not
warrant or guarantee that the functions contained in the work will meet your requirements or that its operation will be uninterrupted or
error free. Neither McGraw-Hill nor its licensors shall be liable to you or anyone else for any inaccuracy, error or omission, regardless
of cause, in the work or for any damages resulting therefrom. McGraw-Hill has no responsibility for the content of any information
accessed through the work. Under no circumstances shall McGraw-Hill and/or its licensors be liable for any indirect, incidental, special, punitive, consequential or similar damages that result from the use of or inability to use the work, even if any of them has been
advised of the possibility of such damages. This limitation of liability shall apply to any claim or cause whatsoever whether such claim
or cause arises in contract, tort or otherwise.
DOI: 10.1036/0071545883
“With the right knowledge, Linux can be clear and simple to understand. This
book presents the core fundamentals of Linux in a manner that is very logical
and easy to follow.”
—Greg Kurtzer, CTO, Infiscale, Inc.
“Wale continues to do a great job explaining complex information in a straightforward manner. All newcomers should start their Linux library with this book.”
—Ron Hudson, Senior Field Support Engineer, Intervoice, Inc.
“Wale Soyinka did a stellar job in the fourth edition and he was up for the challenge of making the fifth edition his own. It is with great pleasure I present the
fifth edition of Linux Administration: A Beginners Guide by Wale Soyinka. This
book barely resembles the 500-odd pages written nine years ago in the first edition, and it is without hesitation that I say his new words are for the better.”
—From the Foreword by Steve Shah, original author of
Linux Administration: A Beginner’s Guide
ABOUT THE AUTHOR
Wale Soyinka (Canada) is a systems/network engineering consultant with several years
experience in the field. He has written an extensive library of Linux administration training materials. In addition to being a co-author of the fourth edition of Linux Administration:
A Beginner’s Guide, he is the author of a projects lab manual—Microsoft Windows 2000 Managing Network Environments, which is part of the Microsoft certification series published
by Prentice Hall. Wale participates in several open source discussions and projects. His
latest project is at caffe*nix (www.caffenix.com) where he usually hangs out. caffe*nix is
possibly the world’s first (or only existing) brick-and-mortar store committed and dedicated to prompting and showcasing open source technologies and culture.
ABOUT THE CONTRIBUTING AUTHOR
Steve Shah (San Jose, California) is the chief technology officer (CTO) and co-founder
of Asyncast, where he leads the product strategy and engineering groups. Prior to starting Asyncast, Steve was the founder and principal of RisingEdge Consulting where he
provided strategic marketing services for a number of Silicon Valley infrastructure companies. To earn his chops, Steve grew to be a prominent player in network load balancing, application delivery controllers, and Secure Sockets Layer-virtual private network
(SSL-VPN) markets as the director of product management at NetScaler (acquired by
Citrix) and Array Networks. Before turning into a marketing droid who is eerily comfortable at a Unix command prompt, Steve was a senior software engineer and systems
administrator at numerous companies. Steve holds a bachelor of science (BS) in computer science with a minor in creative writing and a master in science (MS) in computer
science from University of California Riverside.
ABOUT THE TECHNICAL EDITOR
Dr. Ibrahim Haddad is director of technology at Motorola, Inc. and is responsible for
defining and developing the requirements for Motorola’s open source initiatives. Prior
to Motorola, Dr. Haddad managed the carrier-grade Linux and Mobile Linux Initiatives
at the Open Source Development Lab (OSDL), which included promoting the development and adoption of Linux and open source software in the communications industry.
Prior to joining OSDL, Dr. Haddad was a senior researcher at the Research & Innovation Department of Ericsson’s Corporate Unit of Research. He is a contributing editor
for Linux Journal and Enterprise Open Source magazines. Haddad received his BS and
MS degrees in computer science from the Lebanese American University, and his PhD
in computer science from Concordia University in Montreal, Canada. In 2000, he was
awarded by Concordia University both the J.W. McConnell Memorial Graduate Fellowship, and the Concordia University 25th Anniversary Fellowship, in recognition for
academic excellence. In 2007, he was the winner of the Big Idea Innovation Award in
Recognition of Leadership and Vision at Motorola, Inc.
Copyright © 2009 by The McGraw-Hill Companies. Click here for terms of use.
For more information about this title, click here
CONTENTS
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xx
xxi
xxii
Part I
Installing Linux as a Server
▼ 1 Technical Summary of Linux Distributions . . . . . . . . . . . . . . . . . . . . . . . .
Linux—The Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What Is Open Source Software and GNU All About? . . . . . .
What Is the GNU Public License? . . . . . . . . . . . . . . . . . . . . .
The Advantages of Open Source Software . . . . . . . . . . . . . . . . . . .
Understanding the Differences Between Windows and Linux . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
▼ 2 Installing Linux in a Server Configuration . . . . . . . . . . . . . . . . . . . . . . .
Hardware and Environmental Considerations
Server Design . . . . . . . . . . . . . . . . . . . . . . . . . .
Uptime . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dual-Booting Issues . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
4
5
7
8
9
14
15
16
16
18
18
v
vi
Linux Administration: A Beginner’s Guide
Methods of Installation. . . . . . . . . .
Installing Fedora . . . . . . . . . . . . . . .
Project Prerequisites. . . . . . . .
Carrying Out the Installation.
Initial System Configuration .
Installing Ubuntu Server . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
20
20
21
36
37
41
▼ 3 Managing Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
44
47
47
48
The RPM Package Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Debian Package Management System . . . . . . . . . . . . . . . . . .
APT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Managing Software Using RPM . . . . . . . . . . . . . . . . . . . . . . . . . . .
Querying for Information the RPM Way
(Getting to Know One Another) . . . . . . . . . . . . . . . . . . . . .
Installing with RPM (Moving In Together) . . . . . . . . . . . . .
Uninstalling Software with RPM (Ending the Relationship) . .
Other Things You Can Do with RPM . . . . . . . . . . . . . . . . .
Software Management in Ubuntu . . . . . . . . . . . . . . . . . . . . . . . .
Querying for Information . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing Software in Ubuntu . . . . . . . . . . . . . . . . . . . . . . .
Removing Software in Ubuntu . . . . . . . . . . . . . . . . . . . . . .
GUI RPM Package Managers . . . . . . . . . . . . . . . . . . . . . . .
Compile and Install GNU Software . . . . . . . . . . . . . . . . . . . . . . .
Getting and Unpacking the Package . . . . . . . . . . . . . . . . . .
Looking for Documentation
(Getting to Know Each Other—Again) . . . . . . . . . . . . . . . .
Configuring the Package . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compiling the Package . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing the Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Testing the Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Common Problems when Building from Source Code . . . . . . . .
Problems with Libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . .
When There Is No configure Script . . . . . . . . . . . . . . . . . . .
Broken Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
51
54
55
58
58
59
59
60
62
62
64
64
65
66
66
67
67
68
68
68
69
Part II
Single-Host Administration
▼ 4 Managing Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What Exactly Constitutes a User?. . . . . . . . . . . . . . . . . . . . . . . . .
Where User Information Is Kept . . . . . . . . . . . . . . . . . . . . .
The /etc/passwd File . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
74
74
75
Contents
The /etc/shadow File . . . . . . . . . . . . . . . . . . . . . . . . . .
The /etc/group File . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User Management Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Command-Line User Management . . . . . . . . . . . . . . . .
GUI User Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Users and Access Permissions . . . . . . . . . . . . . . . . . . . . . . . .
Understanding SetUID and SetGID Programs . . . . . . .
Pluggable Authentication Modules (PAM) . . . . . . . . . . . . . .
How PAM Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PAM’s Files and Their Locations . . . . . . . . . . . . . . . . . .
Configuring PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The “Other” File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
“DOH! I Can’t Log In!” . . . . . . . . . . . . . . . . . . . . . . . . .
Debugging PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A Grand Tour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Users with useradd . . . . . . . . . . . . . . . . . . . . .
Creating Groups with groupadd . . . . . . . . . . . . . . . . . .
Modifying User Attributes with usermod . . . . . . . . . . .
Modifying Group Attributes with groupmod . . . . . . . .
Deleting Groups and Users with groupdel and userdel
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
▼ 5 The Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
An Introduction to BASH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Job Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pipes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Command-Line Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Filename Expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Environment Variables as Parameters . . . . . . . . . . . . . . . .
Multiple Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backticks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Documentation Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The man Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The texinfo System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Files, File Types, File Ownership, and File Permissions . . . . . . . .
Normal Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hard Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Symbolic Links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Block Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Character Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Named Pipes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
80
81
81
85
88
88
89
89
90
90
95
95
95
96
96
97
98
99
99
100
101
102
103
104
106
107
107
108
108
108
109
110
110
112
112
112
112
113
113
113
114
114
vii
viii
Linux Administration: A Beginner’s Guide
Listing Files: ls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Ownership: chown . . . . . . . . . . . . . . . . . . . . . . . . .
Change Group: chgrp . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change Mode: chmod . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File Management and Manipulation . . . . . . . . . . . . . . . . . . . . . .
Copy Files: cp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Move Files: mv. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Link Files: ln. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Find a File: find . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File Compression: gzip . . . . . . . . . . . . . . . . . . . . . . . . . . .
bzip2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create a Directory: mkdir . . . . . . . . . . . . . . . . . . . . . . . . .
Remove a Directory: rmdir . . . . . . . . . . . . . . . . . . . . . . . .
Show Present Working Directory: pwd . . . . . . . . . . . . . . .
Tape Archive: tar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Concatenate Files: cat. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Display a File One Screen at a Time: more. . . . . . . . . . . . .
Disk Utilization: du . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Show the Directory Location of a File: which . . . . . . . . . .
Locate a Command: whereis . . . . . . . . . . . . . . . . . . . . . . .
Disk Free: df . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Synchronize Disks: sync . . . . . . . . . . . . . . . . . . . . . . . . . .
Moving a User and Its Home Directory . . . . . . . . . . . . . . . . . . .
List Processes: ps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Show an Interactive List of Processes: top . . . . . . . . . . . . .
Send a Signal to a Process: kill . . . . . . . . . . . . . . . . . . . . . .
Miscellaneous Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Show System Name: uname . . . . . . . . . . . . . . . . . . . . . . .
Who Is Logged In: who . . . . . . . . . . . . . . . . . . . . . . . . . . .
A Variation on who: w . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Switch User: su . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
emacs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
joe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
pico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
▼ 6 Booting and Shutting Down. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Boot Loaders . . . . . .
GRUB . . . . . . .
LILO. . . . . . . .
Bootstrapping
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
114
115
116
116
119
119
120
120
121
121
122
122
123
123
123
125
126
126
127
127
127
128
128
131
133
134
135
135
136
136
136
137
137
138
138
139
139
140
141
142
142
152
152
Contents
The init Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
rc Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Writing Your Own rc Script . . . . . . . . . . . . . . . . . . . . . . . .
Enabling and Disabling Services . . . . . . . . . . . . . . . . . . . . . . . .
Disabling a Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Odds and Ends of Booting and Shutting Down . . . . . . . . . . . . .
fsck! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Booting into Single-User (“Recovery”) Mode . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
153
154
155
159
162
162
163
163
164
▼ 7 File Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
165
166
166
167
168
169
169
169
176
177
178
178
179
180
190
192
The Makeup of File Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . .
i-Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Superblocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ext3 and ReiserFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Which File System to Use? . . . . . . . . . . . . . . . . . . . . . . . .
Managing File Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mounting and Unmounting Local Disks . . . . . . . . . . . . . .
Using fsck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding a New Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overview of Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Traditional Disk- and Partition-Naming Conventions . . .
Volume Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating Partitions and Logical Volumes . . . . . . . . . . . . .
Creating File Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
▼ 8 Core System Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The init Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
upstart: Die init. Die Now!. . . . . . . . . . . . . . . . . . . . . . . . .
The /etc/inittab File . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xinetd and inetd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The /etc/xinetd.conf File . . . . . . . . . . . . . . . . . . . . . . . . .
Examples: A Simple Service Entry and
Enabling/Disabling a Service . . . . . . . . . . . . . . . . . . . . . .
The Logging Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Invoking rsyslogd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the Logging Daemon . . . . . . . . . . . . . . . . . . . . . . .
Log Message Classifications . . . . . . . . . . . . . . . . . . . . . . .
Format of /etc/rsyslog.conf . . . . . . . . . . . . . . . . . . . . . . . .
The cron Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The crontab File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Editing the crontab File . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
193
194
195
196
198
200
205
208
208
208
210
211
216
216
218
218
ix
x
Linux Administration: A Beginner’s Guide
▼ 9 Compiling the Linux Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What Exactly Is a Kernel? . . . . . . . . . . . . . .
Finding the Kernel Source Code. . . . . . . . .
Getting the Correct Kernel Version . .
Unpacking the Kernel Source Code . .
Building the Kernel . . . . . . . . . . . . . . . . . .
Preparing to Configure the Kernel . .
Kernel Configuration . . . . . . . . . . . . .
Compiling the Kernel . . . . . . . . . . . .
Installing the Kernel . . . . . . . . . . . . .
Booting the Kernel . . . . . . . . . . . . . . .
The Author Lied—It Didn’t Work! . .
Patching the Kernel . . . . . . . . . . . . . . . . . .
Downloading and Applying Patches.
Summary . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
▼ 10 Knobs and Dials: proc and SysFS File Systems . . . . . . . . . . . . . . . . . .
What’s Inside the /proc Directory? . .
Tweaking Files Inside of /proc .
Some Useful /proc Entries . . . . . . . . .
Enumerated /proc Entries . . . . .
Common proc Settings and Reports . .
SYN Flood Protection . . . . . . . .
Issues on High-Volume Servers .
Debugging Hardware Conflicts .
SysFS. . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
221
222
224
224
225
225
227
228
231
233
235
235
236
237
239
241
242
243
244
246
247
248
249
249
249
252
Part III
Security and Networking
▼ 11 TCP/IP for System Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Layers . . . . . . . . . . . . . . . . . . . . . . .
TCP/IP Model and the OSI Model
Headers . . . . . . . . . . . . . . . . . . . . . . . . .
Ethernet . . . . . . . . . . . . . . . . . . . . .
IP (IPv4) . . . . . . . . . . . . . . . . . . . . .
TCP . . . . . . . . . . . . . . . . . . . . . . . .
UDP . . . . . . . . . . . . . . . . . . . . . . . .
A Complete TCP Connection . . . . . . . . .
Opening a Connection . . . . . . . . . .
Transferring Data . . . . . . . . . . . . . .
Closing the Connection . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
255
256
259
263
264
265
268
272
273
273
274
275
Contents
How ARP Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The ARP Header: ARP Works with Other Protocols, Too! . . .
Bringing IP Networks Together . . . . . . . . . . . . . . . . . . . . . . . . .
Hosts and Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Subnetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Netmasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Static Routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dynamic Routing with RIP . . . . . . . . . . . . . . . . . . . . . . . .
Digging into tcpdump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A Few General Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Graphing Odds and Ends . . . . . . . . . . . . . . . . . . . . . . . . .
IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IPv6 Address Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IPv6 Address Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IPv6 Backward Compatibility . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
276
277
278
278
279
280
282
284
289
289
293
294
294
295
295
296
▼ 12 Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
299
300
301
303
304
307
309
311
314
314
317
317
Modules and Network Interfaces . . . . . . . . . . . . . . . . . . . . . . . .
Network Device Configuration Utilities (ip and ifconfig) . . .
IP Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting Up NICs at Boot Time . . . . . . . . . . . . . . . . . . . . . .
Managing Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simple Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Displaying Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A Simple Linux Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routing with Static Routes . . . . . . . . . . . . . . . . . . . . . . . .
How Linux Chooses an IP Address . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
▼ 13 The Linux Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How Netfilter Works . . . . . . . . . . . . . . . . . .
A NAT Primer . . . . . . . . . . . . . . . . . . .
NAT-Friendly Protocols . . . . . . . . . . . .
Chains . . . . . . . . . . . . . . . . . . . . . . . . .
Installing Netfilter . . . . . . . . . . . . . . . . . . . .
Enabling Netfilter in the Kernel. . . . . .
Required Kernel Options . . . . . . . . . . .
Optional but Sensible Kernel Options .
Other Options . . . . . . . . . . . . . . . . . . .
Configuring Netfilter . . . . . . . . . . . . . . . . . .
Saving Your Netfilter Configuration . .
The iptables Command . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
319
320
321
324
325
328
328
329
329
330
331
331
333
xi
xii
Linux Administration: A Beginner’s Guide
Cookbook Solutions . . . . . . . . . . . . .
Rusty’s Three-Line NAT . . . . .
Configuring a Simple Firewall.
Summary . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
340
341
342
344
▼ 14 Local Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
345
347
347
349
350
351
352
354
354
357
358
358
358
359
359
359
360
360
Common Sources of Risk . . . . . . . . . . . .
SetUID Programs . . . . . . . . . . . . . .
Unnecessary Processes. . . . . . . . . .
Picking the Right Runlevel to Boot Into .
Non-human Accounts . . . . . . . . . . . . . .
Limited Resources . . . . . . . . . . . . . . . . .
Mitigating Risk . . . . . . . . . . . . . . . . . . . .
Using Chroot . . . . . . . . . . . . . . . . .
SELinux . . . . . . . . . . . . . . . . . . . . .
AppArmor . . . . . . . . . . . . . . . . . . . . . . .
Monitoring Your System. . . . . . . . . . . . .
Logging . . . . . . . . . . . . . . . . . . . . .
Using ps and netstat . . . . . . . . . . .
Using df . . . . . . . . . . . . . . . . . . . . .
Automated Monitoring . . . . . . . . .
Mailing Lists . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
▼ 15 Network Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TCP/IP and Network Security . . . . . . . . . . . . . . . . . . . . . . . . . .
The Importance of Port Numbers . . . . . . . . . . . . . . . . . . .
Tracking Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the netstat Command . . . . . . . . . . . . . . . . . . . . . . .
Security Implications of netstat’s Output . . . . . . . . . . . . .
Binding to an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Shutting Down Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Shutting Down xinetd and inetd Services . . . . . . . . . . . . .
Monitoring Your System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Making the Best Use of syslog . . . . . . . . . . . . . . . . . . . . . .
Monitoring Bandwidth with MRTG . . . . . . . . . . . . . . . . .
Handling Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Trust Nothing (and No One) . . . . . . . . . . . . . . . . . . . . . . .
Change Your Passwords . . . . . . . . . . . . . . . . . . . . . . . . . .
Pull the Plug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Security Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wireshark/tcpdump . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
361
362
362
363
363
364
365
366
366
368
368
370
370
370
371
371
371
371
372
373
Contents
Part IV
Internet Services
▼ 16 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Hosts File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Understanding How DNS Works . . . . . . . . . . . . . . . . . . . . . . . .
Domain and Host Naming Conventions . . . . . . . . . . . . . .
Subdomains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The in-addr.arpa Domain . . . . . . . . . . . . . . . . . . . . . . . . .
Types of Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing a DNS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Understanding the BIND Configuration File . . . . . . . . . .
The Specifics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring a DNS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining a Primary Zone in the named.conf File . . . . . . .
Defining a Secondary Zone in the named.conf File . . . . . .
Defining a Caching Zone in the named.conf File . . . . . . .
DNS Records Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SOA: Start of Authority . . . . . . . . . . . . . . . . . . . . . . . . . . .
NS: Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A: Address Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PTR: Pointer Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MX: Mail Exchanger . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CNAME: Canonical Name . . . . . . . . . . . . . . . . . . . . . . . .
RP and TXT: The Documentation Entries . . . . . . . . . . . . .
Setting Up BIND Database Files . . . . . . . . . . . . . . . . . . . . . . . . .
Breaking Out the Individual Steps . . . . . . . . . . . . . . . . . .
The DNS Toolbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
dig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nslookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
whois . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
nsupdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The rndc Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring DNS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the Client . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
▼ 17 FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Mechanics of FTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Client/Server Interactions . . . . . . . . . . . . . . . . . . . . . . . . .
377
378
379
379
382
383
383
385
387
388
391
391
392
393
394
394
395
396
396
397
397
398
398
400
404
404
406
407
408
408
409
410
410
412
413
415
416
416
xiii
xiv
Linux Administration: A Beginner’s Guide
Obtaining and Installing vsftpd . . . . . . . . . . . . . . .
Configuring vsftpd . . . . . . . . . . . . . . . . . . . .
Starting and Testing the FTP Server. . . . . . . .
Customizing the FTP Server . . . . . . . . . . . . . . . . . .
Setting Up an Anonymous-Only FTP Server .
Setting Up an FTP Server with Virtual Users
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
418
418
423
426
426
427
431
▼ 18 Apache Web Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
433
434
434
435
436
437
438
439
440
441
441
442
442
442
448
449
Understanding the HTTP Protocol . . . . . .
Headers . . . . . . . . . . . . . . . . . . . . . .
Ports . . . . . . . . . . . . . . . . . . . . . . . . .
Process Ownership and Security . . .
Installing the Apache HTTP Server . . . . .
Apache Modules . . . . . . . . . . . . . . .
Starting Up and Shutting Down Apache .
Starting Apache at Boot Time . . . . .
Testing Your Installation . . . . . . . . . . . . . .
Configuring Apache . . . . . . . . . . . . . . . . .
Creating a Simple Root-Level Page .
Apache Configuration Files . . . . . . .
Common Configuration Options . . .
Troubleshooting Apache. . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
▼ 19 SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Understanding SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rudimentary SMTP Details . . . . . . . . . . . . . . . . . . . . . . . .
Security Implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing the Postfix Server . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing Postfix via RPM in Fedora . . . . . . . . . . . . . . . . .
Installing Postfix via APT in Ubuntu . . . . . . . . . . . . . . . . .
Configuring the Postfix Server . . . . . . . . . . . . . . . . . . . . . . . . . .
The main.cf File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Checking Your Configuration . . . . . . . . . . . . . . . . . . . . . .
Running the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Checking the Mail Queue . . . . . . . . . . . . . . . . . . . . . . . . .
Flushing the Mail Queue . . . . . . . . . . . . . . . . . . . . . . . . . .
The newaliases Command . . . . . . . . . . . . . . . . . . . . . . . . .
Making Sure Everything Works. . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
451
452
452
454
455
455
456
458
459
461
462
462
462
462
462
463
Contents
▼ 20 POP and IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
POP and IMAP Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing the UW-IMAP and POP3 Server. . . . . . . . . . . . . . . . .
Installing UW-IMAP from Source . . . . . . . . . . . . . . . . . . .
Running UW-IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other Issues with Mail Services . . . . . . . . . . . . . . . . . . . . . . . . .
SSL Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Testing IMAP Connectivity with SSL . . . . . . . . . . . . . . . .
Availability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
▼ 21 The Secure Shell (SSH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Understanding Public Key Cryptography . . . . . . . . . . . . . . . . .
Key Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cryptography References . . . . . . . . . . . . . . . . . . . . . . . . .
Understanding SSH Versions and Distributions . . . . . . . . . . . .
OpenSSH and OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . .
Alternative Vendors for SSH Clients . . . . . . . . . . . . . . . . .
Installing OpenSSH via RPM in Fedora . . . . . . . . . . . . . .
Installing OpenSSH via APT in Ubuntu . . . . . . . . . . . . . .
Downloading, Compiling, and Installing OpenSSH from Source
Server Startup and Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . .
SSHD Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using OpenSSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Secure Shell (SSH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Secure Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OpenSSH Shell Tricks . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Secure Copy (SCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Secure FTP (SFTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Files Used by the OpenSSH Client . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
465
468
468
469
471
474
474
475
475
476
476
479
480
482
483
484
484
484
486
486
486
489
490
490
491
491
494
495
495
496
496
Part V
Intranet Services
▼ 22 Network File System (NFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Mechanics of NFS . . . . . . . . . . . . .
Versions of NFS . . . . . . . . . . . . . .
Security Considerations for NFS .
Mount and Access a Partition . . .
Enabling NFS in Fedora . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
501
502
503
504
504
505
xv
xvi
Linux Administration: A Beginner’s Guide
Enabling NFS in Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Components of NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kernel Support for NFS . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring an NFS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The /etc/exports Configuration File . . . . . . . . . . . . . . . . .
Configuring NFS Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The mount Command . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Soft vs. Hard Mounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cross-Mounting Disks . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Importance of the intr Option . . . . . . . . . . . . . . . . . . .
Performance Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Troubleshooting Client-Side NFS Issues . . . . . . . . . . . . . . . . . .
Stale File Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Permission Denied . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sample NFS Client and NFS Server Configuration . . . . . . . . . .
Common Uses for NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
506
507
508
508
508
512
513
515
515
516
516
517
517
517
518
520
520
▼ 23 Network Information Service (NIS) . . . . . . . . . . . . . . . . . . . . . . . . . . .
523
524
525
526
526
527
528
528
532
534
534
535
536
538
540
540
540
541
541
542
543
543
544
544
545
545
Inside NIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The NIS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . .
Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring the Master NIS Server . . . . . . . . . . . .
Establishing the Domain Name . . . . . . . . . . .
Starting NIS . . . . . . . . . . . . . . . . . . . . . . . . . .
Editing the Makefile . . . . . . . . . . . . . . . . . . .
Using ypinit . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring an NIS Client . . . . . . . . . . . . . . . . . . .
Editing the /etc/yp.conf File . . . . . . . . . . . . .
Enabling and Starting ypbind . . . . . . . . . . . .
Editing the /etc/nsswitch.conf File . . . . . . . . . . . .
NIS at Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Testing Your NIS Client Configuration . . . . .
Configuring a Secondary NIS Server . . . . . . . . . . .
Setting the Domain Name . . . . . . . . . . . . . . .
Setting Up the NIS Master to Push to Slaves .
Running ypinit . . . . . . . . . . . . . . . . . . . . . . . .
NIS Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using NIS in Configuration Files. . . . . . . . . .
Implementing NIS in a Real Network . . . . . . . . . .
A Small Network . . . . . . . . . . . . . . . . . . . . . .
A Segmented Network. . . . . . . . . . . . . . . . . .
Networks Bigger Than Buildings . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Contents
▼ 24 Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Mechanics of SMB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Usernames and Passwords . . . . . . . . . . . . . . . . . . . . . . . .
Encrypted Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Samba Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing Samba via RPM . . . . . . . . . . . . . . . . . . . . . . . . .
Installing Samba via APT. . . . . . . . . . . . . . . . . . . . . . . . . .
Samba Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Starting and Stopping Samba . . . . . . . . . . . . . . . . . . . . . .
Using SWAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting Up SWAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The SWAT Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Globals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Shares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Printers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a Share . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using smbclient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mounting Remote Samba Shares . . . . . . . . . . . . . . . . . . . . . . . .
Creating Samba Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Allowing Null Passwords . . . . . . . . . . . . . . . . . . . . . . . . .
Changing Passwords with smbpasswd . . . . . . . . . . . . . . .
Using Samba to Authenticate Against a Windows Server . . . . .
Troubleshooting SAMBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
▼ 25 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LDAP Basics . . . . . . . . . . . . . . . . .
LDAP Directory . . . . . . . . . .
Client/Server Model . . . . . .
Uses of LDAP. . . . . . . . . . . .
LDAP Terminologies . . . . . .
OpenLDAP . . . . . . . . . . . . . . . . . .
Server-Side Daemons . . . . . .
OpenLDAP Utilities . . . . . . .
Installing OpenLDAP . . . . . . . . . .
Configuring OpenLDAP . . . . . . .
Configuring slapd . . . . . . . .
Starting and Stopping slapd
Configuring OpenLDAP Clients .
Creating Directory Entries . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
547
548
548
549
549
550
551
552
553
554
554
556
557
557
557
557
558
558
558
560
563
563
564
564
565
567
567
569
570
570
571
572
572
573
573
574
574
576
577
580
581
581
xvii
xviii
Linux Administration: A Beginner’s Guide
Searching, Querying, and Modifying the Directory .
Using OpenLDAP for User Authentication . . . . . . .
Configuring the Server . . . . . . . . . . . . . . . . . .
Configuring the Client . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
583
584
584
586
587
▼ 26 Printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
589
590
591
591
591
593
594
595
600
600
600
600
601
601
602
603
603
604
604
605
Printing Terminologies . . . . . . . . . . . . . . .
The CUPS System . . . . . . . . . . . . . . . . . . .
Running CUPS . . . . . . . . . . . . . . . . .
Installing CUPS . . . . . . . . . . . . . . . .
Configuring CUPS . . . . . . . . . . . . . .
Adding Printers . . . . . . . . . . . . . . . . . . . .
Local Printers and Remote Printers .
Routine CUPS Administration . . . . . . . . .
Setting the Default Printer . . . . . . . .
Enabling and Disabling Printers . . .
Accepting and Rejecting Print Jobs .
Managing Printing Privileges . . . . .
Deleting Printers . . . . . . . . . . . . . . .
Managing Printers via the Web Interface .
Using Client-Side Printing Tools . . . . . . .
lpr. . . . . . . . . . . . . . . . . . . . . . . . . . .
lpq . . . . . . . . . . . . . . . . . . . . . . . . . .
lprm . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
▼ 27 DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Mechanics of DHCP . . . . . . . . . . . . . . . . . . . . .
The DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installing DHCP Software via RPM. . . . . . . . .
Installing DHCP Software via APT in Ubuntu
Configuring the DHCP Server . . . . . . . . . . . . .
A Sample dhcpd.conf File . . . . . . . . . . . . . . . .
The DHCP Client Daemon . . . . . . . . . . . . . . . . . . . .
Configuring the DHCP Client . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
▼ 28 Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Why Virtualize? . . . . . . . . . . . . .
Virtualization Concepts . . .
Virtualization Implementations .
QEMU . . . . . . . . . . . . . . . .
Xen . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
607
608
609
609
609
610
616
617
617
619
621
622
622
623
624
624
Contents
User-Mode Linux (UML) . . . . . . . . . . . . . . . . . . . . . . . . . .
Kernel-based Virtual Machines (KVM) . . . . . . . . . . . . . . .
VMware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Virtualbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Hyper-V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Kernel-based Virtual Machines (KVM) . . . . . . . . . . . . . . . . . . .
KVM Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
624
624
624
624
625
625
626
631
▼ 29 Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
633
634
634
635
636
637
637
639
640
640
646
646
Evaluating Your Backup Needs . . . . . . . . . . . . . . .
How Much Data? . . . . . . . . . . . . . . . . . . . . . .
What Kind of Media? . . . . . . . . . . . . . . . . . . .
How Much Network Throughput? . . . . . . . .
How Quickly Must the Data Be Recovered? .
What Kind of Tape Management? . . . . . . . . .
Manipulating the Tape Device with mt . . . . .
Command-Line Tools . . . . . . . . . . . . . . . . . . . . . . .
dump and restore. . . . . . . . . . . . . . . . . . . . . .
Miscellaneous Backup Solutions . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
▼
Index
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..............................................
647
xix
FOREWORD
I
n 1999, editor Jane Brownlow approached me to do a book on Linux.
The idea of writing my own book, start to finish, on an operating system I loved was so fantastic that the little detail of already being overcommitted with my work was merely a footnote. Lucky for me, my very
patient wife supported the endeavor and accepted this mistress, which
consumed my evenings the first few months we were married.
When talk of the second edition came up, my dear wife asked, “Aren’t you
overcommitted even more than you were during the first edition?” She was
right, yet I couldn’t let my dear book—which had done very well—go to someone else. And so, five months of nights and weekends slipped away as I updated
and rewrote large portions of the book. By the end of the exercise, I was tired but
pleased.
Fortunately for my sanity, a few years of marriage made my wife much more
direct when talk of the third and fourth editions came about. “No,” she said, “not
unless you can prove that you can do this without becoming a tired and cranky
old man.” She was right, and I recruited help as a result. My co-worker and friend
Steve Graham helped with the third edition, and Wale Soyinka of Linux Lab Manual
fame jumped in on the fourth.
When Jane asked, “Fifth edition?” a few months ago, I actually knew better.
With a two-year-old son, a new business, and a mere four to five hours of sleep
a night, with weekends officially off-limits to non-family activity, lest I become
“Uncle Daddy,” there simply wasn’t any time to beg, borrow, or steal away to make
a fifth edition happen. However, this time, there was no question about whether
Linux Administration: A Beginner’s Guide, a book that I hold dear, would be in good
hands. Wale Soyinka had done a stellar job in the fourth edition, and he was up
for the challenge of making the fifth edition his own. It was time to pass the baton.
It is with great pleasure that I present the fifth edition of Linux Administration:
A Beginner’s Guide by Wale Soyinka. This book barely resembles the 500-odd pages
written nine years ago in the first edition, and it is without hesitation that I say the
new words are for the better.
xx
Steve Shah
June 2008
Author, Linux Administration: A Beginner’s Guide
(1st through 4th editions)
Copyright © 2009 by The McGraw-Hill Companies. Click here for terms of use.
ACKNOWLEDGMENTS
T
he list of people whom I would like to acknowledge is rather long—
and as such, I will try to create a “catch all” that will reflect the
individuals and groups that I am referring to.
This simply includes everybody who has ever believed in me and provided
me with one opportunity or another to experience various aspects of my life
up to this point. You know who you are, and I thank you and remain forever
indebted to you.
I would like to dedicate this book to everyone who has contributed
to open source technologies and ideals in one form or another.
Without you, I would have nothing to write about in this book.
xxi
Copyright © 2009 by The McGraw-Hill Companies. Click here for terms of use.
INTRODUCTION
O
n October 5, 1991, Linus Torvalds posted this message to the newsgroup comp.os.minix:
Do you pine for the nice days of minix-1.1, when men were men and
wrote their own device drivers? Are you without a nice project and
just dying to cut your teeth on an OS you can try to modify for
your needs? Are you finding it frustrating when everything works
on minix? No more all-nighters to get a nifty program working?
Then this post might be just for you :-)
Linus went on to introduce the first cut of Linux to the world. Unbeknownst to
him, he had unleashed what was to become one of the world’s most popular and
disruptive operating systems. Seventeen years later, an entire industry has grown
up around Linux. And chances are, you’ve probably already used it (or benefitted
from it) in one form or another!
WHO SHOULD READ THIS BOOK
A part of the title of this book reads “A Beginner’s Guide”; this is mostly apt.
But what the title should say is “A Beginner’s to Linux Administration Guide,”
because we do make a few assumptions about you, the reader. (And we jolly well
couldn’t use that title because it was such a mouthful and not sexy enough.)
But seriously, we assume that you are already familiar with Microsoft Windows
servers at a “power user” level or better. We assume that you are familiar with the
terms (and some concepts) necessary to run a small- to medium-sized Windows
xxii
Copyright © 2009 by The McGraw-Hill Companies. Click here for terms of use.
Introduction
network. Any experience with bigger networks or advanced Windows technologies,
such as Active Directory, will allow you to get more from the book but is not required.
We make this assumption because we did not want to write a guide for dummies.
There are already enough books on the market that tell you what to click without telling you why; this book is not meant to be among those ranks. Furthermore, we did not
want to waste time writing about information that we believe is common knowledge for
power users of Windows. Other people have already done an excellent job of conveying
that information, and there is no reason to repeat that work here.
In addition to your Windows background, we assume that you’re interested in having more information about the topics here than the material we have written alone. After
all, we’ve only spent 30 to 35 pages on topics that have entire books devoted to them!
For this reason, we have scattered references to other books throughout the chapters. We
urge you to take advantage of these recommendations. No matter how advanced you
are, there is always something new to learn.
We feel that seasoned Linux system administrators can also benefit from this book
because it can serve as a quick how-to cookbook on various topics that may not be the
seasoned reader’s strong points. We understand that system administrators generally
have aspects of system administration that they like or loath. For example, backups is not
one of the author’s favorite aspects of system administration, and this is reflected in the
half a page we’ve dedicated to backups—just kidding, we’ve actually dedicated an entire
chapter to backups.
WHAT’S IN THIS BOOK?
Linux Administration: A Beginner’s Guide, is broken into five parts.
Part I: Installing Linux as a Server
Part I includes three chapters (Chapter 1, “Technical Summary of Linux Distributions”;
Chapter 2, “Installing Linux in a Server Configuration”; and Chapter 3, “Managing Software”) that give you a firm handle on what Linux is, how it compares to Windows in
several key areas, and how to install server-grade Fedora and Ubuntu Linux distributions. We end Part I with a chapter on how to install and manage software installed from
prepackaged binaries and source code. Ideally, this should be enough information to
get you started and help you draw parallels to how Linux works based on your existing
knowledge of Windows.
Part II: Single-Host Administration
Part II covers the material necessary to manage a stand-alone system (a system not requiring or providing any services to other systems on the network). While this may seem
useless at first, it is the foundation on which many other concepts are built, and these
concepts are essential to understand, even after a system is connected to a network.
xxiii
xxiv
Introduction
There are seven chapters in this part. Chapter 4, “Managing Users,” covers the information necessary on how to add, remove, and otherwise manage users. The chapter also
introduces the basic concepts of multiuser operation, permissions, etc. In Chapter 5, “The
Command Line,” we begin covering the basics of working with the Linux command line
so that you can become comfortable dropping out of the graphical environment provided by default. While it is possible to administer a system from within the graphical
desktop, the greatest power comes from being comfortable with both the command line
interface (CLI) and the graphical user interface (GUI). (This is true for Windows, too.
Don’t believe that? Open a command prompt, run netsh, and try to do what netsh
does in the GUI.).
Once you are comfortable with the CLI, you begin Chapter 6, “Booting and Shutting
Down,” which documents the entire booting and shutting down process. This includes
the necessary detail on how to start up services and properly shut them down during
these cycles so that you can reliably add new services later on in the book without any
difficulty.
Chapter 7, “File Systems,” continues with the basics of file systems—their organization, creation, and, most importantly, their management.
The basics of operation continue in Chapter 8, “Core System Services,” with coverage
of basic tools, such as xinetd for scheduling applications to run at specified times. xinetd
is the Linux equivalent of Windows’ svchost and rsyslog, which manage logging for all
applications in a unified framework. One may think of rsyslog as a more flexible version
of the Event Viewer.
We finish this section with Chapter 9, “Compiling the Linux Kernel,” and Chapter 10,
“Knobs and Dials: proc and SysFS File Systems,” which cover the kernel and kernel-level
tweaking through /proc and /sys. Kernel coverage documents the process of compiling
and installing your own custom kernel in Linux. This capability is one of the points that
gives Linux administrators an extraordinary amount of fine-grained control over how
their systems operate. The viewing of kernel-level configuration and variables through
the /proc and /sys file systems shown in Chapter 10 allows administrators to fine-tune
their kernel operation in what amounts to an arguably better and easier way than in the
Microsoft Windows world.
Part III: Security and Networking
Previous editions of this book had security and networking at the back. This was done
because at the time, the only real extensions to the book that were covered were advanced
networking concepts that don’t apply to most administrators. This has significantly
changed over the last few years. With the ongoing importance of security on the Internet,
as well as compliancy issues with Sarbanes Oxley and Health Insurance Portability and
Accountability Act (HIPAA), the use of Linux in scenarios that require high security has
risen dramatically. Thus, we decided to move coverage up before introducing networkbased services, which could be subject to network attacks.
We kick off this section with Chapter 11, “TCP/IP for System Administrators,”
which provides a detailed overview of Transmission Control Protocol/Internet Protocol (TCP/IP) in the context of what system administrators need to know. The chapter
Introduction
provides a lot of detail on how to use troubleshooting tools, like tcpdump, to capture
packets and read them back, as well as a step-by-step analysis of how TCP connections
work. These tools should enable you to effectively troubleshoot network peculiarities.
Chapter 12, “Network Configuration,” returns to administration issues by focusing
on basic network configuration (for both IPv4 and IPv6). This includes setting up IP
addresses, routing entries, etc. We extend past the basics in Chapter 13, “The Linux Firewall,” by going into advanced networking concepts and showing you how to build a
Linux-based firewall.
Chapter 14, “Local Security,” and Chapter 15, “Network Security,” discuss aspects
of system and network security in detail. They include Linux-specific issues as well as
general security tips and tricks so that you can better configure your system and protect
it against attacks.
Part IV: Internet Services
The remainder of the book is broken into two distinct parts: Internet and intranet services. We define Internet services as those that you may consider running on a Linux system exposed directly to the Internet. Examples of this include Web and Domain Name
System (DNS) services.
We start this section off with Chapter 16, “DNS.” In this section, we cover the information you need to know to install, configure, and manage a DNS server. In addition to
the actual details of running a DNS server, we provide a detailed background on how
DNS works and several troubleshooting tips, tricks, and tools.
From DNS we move on to Chapter 17, “FTP,” and cover the installation and care of
File Transfer Protocol (FTP) servers. Like the DNS chapter, we also include a background
on the FTP protocol itself and some notes on its evolution.
Chapter 18, “Apache Web Server,” moves on to what may be considered one of the
most popular uses of Linux today: running a Web server with the Apache Web server.
In this chapter, we cover the information necessary to install, configure, and manage the
Apache Web server.
Chapter 19, “SMTP,” and Chapter 20, “POP and IMAP,” dive into e-mail through the
setup and configuration of Simple Mail Transfer Protocol (SMTP), Post Office Protocol
(POP), and Internet Message Access Protocol (IMAP) servers. We cover the information
needed to configure all three, as well as show how they interact with one another. What
you may find a little different about this book from other books on Linux is that we have
chosen to cover the Postfix SMTP server instead of the classic Sendmail server, because
it provides a more flexible server with a better security record.
We end Part IV with Chapter 21, “The Secure Shell (SSH).” Knowing how to set up
and manage the SSH service is useful for almost any server environment—regardless of
the server’s primary function.
Part V: Intranet Services
We define intranet services as those that are typically run behind a firewall for internal
users only. Even in this environment, Linux has a lot to offer. We start off by looking
xxv
xxvi
Introduction
at NFS in Chapter 22, “Network File System (NFS).” NFS has been around for close to
20 years now and has evolved and grown to fit the needs of its users quite well. In this
chapter, we cover Linux’s NFS server capabilities, including how to set up both clients
and servers, as well as troubleshooting. From NFS, we move on to NIS in Chapter 23,
“Network Information Service (NIS).” NIS is typically deployed alongside NFS servers to
provide a central naming service for all users within a network. We pay special attention
to scaling issues and how you can make NIS work in a large user-base environment.
Chapter 24, “Samba,” continues the idea of sharing disks and resources with coverage of the Samba service. Using Samba, administrators can share disks, printing facilities
and provide authentication for Windows (and Linux) users without having to install any
special client software. Thus, Linux can become an effective server, able to support and
share resources between UNIX/Linux systems as well as Windows systems.
We revisit directory services in Chapter 25, “LDAP,” with coverage of Lightweight
Directory Access Protocol (LDAP) and how administrators can use this standard service
for providing a central (or single) user database (directory) for use amongst heterogeneous operating systems.
In Chapter 26, “Printing,” we take a tour of the Linux printing subsystem. The printing subsystem, when combined with Samba, allows administrators to support seamless
printing from Windows desktops. The result is a powerful way of centralizing printing
options for Linux, Windows, and even Mac OS X users on a single server.
Chapter 27, “DHCP,” covers another common use of Linux systems: Dynamic Host
Configuration Protocol (DHCP) servers. In this chapter, we cover how to deploy the ISC
DHCP server, which offers a powerful array of features and access controls that are not
traditionally exposed in graphical-based DHCP administration tools.
Chapter 28, “Virtualization,” is a new chapter. We discuss the basic virtualization concepts and briefly cover some of the popular virtualization technologies in Linux. We cover
the kernel-based virtual machine (KVM) implementation in detail, with examples.
We end with Chapter 29, “Backups.” Backups are arguably one of the most critical
pieces of administration. Linux based systems support several methods of providing
backups that are easy to use and readily usable by tape drives and other media. We discuss some of the methods and explain how they can be used as part of a backup schedule. In addition to the mechanics of backups, we discuss general backup design and how
you can optimize your backup system.
Updates and Feedback
While we hope that we publish a book with no errors, this isn’t always possible. You can
find an errata list for this book posted at www.labmanual.org. If you find any errors,
we welcome your submissions for errata updates. We also welcome your feedback and
comments. Unfortunately, our day jobs prevent us from answering detailed questions,
so if you’re looking for help on a specific issue, you may find one of the many online
communities a better choice. However, if you have two cents to share about the book, we
welcome your thoughts. You can send us e-mail at feedback@labmanual.org.
I
Installing Linux
as a Server
1
Copyright © 2009 by The McGraw-Hill Companies. Click here for terms of use.
This page intentionally left blank
1
Technical Summary of
Linux Distributions
3
Copyright © 2009 by The McGraw-Hill Companies. Click here for terms of use.
4
Linux Administration: A Beginner’s Guide
L
inux has hit the mainstream. A quick walk through any local major computer
and electronics retail store will show this—the software offerings include boxed
versions of various Linux distributions, and the hardware offerings include systems
or appliances that use Linux in one form or another! Hardly a day goes by without a
mention of Linux (or open source software) in widely read print or digital publications.
What was only a hacker’s toy several years ago has grown up tremendously and is well
known for its stable and fast server performance. If more proof is needed, just note a
common question that is now asked of chief technology officers (CTOs) of Fortune 500
companies: “What is your Linux or open source strategy?”
With the innovative K Desktop Environment (KDE) and GNOME environments,
Linux is also making inroads into the Windows desktop market. In this chapter, we
will take a look at some of the core server-side technologies as they are implemented
in the Linux (open source) world and in the Microsoft Windows Server world (likely
the platform you are considering replacing with Linux). But before we delve into any
technicalities, we will briefly discuss some important underlying concepts and ideas
that affect Linux.
LINUX—THE OPERATING SYSTEM
Usually, people (mis)understand Linux to be an entire software suite of developer tools,
editors, graphical user interfaces (GUIs), networking tools, and so forth. More formally
and correctly, such software collectively is called a distribution, or distro. So the distro is the
entire software suite that makes Linux useful.
So if we consider a distribution everything you need for Linux, what then is Linux
exactly? Linux itself is the core of the operating system: the kernel. The kernel is the
program acting as chief of operations. It is responsible for starting and stopping other
programs (such as editors), handling requests for memory, accessing disks, and managing network connections. The complete list of kernel activities could easily be a chapter
in itself, and in fact, several books documenting the kernel’s internal functions have been
written.
The kernel is a nontrivial program. It is also what puts the Linux badge on all the
numerous Linux distributions. All distributions use essentially the same kernel, and
thus, the fundamental behavior of all Linux distributions is the same.
You’ve most likely heard of the Linux distributions named Red Hat Enterprise Linux
(RHEL), Fedora, Debian, Mandrake, Ubuntu, Kubuntu, openSuSE, goBuntu, and so on,
which have received a great deal of press.
Linux distributions can be broadly categorized into two groups. The first category
includes the purely commercial distros, and the second includes the noncommercial distros, or spins. The commercial distros generally offer support for their distribution—at
a cost. The commercial distros also tend to have a longer release life cycle. Examples of
commercial flavors of Linux-based distros are RHEL, SuSE Linux Enterprise (SLE), etc.
Chapter 1:
Technical Summary of Linux Distributions
The noncommercial distros, on the other hand, are free. The noncommercial distros try to adhere to the original spirit of the open source software. They are mostly
community supported and maintained—the community consists of the users and developers. The community support and enthusiasm can sometimes supersede that provided
by the commercial offerings.
Several of the so-called noncommercial distros also have the backing and support of
their commercial counterparts. The companies that offer the purely commercial flavors
have vested interests in making sure that free distros exist. Some of the companies use
the free distros as the proofing and testing ground for software that ends up in the commercial spins. Examples of noncommercial flavors of Linux-based distros are Fedora,
OpenSuSE, Ubuntu, goBuntu, Debian, etc. Linux distros like Debian may be less well
known and may not have reached the same scale of popularity as Fedora, OpenSuSE,
and others, but they are out there and in active use by their respective (and dedicated)
communities.
What’s interesting about the commercial Linux distributions is that most of the tools
with which they ship were not written by the companies themselves. Rather, other people have released their programs with licenses, allowing their redistribution with source
code. By and large, these tools are also available on other variants of UNIX, and some
of them are becoming available under Windows as well. The makers of the distribution
simply bundle them into one convenient package that’s easy to install. (Some distribution makers also develop value-added tools that make their distribution easier to administer or compatible with more hardware, but the software that they ship is generally
written by others.)
What Is Open Source Software and GNU All About?
In the early 1980s, Richard Stallman began a movement within the software industry. He
preached (and still does) that software should be free. Note that by free, he doesn’t mean
in terms of price, but rather free in the same sense as freedom. This meant shipping not
just a product, but the entire source code as well.
Stallman’s policy was, somewhat ironically, a return to classic computing, when software was freely shared among hobbyists on small computers and given as part of the
hardware by mainframe and minicomputer vendors. (It was not until the late 1960s that
IBM considered selling application software. Through the 1950s and most of the 1960s,
they considered software merely a tool for enabling the sale of hardware.)
This return to openness was a wild departure from the early 1980s convention of selling prepackaged software, but Stallman’s concept of open-source software was in line
with the initial distributions of UNIX from Bell Labs. Early UNIX systems did contain
full source code. Yet by the late 1970s, source code was typically removed from UNIX
distributions and could be acquired only by paying large sums of money to AT&T (now
SBC). The Berkeley Software Distribution (BSD) maintained a free version, but its commercial counterpart, BSDi, had to deal with many lawsuits from AT&T until it could be
proved that nothing in the BSD kernel was from AT&T.
5
6
Linux Administration: A Beginner’s Guide
Kernel Differences
Each company that sells a Linux distribution of its own will be quick to tell you
that its kernel is better than others. How can a company make this claim? The
answer comes from the fact that each company maintains its own patch set. In
order to make sure that the kernels largely stay in sync, most do adopt patches
that are put into Linus’ tree (as published on www.kernel.org). The main difference is that vendors typically do not track the release of every single kernel version
that is released onto www.kernel.org. Instead, they take a foundation, apply their
custom patches to it, run the kernel through their quality assurance (QA) process,
and then take it out to production. This helps organizations have confidence that
their kernels have been sufficiently baked, thus mitigating any perceived risk of
running open source–based operating systems.
The only exception to this rule revolves around security issues. If a security
issue is found with a Linux kernel, vendors are quick to adopt the necessary patches
to fix the problem immediately. A new release of the kernel is made within a short
time (commonly less than 24 hours) so that administrators can be sure their installations are secure. Thankfully, exploits against the kernel itself are rare.
So if each vendor maintains its own patch set, what exactly is it patching?
This answer varies from vendor to vendor, depending on each vendor’s target
market. Red Hat, for instance, is largely focused on providing enterprise-grade
reliability and solid efficiency for application servers. This may be different from
the mission of the Fedora team, which is more interested in trying new technologies quickly, and even more different from the approach of a vendor that is trying
to put together a desktop-oriented Linux system.
What separates one distribution from the next are the value-added tools that come
with each one. Asking “Which distribution is better?” is much like asking “Which is
better, Coke or Pepsi?” Almost all colas have the same basic ingredients—carbonated
water, caffeine, and high-fructose corn syrup—thereby giving the similar effect of
quenching thirst and bringing on a small caffeine-and-sugar buzz. In the end, it’s
a question of requirements: Do you need commercial support? Did your application vendor recommend one distribution over another? Does the software (package) updating infrastructure suit your site’s administrative style better than another
distribution? When you review your requirements, you’ll find that there is likely a
distribution that is geared toward your exact needs.
The idea of giving away source code is a simple one: A user of the software should
never be forced to deal with a developer who might or might not support that user’s
intentions for the software. The user should never have to wait for bug fixes to be
published. More importantly, code developed under the scrutiny of other programmers
is typically of higher quality than code written behind locked doors. The greatest benefit
Chapter 1:
Technical Summary of Linux Distributions
of open source software, however, comes from the users themselves: Should they need
a new feature, they can add it to the original program and then contribute it back to the
source so that everyone else can benefit from it.
This line of thinking sprung a desire to release a complete UNIX-like system to the
public, free of license restrictions. Of course, before you can build any operating system,
you need to build tools. And this is how the GNU project was born.
NOTE GNU stands for GNU’s Not UNIX—recursive acronyms are part of hacker humor. If you don’t
understand why it’s funny, don’t worry. You’re still in the majority.
What Is the GNU Public License?
An important thing to emerge from the GNU project has been the GNU Public License
(GPL). This license explicitly states that the software being released is free and that no
one can ever take away these freedoms. It is acceptable to take the software and resell
it, even for a profit; however, in this resale, the seller must release the full source code,
including any changes. Because the resold package remains under the GPL, the package can be distributed for free and resold yet again by anyone else for a profit. Of primary importance is the liability clause: The programmers are not liable for any damages
caused by their software.
It should be noted that the GPL is not the only license used by open source software developers (although it is arguably the most popular). Other licenses, such as BSD
and Apache, have similar liability clauses but differ in terms of their redistribution. For
instance, the BSD license allows people to make changes to the code and ship those
changes without having to disclose the added code. (The GPL would require that the
added code be shipped.) For more information about other open source licenses, check
out www.opensource.org.
Historical Footnote
Several years ago, Red Hat started a commercial offering of their erstwhile free
product (Red Hat Linux). The commercial release was the Red Hat Enterprise
Linux (RHEL) series. Because the foundation for RHEL is GPL, individuals interested in maintaining a free version of Red Hat’s distribution have been able to do
so. Furthermore, as an outreach to the community Red Hat created the Fedora Project, which is considered the testing grounds for new software before it is adopted
by the RHEL team. The Fedora Project is freely distributed and can be downloaded
from http: //fedora.redhat.com.
7
8
Linux Administration: A Beginner’s Guide
THE ADVANTAGES OF OPEN SOURCE SOFTWARE
If the GPL seems like a bad idea from the standpoint of commercialism, consider the
surge of successful open source software projects—they are indicative of a system that
does indeed work. This success has evolved for two reasons. First, as mentioned earlier,
errors in the code itself are far more likely to be caught and quickly fixed under the
watchful eyes of peers. Second, under the GPL system, programmers can release code
without the fear of being sued. Without that protection, people may not feel as comfortable to release their code for public consumption.
NOTE The concept of free software, of course, often begs the question of why anyone would release
his or her work for free. As hard as it may be to believe, some people do it purely for altruistic reasons
and the love of it.
Most projects don’t start out as full-featured, polished pieces of work. They may
begin life as a quick hack to solve a specific problem bothering the programmer at the
time. As a quick-and-dirty hack, the code may not have a sales value. But when this code
is shared and consequently improved upon by others who have similar problems and
needs, it becomes a useful tool. Other program users begin to enhance it with features
they need, and these additions travel back to the original program. The project thus
evolves as the result of a group effort and eventually reaches full refinement. This polished program may contain contributions from possibly hundreds, if not thousands, of
programmers who have added little pieces here and there. In fact, the original author’s
code is likely to be little in evidence.
There’s another reason for the success of generally licensed software. Any project
manager who has worked on commercial software knows that the real cost of development software isn’t in the development phase. It’s in the cost of selling, marketing, supporting, documenting, packaging, and shipping that software. A programmer carrying
out a weekend hack to fix a problem with a tiny, kludged program may lack the interest,
time, and money to turn that hack into a profitable product.
When Linus Torvalds released Linux in 1991, he released it under the GPL. As a result
of its open charter, Linux has had a notable number of contributors and analyzers. This
participation has made Linux strong and rich in features. Torvalds himself estimates that
since the v.2.2.0 kernel, his contributions represent only 5 percent of the total code base.
Since anyone can take the Linux kernel (and other supporting programs), repackage
them, and resell them, some people have made money with Linux. As long as these individuals release the kernel’s full source code along with their individual packages, and
as long as the packages are protected under the GPL, everything is legal. Of course, this
means that packages released under the GPL can be resold by other people under other
names for a profit.
In the end, what makes a package from one person more valuable than a package
from another person are the value-added features, support channels, and documentation. Even IBM can agree to this; it’s how they made most of their money from 1930 to
Chapter 1:
Technical Summary of Linux Distributions
1970, and now in the late 1990s and early 2000s with IBM Global Services. The money
isn’t necessarily in the product alone; it can also be in the services that go with it.
The Disadvantages of Open Source Software
This section was included to provide a balanced and unbiased contrast to the previous
section, which discussed some of the advantages of open source software.
Nothing to see here.
UNDERSTANDING THE DIFFERENCES
BETWEEN WINDOWS AND LINUX
As you might imagine, the differences between Microsoft Windows and the Linux operating system cannot be completely discussed in the confines of this section. Throughout
this book, topic by topic, we’ll examine the specific contrasts between the two systems.
In some chapters, you’ll find that we don’t derive any comparisons because a major difference doesn’t really exist.
But before we attack the details, let’s take a moment to discuss the primary architectural differences between the two operating systems.
Single Users vs. Multiple Users vs. Network Users
Windows was designed according to the “one computer, one desk, one user” vision of
Microsoft’s cofounder Bill Gates. For the sake of discussion, we’ll call this philosophy
single-user. In this arrangement, two people cannot work in parallel running (for example)
Microsoft Word on the same machine at the same time. (On the other hand, one might
question the wisdom of doing this with an overwhelmingly weighty program like Word!)
You can buy Windows and run what is known as Terminal Server, but this requires huge
computing power and extra costs in licensing. Of course, with Linux, you don’t run into
the cost problem, and Linux will run fairly well on just about any hardware.
Linux borrows its philosophy from UNIX. When UNIX was originally developed at
Bell Labs in the early 1970s, it existed on a PDP-7 computer that needed to be shared by
an entire department. It required a design that allowed for multiple users to log into the
central machine at the same time. Various people could be editing documents, compiling programs, and doing other work at the exact same time. The operating system on the
central machine took care of the “sharing” details so that each user seemed to have an
individual system. This multiuser tradition continues through today on other versions of
UNIX as well. And since Linux’s birth in the early 1990s, it has supported the multiuser
arrangement.
NOTE Most people believe that with the advent of Windows 95, the term “multitasking” was invented.
UNIX has had this capability since 1969! You can rest assured that the concepts put into Linux have
had many years to develop and prove themselves.
9
10
Linux Administration: A Beginner’s Guide
Today, the most common implementation of a multiuser setup is to support servers—
systems dedicated to running large programs for use by many clients. Each member of a
department can have a smaller workstation on the desktop, with enough power for dayto-day work. When they need to do something requiring significantly more processing
power or memory, they can run the operation on the server.
“But, hey! Windows can allow people to offload computationally intensive work to
a single machine!” you may argue. “Just look at SQL Server!” Well, that position is only
half correct. Both Linux and Windows are indeed capable of providing services such as
databases over the network. We can call users of this arrangement network users, since
they are never actually logged into the server, but rather, send requests to the server.
The server does the work and then sends the results back to the user via the network.
The catch in this case is that an application must be specifically written to perform such
server/client duties. Under Linux, a user can run any program allowed by the system
administrator on the server without having to redesign that program. Most users find
the ability to run arbitrary programs on other machines to be of significant benefit.
The Monolithic Kernel and the Micro-Kernel
In operating systems, there are two forms of kernels. You have a monolithic kernel that
provides all the services the user applications need. And then you have the micro-kernel,
a small core set of services and other modules that perform other functions.
Linux, for the most, part adopts the monolithic kernel architecture; it handles everything dealing with the hardware and system calls. Windows works off a micro-kernel
design. The kernel provides a small set of services and then interfaces with other executive services that provide process management, input/output (I/O) management, and
other services. It has yet to be proved which methodology is truly the best way.
Separation of the GUI and the Kernel
Taking a cue from the Macintosh design concept, Windows developers integrated the
GUI with the core operating system. One simply does not exist without the other. The
benefit with this tight coupling of the operating system and user interface is consistency
in the appearance of the system.
Although Microsoft does not impose rules as strict as Apple’s with respect to the
appearance of applications, most developers tend to stick with a basic look and feel
among applications. One reason this is dangerous is that the video card driver is now
allowed to run at what is known as “Ring 0” on a typical x86 architecture. Ring 0 is a protection mechanism—only privileged processes can run at this level, and typically user
processes run at Ring 3. Since the video card is allowed to run at Ring 0, the video card
could misbehave (and it does!), which can bring down the whole system.
On the other hand, Linux (like UNIX in general) has kept the two elements—user
interface and operating system—separate. The X Window System interface is run as a
user-level application, which makes it more stable. If the GUI (which is complex for both
Windows and Linux) fails, Linux’s core does not go down with it. The process simply
crashes, and you get a terminal window. The X Window System also differs from the
Chapter 1:
Technical Summary of Linux Distributions
Windows GUI in that it isn’t a complete user interface. It only defines how basic objects
should be drawn and manipulated on the screen.
The most significant feature of the X Window System is its ability to display windows across a network and onto another workstation’s screen. This allows a user sitting
on host A to log into host B, run an application on host B, and have all of the output
routed back to host A. It is possible for two people to be logged into the same machine,
running a Linux equivalent of Microsoft Word (such as OpenOffice) at the same time.
In addition to the X Window System core, a window manager is needed to create
a useful environment. Linux distributions come with several window managers and
include support for GNOME and KDE, both of which are available on other variants of
UNIX as well. If you’re concerned with speed, you can look into the WindowMaker and
Free Virtual Window Manager (FVWM) window managers. They might not have all the
glitz of KDE or GNOME, but they are really fast. When set as default, both GNOME and
KDE offer an environment that is friendly, even to the casual Windows user.
So which approach is better—Windows or Linux—and why? That depends on what
you are trying to do. The integrated environment provided by Windows is convenient
and less complex than Linux, but out of the box, it lacks the X Window System feature
that allows applications to display their windows across the network on another workstation. Windows’ GUI is consistent, but cannot be turned off, whereas the X Window
System doesn’t have to be running (and consuming valuable memory) on a server.
NOTE With its latest server family (Windows Server 2008), Microsoft has somewhat decoupled the
GUI from the base operating system (OS).You can now install and run the server in a so-called “Server
Core” mode. Windows Server 2008 Server Core runs without the usual Windows GUI. Managing the
server in this mode is done via the command line or remotely from a regular system, with full GUI
capabilities.
The Network Neighborhood
The native mechanism for Windows users to share disks on servers or with each other is
through the Network Neighborhood. In a typical scenario, users attach to a share and have
the system assign it a drive letter. As a result, the separation between client and server is
clear. The only problem with this method of sharing data is more people-oriented than
technology-oriented: People have to know which servers contain which data.
With Windows, a new feature borrowed from UNIX has also appeared: mounting. In
Windows terminology, it is called reparse points. This is the ability to mount a CD-ROM
drive into a directory on your C drive. The concept of mounting resources (optical media,
network shares, etc.) in Linux/UNIX may seem a little strange, but as you get used to
Linux, you’ll understand and appreciate the beauty in this design. To get anything close
to this functionality in Windows, you have to map a network share to a drive letter.
Linux, using the Network File System (NFS), has supported the concept of mounting
since its inception. In fact, the Linux Automounter can dynamically mount and unmount
partitions on an as-needed basis.
11
12
Linux Administration: A Beginner’s Guide
A common example of mounting partitions under Linux involves mounted home
directories. The user’s home directories reside on a server, and the client mounts the
directories at boot time (automatically). So the /home directory exists on the client, but
the /home/username directory (and its contents) can reside on the server.
Under Linux NFS, users never have to know server names or directory paths, and
their ignorance is your bliss. No more questions about which server to connect to. Even
better, users need not know when the server configuration must change. Under Linux,
you can change the names of servers and adjust this information on client-side systems
without making any announcements or having to reeducate users. Anyone who has
ever had to reorient users to new server arrangements is aware of the repercussions
that can occur.
Printing works in much the same way. Under Linux, printers receive names that are
independent of the printer’s actual host name. (This is especially important if the printer
doesn’t speak Transmission Control Protocol/Internet Protocol, or TCP/IP.) Clients point
to a print server whose name cannot be changed without administrative authorization.
Settings don’t get changed without you knowing it. The print server can then redirect
all print requests as needed. The Linux uniform interface will go a long way toward
improving what may be a chaotic printer arrangement in your installation. This also
means you don’t have to install print drivers in several locations.
The Registry vs. Text Files
Think of the Windows Registry as the ultimate configuration database—thousands upon
thousands of entries, only a few of which are completely documented.
“What? Did you say your Registry got corrupted?” “Well, yes,
we can try to restore it from last night’s backups, but then Excel starts acting funny and
the technician (who charges $50 just to answer the phone) said to reinstall.…”
In other words, the Windows Registry system is, at best, difficult to manage. Although
it’s a good idea in theory, most people who have serious dealings with it don’t emerge
from battle without a scar or two.
Linux does not have a registry. This is both a blessing and a curse. The blessing is that
configuration files are most often kept as a series of text files (think of the Windows .ini
files before the days of the Registry). This setup means you’re able to edit configuration
files using the text editor of your choice rather than tools like regedit. In many cases,
it also means you can liberally comment those configuration files so that six months
from now you won’t forget why you set something up in a particular way. With most
tools that come with Linux, configuration files exist in the /etc directory or one of its
subdirectories.
The curse of a no-registry arrangement is that there is no standard way of writing
configuration files. Each application can have its own format. Many applications are now
coming bundled with GUI-based configuration tools to alleviate some of these problems.
So you can do a basic setup easily and then manually edit the configuration file when
you need to do more complex adjustments.
Chapter 1:
Technical Summary of Linux Distributions
In reality, having text files hold configuration information usually turns out to be
an efficient method. Once set, they rarely need to be changed; even so, they are straight
text files and thus easy to view when needed. Even more helpful is that it’s easy to write
scripts to read the same configuration files and modify their behavior accordingly. This
is especially helpful when automating server maintenance operations, which is crucial
in a large site with many servers.
Domains and Active Directory
If you’ve been using Windows long enough, you may remember the Windows NT domain
controller model. If twinges of anxiety ran through you when reading the last sentence,
you may still be suffering from the shell shock of having to maintain Primary Domain
Controllers (PDCs), Backup Domain Controllers (BDCs), and their synchronization.
Microsoft, fearing revolt from administrators all around the world, gave up on the
Windows NT model and created Active Directory (AD). The idea behind AD was simple:
Provide a repository for any kind of administrative data, whether it is user logins, group
information, or even just telephone numbers, and manage authentication and authorization for a domain. The domain synchronization model was also changed to follow a
Domain Name System (DNS)–style hierarchy that has proved to be far more reliable.
NT LAN Manager (NTLM) was also dropped in favor of Kerberos. (Note that AD is still
compatible with NTLM.)
While running dcpromo may not be anyone’s idea of a fun afternoon, it is easy to see
that AD works pretty well.
Out of the box, Linux does not use a tightly coupled authentication/authorization
and data store model the way that Windows does with Active Directory. Instead, Linux
uses an abstraction model that allows for multiple types of stores and authentication
schemes to work without any modification to other applications. This is accomplished
through the Pluggable Authentication Modules (PAM) infrastructure and the name resolution libraries that provide a standard means of looking up group information for applications and a flexible way of storing that group information using a variety of schemes.
For administrators looking to Linux, this abstraction layer can seem peculiar at first.
However, consider that you can use anything from flat files to Network Information
Service (NIS) to Lightweight Directory Access Protocol (LDAP) or Kerberos for authentication. This means you can pick the system that works best for you. For example, if you
have an existing UNIX infrastructure that uses NIS, you can simply make your Linux
systems plug into that. On the other hand, if you have an existing AD infrastructure, you
can use PAM with Samba or LDAP to authenticate against the domain. Use Kerberos?
No problem. And of course, you can choose to make your Linux system not interact
with any external authentication system. In addition to being able to tie into multiple
authentication systems, Linux can easily use a variety of tools, such as OpenLDAP, to
keep directory information available as well.
13
14
Linux Administration: A Beginner’s Guide
SUMMARY
In this chapter, we offered an overview of what Linux is and what it isn’t. We discussed
a few of the guiding principles, ideas, and concepts that govern open source software
and Linux by extension. We ended the chapter by glossing over some of the similarities
and differences between core technologies in the Linux and Microsoft Windows Server
worlds. Most of these technologies and their practical uses are dealt with in greater detail
in the rest of this book.
If you are so inclined and would like to get more detailed information on the internal
workings of Linux itself, you may want to start with the source code. The source code
can be found here: www.kernel.org. It is, after all, open source!
2
Installing Linux in a
Server Configuration
15
Copyright © 2009 by The McGraw-Hill Companies. Click here for terms of use.
16
Linux Administration: A Beginner’s Guide
A
key attribute in Linux’s recent success is the remarkable improvement in
installation tools. What once was a mildly frightening process many years back
has now become almost trivial. Even better, there are many ways to install the
software; optical media (CD/DVD-ROMs) are no longer the only choice (although they
are still the most common). Network installations are part of the default list of options as
well, and they can be a wonderful help when installing a large number of hosts. Another
popular method of installing a Linux distribution is installing from a live CD.
Most default configurations where Linux is installed are already capable of becoming servers. It is usually just a question of installing and configuring the proper software
to perform the needed task. Proper practice dictates that a so-called server be dedicated
to performing only one or two specific tasks. Any other installed and irrelevant services simply take up memory and exert a drag on performance and, as such, should be
avoided. In this chapter, we discuss the installation process as it pertains to servers and
their dedicated functions.
HARDWARE AND ENVIRONMENTAL CONSIDERATIONS
As with any operating system, before getting started with the installation process, you
should determine what hardware configurations would work. Each commercial vendor
publishes a hardware compatibility list (HCL) and makes it available on its web site. For
example, Red Hat’s HCL is at http://hardware.redhat.com (Fedora’s HCL can be safely
assumed to be similar to Red Hat’s), OpenSuSE’s HCL database can be found at http://
en.opensuse.org/Hardware, Ubuntu’s HCL can be found at https://wiki.ubuntu.com/
HardwareSupport, and a more generic HCL for most Linux flavors can be found at
http://www.tldp.org/HOWTO/Hardware-HOWTO.
These sites provide a good starting reference point when you are in doubt concerning
a particular piece of hardware. However, keep in mind that new Linux device drivers
are being churned out on a daily basis around the world and no single site can keep up
with the pace of development in the open source community. In general, most popular
Intel-based and AMD-based configurations work without difficulty.
A general suggestion that applies to all operating systems is to avoid cutting-edge
hardware and software configurations. While they appear to be really impressive, they
haven’t had the maturing process some of the slightly older hardware has gone through.
For servers, this usually isn’t an issue, since there is no need for a server to have the latest
and greatest toys, such as fancy video cards and sound cards. After all, your main goal is
to provide a stable and available server for your users.
SERVER DESIGN
By definition, server-grade systems exhibit three important characteristics: stability, availability, and performance. These three factors are usually improved through the purchase
Chapter 2:
Installing Linux in a Server Configuration
of more and better hardware, which is unfortunate. It’s a shame to pay thousands of
dollars extra to get a system capable of achieving in all three areas when you could have
extracted the desired level of performance out of existing hardware with a little tuning.
With Linux, this is not hard. Even better, the gains are outstanding.
One of the most significant design decisions you must make when managing a server
may not even be technical, but administrative. You must design a server to be unfriendly
to casual users. This means no cute multimedia tools, no sound card support, and no
fancy web browsers (when at all possible). In fact, it should be a rule that casual use of a
server is strictly prohibited.
Another important aspect of designing a server is making sure that it has a good
environment. As a system administrator, you must ensure the physical safety of your
servers by keeping them in a separate room under lock and key (or the equivalent).
The only access to the servers for nonadministrative personnel should be through the
network. The server room itself should be well ventilated and kept cool. The wrong environment is an accident waiting to happen. Systems that overheat and nosy users who
think they know how to fix problems can be as great a danger to server stability as bad
software (arguably even more so).
Once the system is in a safe place, installing battery backup is also crucial. Backup
power serves two key purposes:
▼
It keeps the system running during a power failure so that it may gracefully shut
down, thereby avoiding data corruption or loss.
▲
It ensures that voltage spikes, drops, and other electrical noises don’t interfere
with the health of your system.
Here are some specific things you can do to improve your server performance:
▼
Take advantage of the fact that the graphical user interface is uncoupled from
the core operating system, and avoid starting the X Window System (Linux’s
graphical user interface or GUI) unless someone needs to sit on a console and
run an application. After all, like any other application, the X Window System
requires memory and CPU time to work, both of which are better off going to the
more essential server processes instead.
■
Determine what functions the server is to perform, and disable all other
unrelated functions. Not only are unused functions a waste of memory
and CPU time, but they are just another issue you need to deal with on the
security front.
▲
Unlike some other operating systems, Linux allows you to pick and choose
the features you want in the kernel. (You’ll learn about this process in Chapter 10.) The default kernel will already be reasonably well tuned, so you won’t
have to worry about it. But if you do need to change a feature or upgrade the
kernel, be picky about what you add. Make sure you really need a feature
before adding it.
17
18
Linux Administration: A Beginner’s Guide
NOTE You may hear an old recommendation that you recompile your kernel to make the most
effective use of your system resources. This is no longer entirely true—the other reasons to recompile
your kernel might be to upgrade or add support for a new device or even to remove support for
components you don’t need.
Uptime
All of this chatter about taking care of servers and making sure silly things don’t cause
them to crash stems from a longtime UNIX philosophy: Uptime is good. More uptime is
better.
The UNIX (Linux) uptime command tells the user how long the system has been
running since its last boot, how many users are currently logged in, and how much load
the system is experiencing. The last two are useful measures that are necessary for dayto-day system health and long-term planning. (For example, the server load has been
staying high lately, so maybe it’s time to buy a faster/bigger/better server.)
But the all-important number is how long the server has been running since its last
reboot. Long uptime is regarded as a sign of proper care, maintenance, and, from a practical standpoint, system stability. You’ll often find UNIX administrators boasting about
their server’s uptime the way you hear car buffs boast about horsepower. This is also
why you’ll hear UNIX administrators cursing at system changes (regardless of operating
system) that require a reboot to take effect. You may deny caring about it now, but in six
months, you’ll probably scream at anyone who reboots the system unnecessarily. Don’t
bother trying to explain this phenomenon to a nonadmin, because they’ll just look at you
oddly. You’ll just know in your heart that your uptime is better than theirs.
DUAL-BOOTING ISSUES
If you are new to Linux, you may not be ready to commit to a complete system when you
just want a test drive. All distributions of Linux can be installed on separate partitions
of your hard disk while leaving others alone. Typically, this means allowing Microsoft
Windows to coexist with Linux.
Because we are focusing on server installations, we will not cover the details of building a dual-booting system; however, anyone with a little experience in creating partitions
on a disk should be able to figure this out. If you are having difficulty, you may want to
refer to the installation guide that comes with your distribution.
Some quick hints: If you are using Windows NT/200x/XP/Vista with NTFS and
have already allocated the entire disk to the OS, you may have to do some prep work. To
better guarantee success when resizing a New Technology File System (NTFS) file system, you might want to use the built-in Windows tools (e.g., chkdisk, Disk Defragmenter,
etc.) to prepare or fix any file-system issues prior to resizing. Because of its complexity, it
is slightly trickier to resize an NTFS-formatted partition. Nonetheless, it is still possible.
Chapter 2:
Installing Linux in a Server Configuration
Most of the newer Linux distributions will even offer to automatically resize your NTFS
partition for you during the OS install.
NOTE From the perspective of flexibility, NTFS doesn’t sound like a good thing, but in reality, it is. If
you have to run NT, 2000, 2003, 2008, or Vista, use NTFS.
You may find using a commercial tool such as PartitionMagic to be especially
helpful, because it offers support for NTFS, FAT32, and regular File Allocation Table
(FAT), as well as a large number of other file-system types. Another useful, completely
open source alternative for managing disk partition is the GParted Live CD (http://
gparted-livecd.tuxfamily.org). For dealing with Linux dual-boot issues with Vista,
Neosmart’s EasyBCD (www.neosmart.net) product is useful and easy to use.
METHODS OF INSTALLATION
With the improved connectivity and speed of both local area networks and Internet connections, it is becoming an increasingly popular option to perform installations over the
network rather than using a local optical drive (CD-ROM, DVD-ROM, etc.).
Depending on the particular Linux distribution and the network infrastructure
already in place, one can design network-based installations around several protocols.
Some of the more popular protocols over which network-based installations are done
are listed here:
▼
FTP (File Transfer Protocol)
network installations.
■
HTTP (Hypertext Transfer Protocol) The installation tree is served from a web
server.
■
NFS (Network File System) The distribution tree is shared/exported on an
NFS server.
▲
SMB (Server Message Block) This method is relatively new, and not all distributions support it. The installation tree can be shared on a Samba server or
shared from a Windows box.
This is one of the earliest methods for performing
The other, more typical method of installation is through the use of optical media provided by the vendor. All the commercial distributions of Linux have boxed sets of their
brand of Linux that contain the install media. They usually also make CD/DVD-ROM
images (ISOs) of the OS available on their FTP and/or HTTP sites. The distros (distributions) that don’t make their ISOs available will usually have a stripped-down version of
the OS available in a repository tree on their site.
Another variant of installing Linux that has become popular is installing via a live CD
or live distro. This method provides several advantages. It allows the user to try out (test
drive) the distribution first before actually installing anything onto the drive. It allows the
19
20
Linux Administration: A Beginner’s Guide
user to have a rough idea of how hardware and other peripherals on the target system
will behave. Live CDs are usually a stripped-down version of the full distribution and, as
such, no conclusion should be drawn from them. With a little tweak here and there, one
can usually get troublesome hardware working after the fact—your mileage may vary.
We will be performing a server class install in this chapter using an image that was
burnt to a DVD. Of course, once you have gone through the process of installing from an
optical medium (CD/DVD-ROM), you will find performing the network-based installations straightforward. A side note regarding automated installations is that server-type
installs aren’t well suited to automation, because each server usually has a unique task;
thus, each server will have a slightly different configuration. For example, a server dedicated to handling logging information sent to it over the network is going to have especially large partitions set up for the appropriate logging directories, compared to a file
server that performs no logging of its own. (The obvious exception is for server farms,
where you have large numbers of replicated servers. But even those installations have
their nuances that require attention to detail specific to the installation.)
INSTALLING FEDORA
In this section, you will install a Fedora 9 distribution on a stand-alone system. We will
take a liberal approach to the process, installing all of the tools possibly relevant to server
operations. Later chapters explain each subsystem’s purpose and help you determine
which ones you really need to keep.
NOTE Don’t worry if you chose to install a distribution other than Fedora; luckily, most of the concepts
carry over among the various distributions. Some installers are just prettier than others.
Project Prerequisites
First, you need to download the ISOs for Fedora 9 that we will be installing. Fedora’s
project web page has a listing of several mirrors located all over the world. You should,
of course, choose the mirror geographically closest to you. The list of mirrors can be
found at http://mirrors.fedoraproject.org/publiclist.
The DVD image used for this installation was downloaded from ftp://download
.fedora.redhat.com/pub/fedora/linux/releases/9/Fedora/i386/iso/Fedora-9-i386DVD.iso.
NOTE Linux distributions are often packaged by the architecture they were compiled to run on. You
would often find ISO images (and other software) named to reflect an architecture type. Examples of
the architecture types are x86, x86_64, ppc, etc. The x86 refers to the Pentium class family and their
equivalents (e.g., i386, i586, i686, AMD Athlon, AthlonXP, Duron, AthlonMP, Sempron, etc.). The PPC
family refers to the PowerPC family (e.g., G3, G4, G5, IBM pSeries, etc.). And the x86_64 family refers
to the 64-bit platforms (e.g., Athlon64, Turion64, Opteron, EM64T, etc.).
Chapter 2:
Installing Linux in a Server Configuration
The next step is to burn the ISO to a suitable medium. In this case, we need to burn
the ISO to a blank DVD. Use your favorite CD/DVD burning program to burn the image.
Remember that the file you downloaded is already an exact image of a DVD medium
and so should be burnt as such. Most CD/DVD burning programs have an option to create a CD or DVD from an image.
If you burn the file you downloaded as you would a regular data file, you will end up
with a single file on the root of your DVD-ROM. This is not what you want. The system
you are installing on should have a DVD-ROM drive.
NOTE Linux distribution install images are also usually available as a set of CD-ROM images. You
can perform the installation using these CD-ROMs, but we have decided to perform the install using
a DVD-ROM, mostly for the sake of convenience. Using a single DVD helps you avoid having to swap
out CDs in the middle of the install, because all the required files are already on a single DVD, as
opposed to multiple CDs, and also because the chances of having a bad installation medium are
reduced (i.e., there is a higher probability of having one bad CD out of four than of having one bad
DVD out of one).
Let’s begin the installation process.
Carrying Out the Installation
1. To start the installation process, boot off the DVD-ROM (the system Basic Input
Output System, or BIOS, should be preconfigured for this already). This will
present you with a welcome splash screen.
21
22
Linux Administration: A Beginner’s Guide
2. If you do not press any key, the prompt will eventually time out and begin the
installation process by booting the highlighted Install or Upgrade an Existing
System option. You can also press enter to start the process immediately.
3. At the Disc Found screen, press enter to test/verify your install media. Note
that the test performed here is not always perfect. But for the majority of times
when it does work, it can save you the trouble of starting the installation only to
find out halfway through that the installer will abort because of a bad disc. Press
enter again at the Media Check screen to begin testing.
4. After the media check runs to completion, you should get the Success screen that
reports that the media was successfully verified. At this point, it is safe to select
OK to continue with the installation. If you don’t have any other install media to
test, select Continue at the next screen.
5. Click Next at the next screen.
6. Select the language you want to use to perform the installation in this screen (see
illustration). The interface works much like any other Windows-style interface.
Simply point to your selection and click. English (English) is selected on our
sample system. When you are ready, click the Next button in the lower-right
portion of the screen.
7. Select your keyboard layout type. This screen allows you to select the layout type
for the keyboard. The screen lists the various possible layouts that are supported.
The U.S. English layout is selected on our sample system. Click Next to continue.
Chapter 2:
Installing Linux in a Server Configuration
8. If prompted, select Yes at the Warning screen to initialize the hard disk and erase
any data that might be on it.
NOTE After you click Next at this point, the installer will quickly search your hard drive for any
existing Linux installations. If any are found, you might be prompted with a different screen to perform
an upgrade or a reinstallation of the OS found. If you are instead installing on a brand-new hard disk,
you will not get any such screen. If installing on a new hard disk, you will get a Warning dialog box
prompting you to initialize the disk as described in the procedure.
Network Configuration
Each interface card that was detected correctly will be listed under the Network Devices
section. Ethernet devices in Linux are named eth0, eth1, eth2, and so on. For each interface, you can either configure it using Dynamic Host Configuration Protocol (DHCP) or
manually set the Internet Protocol (IP) address. If you choose to configure manually, be
sure to have all the pertinent information ready, such as the IP address, netmask, etc.
On the bottom half of the screen, you’ll see the configuration choices for configuring
the Hostname of the system (the name defaults to localhost.localdomain, which can easily be changed later) and other Miscellaneous Settings.
1. On our sample system, we are going to configure the first Ethernet interface—
eth0—using DHCP. Accept all the default values in this screen, as shown here,
and click Next.
23
24
Linux Administration: A Beginner’s Guide
NOTE Don’t worry if you know that you don’t have a DHCP server available on your network that will
provide your new system with IP configuration information. The Ethernet interface will simply remain
unconfigured. The hostname of the system also can be automatically set via DHCP—if you have a
reachable and capable DHCP server on the network.
Time Zone Selection
The Time Zone Configuration section is the next stage in the installation. This is where
you select the time zone in which the machine is located.
If your system’s hardware clock keeps time in Coordinated Universal Time (UTC),
be sure to select the System Clock Uses UTC check box so that Linux can determine the
difference between the two and display the correct local time.
1. Scroll through the list of locations, and select the nearest city to your time zone.
You can also use the interactive map to select a specific city (marked by a yellow
dot) to set your time zone.
2. Click Next when done.
Set the Root Password
The next part of the installation allows you to set a password for the root user, also
called the superuser. It is the most privileged account on the system and typically has
full control of the system. It is equivalent to the Administrator account in Windows
operating systems. Thus, it is crucial that you protect this account with a good password. Be sure not to pick dictionary words or names as passwords, as they are easy to
guess and crack.
1. Pick a strong password and enter it in the Root Password text box.
2. Enter the same password again in the Confirm text box.
3. Click Next.
Disk Partitioning Setup
This portion of the installation is probably the part that most new Linux users find the
most awkward. This is because of the different naming conventions that Linux uses. This
needn’t be so—all it takes is a slight mind shift. You should also keep in mind that “a
partition is a partition is a partition” in Linux or Windows.
What follows is a quick overview of the partitioning scheme you will be employing
for this installation. Please note that, by default, the installer has the option to automatically lay out the disk partition, but we will not accept the default layout so that we can
configure the server optimally. The equivalent partitions in the Windows world are also
given in the overview:
Chapter 2:
Installing Linux in a Server Configuration
▼
/ The root partition/volume is identified by a forward slash (/). All other
directories are attached (mounted) to this parent directory. It is equivalent to the
system drive (C:\ ) in Windows.
■
/boot This partition/volume contains almost everything required for the boot
process. It stores data that is used before the kernel begins executing user programs. The equivalent of this in Windows is known as the system partition (not
the boot partition).
■
/usr This is where all of the program files will reside (similar to C:\Program
Files in Windows).
■
/home This is where everyone’s home directory will be (assuming this server
will house them). This is useful for keeping users from consuming an entire
disk and leaving other critical components without space (such as log files). This
directory is synonymous with “C:\Documents and Settings\” in Windows
XP/200x or “C:\Users\” in the Vista and Windows Server 2008 world.
■
/var This is where system/event logs are generally stored. Because log files tend
to grow in size quickly and can also be affected by outside users (for instance,
individuals visiting a web site), it is important to store the logs on a separate
partition so that no one can perform a denial-of-service attack by generating
enough log entries to fill up the entire disk. Logs are generally stored in the C:\
WINDOWS\system32\config\ directory in Windows.
■
/tmp This is where temporary files are placed. Because this directory is
designed so that it is writable by any user (similar to the C:\Temp directory
under Windows), you need to make sure arbitrary users don’t abuse it and fill
up the entire disk. You ensure this by keeping it on a separate partition.
▲
Swap This is where the virtual memory file is stored. This isn’t a user-accessible
file system. Although Linux (and other flavors of UNIX as well) can use a normal disk file to hold virtual memory the way Windows does, you’ll find that
having your swap file on its own partition improves performance. You will typically want to configure your swap file to be double the physical memory that is
in your system. This is referred to as the paging file in Windows.
Each of these partitions is mounted at boot time. The mount process makes the contents of that partition available as if it were just another directory on the system. For
example, the root directory (/) will be on the first (root) partition. A subdirectory called
/usr will exist on the root directory, but it will have nothing in it. A separate partition can
then be mounted such that going into the /usr directory will allow you to see the contents
of the newly mounted partition. All the partitions, when mounted, appear as a unified
directory tree rather than as separate drives; the installation software does not differentiate one partition from another. All it cares about is which directory each file goes into. As
a result, the installation process automatically distributes its files across all the mounted
partitions, as long as the mounted partitions represent different parts of the directory
tree where files are usually placed.
25
26
Linux Administration: A Beginner’s Guide
The disk partitioning tool used during the operating system installation provides an
easy way to create partitions and associate them to the directories they will be mounted
on. Each partition entry will typically show the following information:
▼
Device Linux associates each partition with a separate device. For the purpose
of this installation, you need to know only that under Integrated Drive Electronics
(IDE) disks, each device begins with /dev/sdXY, where X is a for an IDE master
on the first chain, b for an IDE slave on the first chain, c for an IDE master on the
second chain, or d for an IDE slave on the second chain, and where Y is the partition number of the disk. For example, /dev/sda1 is the first partition on the primary chain, primary disk. Native Small Computer System Interface (SCSI) disks
follow the same basic idea, and each partition starts with /dev/sdXY, where X is
a letter representing a unique physical drive (a is for SCSI ID 1, b is for SCSI ID 2,
and so on). The Y represents the partition number. Thus, for example, /dev/sdb4
is the fourth partition on the SCSI disk with ID 2. The system is a little more complex than Windows, but each partition’s location is explicit—no more guessing:
“What physical device does drive E: correspond to?”
■
Mount point
■
Type This field shows the partition’s type (for example, ext2, ext3, ext4, swap,
or vfat).
■
Format
■
Size (MB)
■
Start This field shows the cylinder on your hard drive where the partition
begins.
▲
End This field shows the cylinder on your hard drive where the partition ends.
The location where the partition is mounted.
This field indicates whether the partition will be formatted.
This field shows the partition’s size (in megabytes, or MB).
For the sake of simplicity, you will use only some of the disk boundaries described earlier for your installation. In addition, you will leave some free space (unpartitioned space)
that we can play with in a later chapter (Chapter 7). You will carve up your hard disk into:
/boot
/
SWAP
/home
/tmp
FREE SPACE/UNPARTITIONED AREA
The sample system that this installation is being performed on has a 10-gigabyte (GB)
hard disk. You will use the following sizes as a guideline on how to allocate the various
sizes for each partition/volume. You should, of course, adjust the suggested sizes to suit
the overall size of the disk you are using.
Chapter 2:
Mount Point
Size
/boot
200MB
/
5GB
SWAP
1024MB
/home
2.5GB
/tmp
512MB
FREE SPACE
~ 800MB
Installing Linux in a Server Configuration
NOTE The /boot partition cannot be created on a Logical Volume Management (LVM) partition type.
The Fedora boot loader cannot read LVM-type partitions. This is true at the time of this writing, but may
change in the future.
Now that you have some background on partitioning under Linux, let’s go back to
the installation process itself:
1. At the top of the screen, select the Create Custom Layout option, and click Next.
2. Next you will be presented with the Disk Setup screen, as shown here:
27
28
Linux Administration: A Beginner’s Guide
3. Click New. The Add Partition dialog box appears; complete it with the information that follows for the corresponding fields:
Mount Point
/boot
File System Type
ext3
Allowable Drives
Accept the default value
Size (MB)
200
Additional Size Options
Fixed size
Force to be a primary partition
Leave unselected
The completed dialog box should resemble the one shown here. Click the OK
button when done.
NOTE The Fedora installer supports the creation of encrypted file systems. We will not use any
encrypted file systems on our sample system.
4. You will create the / (root), /home, /tmp, and swap containers on an LVM-type
partition. In order to do this, you will first need to create the parent physical
volume.
Chapter 2:
Installing Linux in a Server Configuration
Click New. The Add Partition dialog box appears. The physical volume will be
created with the information that follows:
Mount Point
Leave this field blank
File System Type
physical volume (LVM)
Allowable Drives
Accept the default value
Size (MB)
9216 (Approximately 9.0GB)
Additional Size Options
Fixed size
Force to be a primary partition
Leave unselected
The completed dialog box should resemble the one shown here. Click OK
when done.
5. Click the LVM button. The Make LVM Volume Group dialog box will appear.
Accept the default values already provided for the various fields (Volume
Group Name, Physical Extent, etc.). Click Add. The Make Logical Volume dialog box will appear. Complete the fields in the dialog box with the information
that follows:
Mount Point
/
File System Type
ext3
29
30
Linux Administration: A Beginner’s Guide
Logical Volume Name
LogVol00
Size (MB)
5120 (approximately 5GB)
The completed dialog box should resemble the one shown here. Click OK
when done.
6. Click Add again in the Make LVM Volume Group dialog box. The Make Logical
Volume dialog box will appear. Complete the fields in the dialog box with the
information that follows:
Mount Point
Leave blank
File System Type
swap
Logical Volume Name
LogVol01
Size (MB)
1024 (approximately double the total amount of
random access memory, or RAM, available)
The completed dialog box should resemble the one shown here. Click the OK
button when done.
Chapter 2:
Installing Linux in a Server Configuration
7. Click Add again in the Make LVM Volume Group dialog box. The Make Logical
Volume dialog box will appear. Complete the fields in the dialog box with the
information that follows:
Mount Point
/home
File System Type
ext3
Logical Volume Name
LogVol02
Size (MB)
2560 (Approximately 2.5GB)
Click OK when done.
8. Click Add again in the Make LVM Volume Group dialog box. The Make Logical
Volume dialog box will appear. Complete the fields in the dialog box with the
information that follows:
Mount Point
/tmp
File System Type
ext3
Logical Volume Name
LogVol03
Size (MB)
480 (or “Use up all the remaining free space
on the Volume group”)
Click OK when done.
9. The completed Make LVM Volume Group dialog box should resemble the one
shown here:
31
32
Linux Administration: A Beginner’s Guide
Click OK to close the dialog box.
10. You will be returned to the main Disk Setup screen. The final screen should be
similar to the one shown here:
You will notice that we have some free unpartitioned space left under the device
column. This was done deliberately so that we can play with that space in a later
chapter without necessarily having to reinstall the entire operating system to
create free space.
11. Click Next to complete the disk-partitioning portion of the installation.
NOTE You might get a warning about “Writing partitioning to disk” before the changes are actually
written to disk. If you do get this warning, it is okay to confirm writing the changes to disk. Also, if you
get a “Low memory” warning message, click Yes to immediately turn on the swap space.
Boot Loader Configuration
A boot manager handles the process of actually starting the load process of an operating
system. GRand Unified Bootloader (GRUB) is one of the popular boot managers for Linux.
Chapter 2:
Installing Linux in a Server Configuration
If you’re familiar with Windows, you have already dealt with the NT Loader (NTLDR),
which presents the menu at boot time.
The Boot Loader Configuration screen has multiple sections (see Figure 2-1). The top
of the screen tells you where the boot loader is being installed. On our sample system,
it is being installed on the Master Boot Record (MBR) of /dev/sda. The MBR is the first
thing the system will read when booting a system. It is essentially the point where the
built-in hardware tests finish and pass off control to the software.
Typically, unless you really know what you are doing, you will want to accept the
defaults provided here. For example, clearing the check box next to the field where you
specify the device on which to install the boot loader will let you choose not to install a
boot loader, which is not what we want in this instance.
The next section of the screen (Boot loader operating system list) lets you configure
the boot loader to boot other operating systems.
If you are installing Linux on a hard disk that already has some other operating
system (e.g., Windows or some other flavor of Linux), this is where the dual-booting
Figure 2-1. Boot Loader Configuration screen
33
34
Linux Administration: A Beginner’s Guide
functionality will be configured. On a system that is configured to support both Windows
and Linux, you will see your choices here. If your system is set up only for Linux (as we
assume here), you will see one entry.
NOTE Various Linux distributions customize the boot loader menu in different ways. Some
distributions automatically add a rescue mode entry to the list of available options. Some distributions
also add a Memory Test utility option to the menu.
To reiterate, most of the default values provided in this stage of the installation usually work fine for most purposes.
1. Accept the default values provided, and click Next.
Package Group Selection
This is the part of the installation where you can select what packages (applications)
get installed onto the system. Fedora categorizes these packages into several high-level
categories, such as Office and Productivity, Software Development, etc. Each category
houses the individual software packages that compliment that category. This organization allows you to make a quick selection of what types of packages you want installed
and safely ignore the details.
Looking at the choices shown here, you see the menu of top-level package groups
that Fedora gives you. You can simply pick the group(s) that interest you.
1. In the top half of the screen, clear the Office and Productivity option.
2. Select the Customize Now option, and click Next.
The next screen allows you to further customize the software packages to be installed.
This is where you can choose to install a bare-bones system or install all the packages
available on the installation medium. Be warned: A full/everything install is not a good
idea for a server-grade system such as the one we are trying to set up.
The GNOME Desktop Environment might already be selected for you—GNOME is
a popular desktop environment.
In addition to the package groups that are selected by default, we will install the
KDE (K Desktop Environment) package group. This additional selection will allow you
to sample another popular desktop environment that is available to Linux. There is an
age-old holy war regarding which of the desktop environments is the best, but you will
have to play around with them to decide for yourself.
1. Select the KDE (K Desktop Environment) package group in the right pane,
and accept the other defaults. The completed screen with KDE selected is
shown here.
Chapter 2:
Installing Linux in a Server Configuration
NOTE The installer will begin the actual installation (laying out the partitions, formatting the partitions
with a file system, writing the operating system to the disk, etc.) after the next step. If you develop
cold feet at this point, you can still safely back out of the installation without any loss of data (or selfesteem). To quit the installer, simply reset your system by pressing CTRL-ALT-DEL on the keyboard or by
pushing the reset or power switch for the system.
2. Click Next to begin the installation.
NOTE If you are installing from a set of CDs, the installer will inform you of the particular discs you
need to have handy to complete the installation. You will not get this warning if you are performing a
network-based installation or using a DVD. (The steps here are being performed using a DVD.)
3. The installation will begin, and the installer will show the progress of the
installation.
35
36
Linux Administration: A Beginner’s Guide
This is also a good time to study the release notes—if any are available. The
Release Notes button is usually displayed somewhere on the Installation Progress screen.
4. Click the Reboot button in the final screen once the installation has completed.
Initial System Configuration
The system will reboot itself. After the boot process completes, you will have to click
through a quick, one-time customization process. It is here that you can view the software license, add users to the system, and so on.
1. Click Forward when you are presented with the Welcome screen.
2. You will next be presented with a license information screen. Unlike other proprietary software licenses, you might actually be able to read and understand the
Fedora license in just a few seconds! Click the Forward button to continue.
Create User
This section of the initial system configuration allows you to create a nonprivileged (nonadministrative) user account on the system. Having and using a nonprivileged account
on a system for day-to-day tasks on a system is a good system administration practice.
But we will skip the creation of any additional user at this time and do it manually later.
1. Leave all the fields empty here, and click Forward.
2. A warning dialog box will appear, urging you to create a nonprivileged user
account; click Continue.
Date and Time Configuration
This section allows you to set all date- and time-related settings for the system. The system can be configured to synchronize its time to a Network Time Protocol (NTP) server.
You can also (re)configure the time zone settings here.
1. In the Date and Time screen, make sure that the current date and time shown
reflect the actual current date and time.
2. Click on the Time Zone menu in the Date and Time screen and make sure that
the correct time zone is selected. Click Forward when done.
Hardware Profile
The next section, which is optional, allows you to submit a profile of your current hardware setup to the Fedora project maintainers. The information sent does not include any
personal information, and the submission is anonymous.
Chapter 2:
Installing Linux in a Server Configuration
1. Accept the preselected default, and click Finish.
2. If you get a dialog box prompting you to reconsider sending the hardware profile, go with your heart.
Login
The system is now set up and ready for use. You will be presented with a Fedora login
screen similar to the one shown here. To log on to the system, enter root as the username,
and enter root’s password.
INSTALLING UBUNTU SERVER
Here we provide a quick overview of installing the Ubuntu Linux distribution in a server
configuration.
First you need to download the ISO image for Ubuntu Server. The ISO image that
was used on our sample system was downloaded from http://mirrors.kernel.org/
ubuntu-releases/8.04/ubuntu-8.04-server-i386.iso.
37
38
Linux Administration: A Beginner’s Guide
The downloaded CD image needs to be burnt to a CD. The same cautions and rules
that were stated during the burning of the Fedora image also apply here. After burning
the ISO image onto a CD, you should now have a bootable Ubuntu Server distribution
media. Unlike the Fedora installer or the Ubuntu Desktop installer, the Ubuntu Server
installer is text-based and is not quite as pretty as the others. Complete the following
steps to start and complete the installation.
Initial System Configuration
1. Insert the Ubuntu Server install media into the system’s optical drive.
2. Make sure that the system is set to use the optical drive as its first boot media in
the system BIOS.
3. Reboot the system if it is currently powered on.
4. Once the system boots off the install media, you will be presented with an initial language selection splash screen. On our sample system, we press enter to
accept the default English language. The installation boot menu shown next will
be displayed.
5. Make sure that the Install Ubuntu Server option is selected, and then press
enter.
6. Select English in the Choose Language screen.
Chapter 2:
Installing Linux in a Server Configuration
7. Select a country in the next screen. The installer will automatically suggest a
country based on your earlier choice. If this is correct, press enter to continue. If
not, manually select the right country and press enter.
8. Next comes the Keyboard Layout section of the installer. On our sample system,
we choose “No” to manually pick the keyboard layout.
9. Select USA when prompted for the origin of the keyboard in the next screen, and
press enter.
10. Select USA again when prompted for keyboard layout, and press enter.
Network Configuration
11. Next comes the Configure the Network section. Type ubuntu-serverA in the
Hostname field, and then press enter.
Time Zone Configuration
12. At the Configure the Clock screen, select the appropriate time zone, and press
enter.
Disk Partition Setup
13. The Partition Disk section of the installation follows. Use the arrow key on your
keyboard to select the Guided – Use Entire Disk and Set Up LVM option, as
shown, and then press enter.
39
40
Linux Administration: A Beginner’s Guide
14. Another screen will appear, prompting you to select the disk to partition. Accept
the default and press enter.
15. If prompted to write the changes to disk and configure LVM, select Yes and press
enter. You might get a different prompt if you are installing the operating system on a disk with existing partitions or volumes. In that case, you will need to
confirm that you want to remove any existing partitions or volumes in order to
continue.
NOTE This section of the installer allows you to customize the actual partition structure of the
system. It is here that you can elect to set up different file systems for different uses (e.g., /var, /home,
etc.). The same concept used in creating the different partitions during the Fedora installation earlier
transfers over for Ubuntu. For the sake of brevity, we won’t do this on our sample system. We will
instead accept the default partition and LVM layout recommended by the installer. As a result, we will
end up with only three file systems: /boot , /, and swap.
16. A summary of the disk partitions and LVM layout will be displayed in the next
screen. You will be prompted to write the changes to disk. Select Yes and press
enter.
17. The base software installation begins.
Users and Password Setup
18. Next you will be presented with the Set Up Users and Passwords screen. Type in
the full name, Ying Yang, in the Full Name field, and then press enter.
19. Type yyang in the Username For Your Account field. Press enter to continue.
20. Create a password for the user “yyang.” Enter the password 19ang19 for the
user, and press enter. Retype the same password at the next screen to verify the
password. Press enter again when done.
NOTE You might be prompted for proxy server information at some point during this stage of the
install. You can safely ignore the prompt and continue.
21. The next screen will inform you that your system has only the core system software installed. Since we are not ready to do any software customization at this
time, ignore this section and press enter to continue.
NOTE If at any point you are prompted for UTC settings for the system, select Yes to confirm that
the system clock is set to UTC and then press ENTER.
Chapter 2:
Installing Linux in a Server Configuration
22. Once done, you will be presented with the Installation Complete screen and you
will be prompted to remove the installation media. Press enter to continue.
23. The installer will complete the installation process by rebooting the system.
Once the system reboots, you will be presented with a login screen. You can log
in as the user that was previously created during the installation. The username
is yyang and the password is 19ang19.
SUMMARY
You have successfully completed the installation process. If you are still having problems
with the installation, be sure to visit Fedora’s web site at http://fedora.redhat.com and
the Ubuntu web site at www.ubuntu.com and take a look at the various manuals and
tips available.
The version release notes are also a good resource for specific installation issues.
Even though the install process discussed in this chapter used Fedora as the operating system of choice (with a quick overview of the Ubuntu Server install process), you
can rest assured that the installation concepts for other Linux distributions are virtually
identical. The install steps also introduced you to some Linux/UNIX-specific concepts
that will covered in more detail in later chapters (e.g., hard disk naming conventions and
partitioning under Linux).
41
This page intentionally left blank
3
Managing Software
43
Copyright © 2009 by The McGraw-Hill Companies. Click here for terms of use.
44
Linux Administration: A Beginner’s Guide
S
ystem administrators deal with software or application management on systems in
various ways. You have the class of system administrators who like to play it safe
and generally abide by the principle of “if it’s not broken, don’t fix it.” This approach
has its benefits as well as its drawbacks. One of the benefits is that the system tends to be
more stable and behave in a predictable manner. Nothing has changed drastically on the
system, so it should pretty much be the same way it was yesterday, last week, last month,
etc. The drawback to this approach is that the system might lose the benefits of bug fixes
and security fixes that are available for the various installed applications.
Another class of system administrators takes the exact opposite approach: They like
to install the latest and greatest piece of software available out there. This approach also
has its benefits and drawbacks. One of its benefits is that the system tends to stay current
as security flaws in applications are discovered and fixed. The obvious drawback is that
some of the newer software might not have had time to benefit from the maturing process that comes with age and, hence, may behave in slightly unpredictable ways.
Regardless of your system administration style, you will find that a great deal of
your time will be spent interacting with the various software components of the system,
whether in keeping them up-to-date maintaining what you already have installed, or
installing new software.
There are a couple of basic approaches to installing software on a Linux system. One
approach is to use the package manager for the distribution. A common method for Red
Hat–like systems such as Fedora and Red Hat Enterprise Linux (RHEL) is to use the
Red Hat Package Manager (RPM). The tool of choice for Debian-based systems, such as
Ubuntu, Kubuntu, and Debian, is the Advanced Packaging Tool (APT). Another more
traditional approach is to compile and install the software by hand using the standard
GNU compilation method or the specific software directives. We will cover these methods in this chapter.
THE RPM PACKAGE MANAGER
The Red Hat Package Manager (RPM) allows the easy installation and removal of software packages—typically, precompiled software. A package consists of an archive of
files and other metadata.
It is wonderfully easy to use, and several graphical interfaces have been built around
it to make it even easier. Several Linux distributions (distros) and various third parties
use this tool to distribute and package their software. In fact, almost all of the software
mentioned in this book is available in RPM form. The reason you’ll go through the
process of compiling software yourself in other chapters is so that you can customize
the software to your system, as such customizations might not be readily possible in
an RPM.
An RPM file is a package that contains files needed for the software to function correctly. These files can be configuration files, binaries, and even pre- and postscripts to run
while installing the software.
Chapter 3:
Managing Software
NOTE In the present context mentioned, we are assuming that the RPM files contain precompiled
binaries. However, adhering to the open source principle, the various commercial and noncommercial
Linux distros are obliged to make the source code for most GNU binaries available. (Those who don’t
make it available by default are obliged to give it to you if you ask for it.) Some Linux vendors stick
to this principle more than others. Several Linux vendors, therefore, make the source code for their
binaries available in RPM form. For instance, Fedora and SuSE also make source code available
as an RPM, and it is becoming increasingly common to download and compile source code in this
fashion.
The RPM tool performs the installation and uninstallation of RPMs. The tool also
maintains a central database of what RPMs you have installed, where they are installed,
when they were installed, and other information about the package.
In general, software that comes in the form of an RPM is less work to install and
maintain than software that needs to be compiled. The trade-off is that by using an RPM,
you accept the default parameters supplied in the RPM. In most cases, these defaults are
acceptable. However, if you need to be more intimately aware of what is going on with
a piece of software, you may find that by compiling the source yourself, you will learn
more about what software components and options exist and how they work together.
Assuming that all you want to do is install a simple package, RPM is perfect. There
are several great resources for RPM packages, including the following:
▼
http://rpm.pbone.net
■
http://ftp.redhat.com
■
http://mirrors.kernel.org
▲
http://freshrpms.net
Of course, if you are interested in more details about RPM itself, you can visit the
RPM web site at www.rpm.org. RPM comes with Fedora, OpenSuSE, Mandrake, and
countless other Red Hat derivatives, and, most surprising of all, the Red Hat version of
Linux! If you aren’t sure if RPM comes with your distribution, check with your vendor.
NOTE Although the name of the package says “Red Hat,” the software can be used with other
distributions as well. In fact, RPM has even been ported to other operating systems, such as Solaris,
AIX, and IRIX. The source code to RPM is open source software, so anyone can take the initiative to
make the system work for them.
The primary functions of the RPM are
▼
Querying, installing, and uninstalling software
■
Maintaining a database that stores various items of information about the
packages
▲
Packaging other software into an RPM form
45
46
Linux Administration: A Beginner’s Guide
Table 3-1, which includes frequently used RPM options, is provided for reference
purposes only.
Command-Line Option
Description
--install
This installs a new package.
--upgrade
This upgrades or installs the package currently
installed to a newer version.
--erase
Removes or erases an installed package.
--query
This is the option used for querying.
--force
This is the sledgehammer of installation. Typically,
you use it when you’re knowingly installing an odd
or unusual configuration and RPM’s safeguards are
trying to keep you from doing so. The --force
option tells RPM to forego any sanity checks and just
do it, even if it thinks you’re trying to fit a square peg
into a round hole. Be careful with this option.
-h
Prints hash marks to indicate progress during an
installation. Use with the -v option for a pretty
display.
--percent
Prints the percentage completed to indicate progress.
It is handy if you’re running RPM from another
program, such as a Perl script, and you want to know
the status of the install.
-nodeps
If RPM is complaining about missing dependency
files, but you want the installation to happen anyway,
passing this option at the command line will cause
RPM to not perform any dependency checks.
-q
Queries the RPM system for information.
--test
This option does not perform a real installation; it just
checks to see whether an installation would succeed.
If it anticipates problems, it displays what they’ll be.
-V
Verifies RPMs or files on the system.
-v
Tells RPM to be verbose about its actions.
Table 3-1. Common RPM Options
Chapter 3:
Managing Software
THE DEBIAN PACKAGE MANAGEMENT SYSTEM
The Debian Package Management System (DPMS) is the foundation for managing software on Debian and Debian-like systems. As is expected of any software management
system, DPMS provides for easy installation and removal of software packages. Debian
packages end with the .deb extension.
At the core of the DPMS is the dpkg (Debian Package) application. dpkg works in
the back-end of the system, and several other command-line tools and graphical user
interface (GUI) tools have been written to interact with it. Packages in Debian are fondly
called “.deb” files. dpkg can directly manipulate .deb files. Various other wrapper tools
have been developed to interact with dpkg, either directly or indirectly.
APT
APT is a highly regarded and sophisticated toolset. It is an example of a wrapper tool
that interacts directly with dpkg. APT is actually a library of programming functions that
are used by other middle-ground tools, like apt-get and apt-cache, to manipulate
software on Debian-like systems. Several user-land applications have been developed
that rely on APT. (User-land refers to non-kernel programs and tools.) Examples of such
applications are synaptic, aptitude, and dselect. The user-land tools are generally more
user-friendly than their command-line counterparts. APT has also been successfully
ported to other operating systems.
One fine difference between APT and dpkg is that APT does not directly deal with
.deb packages; instead, it manages software via the locations (repositories) specified in a
configuration file. This file is the sources.list file. APT utilities use the sources.list file to
locate archives (or repositories) of the package distribution system in use on the system.
It should be noted that any of the components of the DPMS (dpkg, apt, or the GUI
tools) can be used to directly manage software on Debian-like systems. The tool of choice
depends on the user’s level of comfort and familiarity with the tool in question.
Figure 3-1 shows what can be described as the DPMS triangle. The tool at the apex
of the triangle (dpkg) is the most difficult to use and the most powerful, followed by the
next easiest to use (APT), and then followed finally by the user-friendly user-land tools.
dpkg
APT (apt-get, etc.)
synaptic, aptitude, adept, dselect, etc.
Figure 3-1. DPMS triangle
47
48
Linux Administration: A Beginner’s Guide
MANAGING SOFTWARE USING RPM
In the following sections, we will cover details of querying, installing, uninstalling, and
verifying software on Red Hat–based systems. Actual examples are used to facilitate
understanding.
Querying for Information the RPM Way
(Getting to Know One Another)
One of the best ways to begin any relationship is by getting to know the other party.
Some of the relevant information might be the person’s name, what they do for a living,
date of birth, what they like or dislike, etc. The same rules apply to RPM-type packages
or dpkg packages. After you obtain a piece of software (from the Internet, from the
distribution’s CD/DVD, from a third party, etc.), you should get to know the software
before making it a part of your life . . . sorry—your system. This functionality was built
into RPM and dpkg from the beginning, and it is easy to use.
When you get used to Linux/UNIX, you may find that software names are somewhat intuitive, and you can usually tell what a package is just by looking at its name.
For example, to the uninitiated, it may not be immediately obvious that a file named
gcc-4.1.2.rpm is a package for the “GNU Compiler collection.” But once you get used
to the system and you know what to look for, it becomes more intuitive. You can also
use RPM or dpkg to query for other types of information, such as the package’s build
date, its weight ( . . . sorry—its size), its likes and dislikes ( . . . sorry—its dependencies), etc.
Let’s start by trying a few things using RPM and dpkg. Begin by logging into the
system and start a terminal (as per the previous Tip).
Querying for All Packages
Use the rpm command to list all the packages that are currently installed on your system.
At the shell prompt, type:
[root@fedora-serverA ~]# rpm --query --all
This will give you a long listing of software installed.
NOTE Like most Linux commands, the rpm command also has its own long forms and short (or
abbreviated) forms of options or arguments. For example, the short form of the --query option
is -q, and the short form for --all is -a. We will mostly use short forms in this book, but we’ll
occasionally use the long forms just so you can see their relationship.
Chapter 3:
Managing Software
Getting Down to Business
The previous chapter walked you through the installation process. Now that you
have a working system, you will need to log into the system to carry out the exercises in this and other chapters of the book. Most of the exercises will implicitly ask
you to type a command. Although it may seem like stating the obvious, whenever
you are asked to type a command, you will have to type it into a console at the
shell prompt. This is akin to the DOS prompt in Microsoft Windows, but is more
powerful.
There are several ways to type a command at the shell. One way is to use a
nice, windowed (GUI) terminal; another is to use the system console. The windowed consoles are known as terminal emulators (or pseudo-terminals), and
there are tons of them. After logging into your chosen desktop (GNOME, KDE,
Xforms Cool Environment [XFCE], etc.), you can usually launch a pseudoterminal by right-clicking the desktop and selecting Launch Terminal from
the context-sensitive menu. If you don’t have that particular option, look for
an option in the menu that says Run Command (or press the alt and f2 keys
simultaneously to launch the Run Application dialog box). After the Run dialog box appears, you can then type the name of a terminal emulator into the
Run text box. A popular terminal emulator that is almost guaranteed (or your
money back!) to exist on all Linux systems is the venerable xterm. If you are in
a GNOME desktop, the gnome-terminal is the default. If you are using KDE,
the default is konsole.
Querying Details for a Specific Package
Let’s zero in on one of the packages listed in the output of the preceding command, the
bash application. Use rpm to see if you indeed have the bash application installed on
your system.
[root@fedora-serverA ~]# rpm --query bash
bash-3.2-*
The output should be something similar to the one shown. It shows that you do
indeed have the package called bash installed. It also shows the version number
appended to the package name. Note that the version number of the output on your
system might be different; however, the main package name will almost always be
the same, i.e., bash is bash is bash is bash in OpenSuSE, Fedora, Mandrake, RHEL,
Ubuntu, etc.
49
50
Linux Administration: A Beginner’s Guide
Which brings us to the next question. What is bash and what does it do? To find
out, type
[root@fedora-serverA ~]# rpm
Name
: bash
Version
: 3.2
....
Source Exif Data:
File Type : PDF
File Type Extension : pdf
MIME Type : application/pdf
PDF Version : 1.6
Linearized : No
XMP Toolkit : 3.1-702
Modify Date : 2008:12:08 11:10:15+08:00
Create Date : 2008:12:08 11:08:11+08:00
Metadata Date : 2008:12:08 11:10:15+08:00
Creator Tool : Acrobat: pictwpstops filter 1.0
Format : application/pdf
Title : Linux Administration : a Beginner's Guide {McGraw Hill Professional; 5th Ed.}
Description : TEAM DDU
Creator : Soyinka, Wale.
Document ID : uuid:93e71ff0-202b-4342-acaa-8c517ec94129
Instance ID : uuid:f69a8fa1-5834-440d-aa81-ad590e434a6a
Producer : Acrobat Distiller 7.0.5 for Macintosh
Has XFA : No
Page Count : 689
Subject : TEAM DDU
Author : Soyinka
Warning : [Minor] Ignored duplicate Info dictionary
EXIF Metadata provided by EXIF.tools