LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/guide/docbook/lame/linux-admin-made-easy.sgml

5735 lines
259 KiB
Plaintext
Raw Blame History

<!DOCTYPE Book PUBLIC "-//Davenport//DTD DocBook V3.0//EN">
<!-- This is the Linux Administration Made Easy SGML source file. -->
<Book>
<!-- Title information -->
<BookInfo>
<Title>Linux Administration Made Easy</Title>
<Author><FirstName>by Steve Frampton, &lt;frampton@LinuxNinja.com&gt;
</FirstName></Author>
<PubDate>21 October 1999</PubDate>
<ReleaseInfo>v1.06, 21 October 1999</ReleaseInfo>
<Abstract>
<Para>The <Quote>Linux Administration Made Easy</Quote>
(<Acronym>LAME</Acronym>) guide attempts to describe day-to-day
administration and maintenance issues commonly faced by Linux system
administrators. Part of the Linux Documentation Project.</Para>
</Abstract>
</BookInfo>
<!-- Table of contents -->
<TOC></TOC>
<!-- Begin the document -->
<Chapter id="preface"><Title>Preface</Title>
<Sect1 id="acknowledgements"><Title>Acknowledgements</Title>
<Para>I would like to thank the Linux community; particularly those
members who have participated in USENET and mailing lists with lots of
helpful tips, answers, and suggestions on how to use Linux at its best.
Your contributions have benefited us all.</Para>
<Para>This document was written in the DocBook SGML format, and then
rendered using SGMLTools 2.x to a variety of document formats, including
HTML, postscript, Rich-Text-Format, and PDF. For more information on
SGMLTools, see the project web site at <ULink URL="http://www.sgmltools.org/">
http://www.sgmltools.org/</ULink></Para>
</Sect1>
<Sect1 id="copyright-and-disclaimer"><Title>Copyright Information and Legal Disclaimers</Title>
<Para>Copyright &copy; 1997-1999 by Steve Frampton. This material may
be distributed only subject to the terms and conditions set forth in the
Open Publication License, v0.4 or later (the latest version is presently
available at <ULink URL="http://www.opencontent.org/openpub/">
http://www.opencontent.org/openpub/</ULink>).</Para>
<Para>I've written this documentation and am providing it free to the
Linux community as a public-service. I have made every attempt to ensure
that the information contained herein is timely, accurate, and helpful,
but in no way will I be held liable for any damage(s) caused directly or
indirectly by any misinformation contained herein.</Para>
<Para>I will not appreciate being flamed for any errors or omissions.
However, if you notice a glaring inaccuracy, or have suggestions for
further improvement, please, let me know. However, please check the
version number and date of this document (see the table of contents) to
ensure you are looking at the most recent version. If this document is
more than three months old, please check the Linux Documentation Project
home page at
<ULink URL="http://metalab.unc.edu/LDP/">http://metalab.unc.edu/LDP/</ULink>
in case a newer version is available.</Para>
<Para>This document, currently, should be considered moderate-beta. I
began writing it in 1997, and continue to update it as time permits.
Development in the Open Source community continues at a rapid pace, and at
times it is a challenge to keep this document up to date. As such, this
document may have one or more sections which contain obsolete
information.</Para>
<Para>In short, I make no guarantees for any of this information to be
correct. If it helps you out, that's great!</Para>
</Sect1>
<Sect1 id="help-plea"><Title>A Plea for Help</Title>
<Para>If you find this document useful and would like to express your
appreciation for it, please consider donating a food item or two to your
local food bank.</Para>
</Sect1>
</Chapter>
<Chapter id="introduction"><Title>Introduction</Title>
<Para><Emphasis>Linux 2.2.0, released 25-Jan-99: Onwards to World
Domination...</Emphasis></Para>
<Para>Perhaps you are fairly new to Linux and were hoping to find a
summary of the kinds of configuration and administrative tasks that may be
required of you from time to time. If this sounds like you, perhaps this
document is just what you've been looking for!</Para>
<Sect1 id="scope"><Title>Scope</Title>
<Para>This documentation will attempt to summarize the installation and
configuration, as well as the day-to-day administrative and maintenance
procedures that should be followed to keep a Linux-based server or desktop
system up and running. It is geared to an audience of both corporate as
well as home users. It is not intended to be a full overview of Unix
operations, as there are several good texts available as well as on-line
documentation which can be referred to in cases where more detailed
information is required.</Para>
<Para>In general, your Linux system can operate with a minimum of user
maintenance. Routine tasks, such as rotating and discarding of system
logs, are automated. Therefore, for the most part, even with very little
user intervention, Linux will hum along doing its job. However, in cases
of custom needs or system failure this documentation may prove
useful.</Para>
<Para>I currently use Linux both at home and at my place of employment.
It has served me well, and has worked as a reliable Internet and
file/print service for my employer for over four years now.</Para>
</Sect1>
<Sect1 id="choosing-linux"><Title>Choosing a Linux Distribution</Title>
<Para>There is quite a variety of Linux distributions from which to choose
from. Each distribution offers the same base Linux kernel and system
tools, but differ on installation method and bundled applications. Each
distribution has its own advantages as well as disadvantages, so it is
wise to spend a bit of time researching which features are available in a
given distribution before deciding on one.</Para>
<Para>The following is a list of a few web sites you can visit, which will
describe a given Linux distribution as well as provide information on how
you can download or purchase it:</Para>
<VariableList> <VarListEntry> <Term><ULink
URL="http://www.redhat.com/">http://www.redhat.com/</ULink</Term>
<ListItem><Para>The Red Hat distribution, by commercial vendor Red Hat
Software, Inc. is one of the most popular distributions. With a choice of
GUI- and text-based installation procedures, Red Hat 6.1 is possibly the
easiest Linux distribution to install. It offers easy upgrade and
package management via the ``<Literal>RPM</Literal>'' utility, and
includes both the GNU Network Object Model Environment
(<Emphasis>GNOME</Emphasis>) and the ``K Desktop Environment''
(<Emphasis>KDE</Emphasis>), both popular GUI window managers for the X
Window System. This distribution is available for the Intel, Alpha, and
Sparc platforms.</Para></ListItem> </VarListEntry>
<VarListEntry> <Term><ULink
URL="http://www.debian.org/">http://www.debian.org/</ULink></Term>
<ListItem><Para>The Debian distribution, by non-profit organization known
as <Quote>The Debian Project</Quote> is the darling of the Open Source
community. It also offers easy upgrade and package management via the
``<Literal>dpkg</Literal>'' utility. This distribution is available for
the Intel, Alpha, Sparc, and Motorola (Macintosh, Amiga, Atari)
platforms.</Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term><ULink URL="http://www.suse.com/">http://www.suse.com/</ULink></Term>
<ListItem><Para>The S.u.S.E. distribution, by commercial vendor S.u.S.E.,
is another popular distribution, and is the leading distribution in
Europe. It includes the ``K Desktop Environment''
(<Emphasis>KDE</Emphasis>), and also offers easy upgrade and package
management via the ``<Literal>YaST</Literal>'' utility. This distribution is
available for both Intel and Alpha platforms.</Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term><ULink URL="http://www.caldera.com/">http://www.caldera.com/</ULink></Term>
<ListItem><Para>The OpenLinux distribution, by commercial vendor Caldera,
is aimed towards corporate users. With the new OpenLinux 2.2 release,
Caldera has raised the bar with what appears to be the easiest to install
distribution of Linux available today. In addition, it comes standard
with the ``K Desktop Environment'' (<Emphasis>KDE</Emphasis>). This
distribution is available for the Intel platform only.</Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term><ULink URL="http://www.linux-mandrake.com/">http://www.linux-mandrake.com/</ULink></Term
<ListItem><Para>The Mandrake distribution, by commercial vendor
MandrakeSoft S.A., integrates the Red Hat or Debian distributions (your
choice) with additional value-add software packages than those included
with the original distributions.</Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term><ULink URL="http://www.slackware.com/">http://www.slackware.com/</ULink></Term>
<ListItem><Para>The Slackware distribution, by Patrick Volkerding of
Walnut Creek Software, is the grandfather of modern distributions of
Linux. Offers a fairly simple installation procedure, but poor upgrade
and package management. Still based on the libc libraries but the next
version will probably migrate to the newer glibc. Recommended for users
who are more technical and familiar with Linux. This distribution is
available for the Intel platform only.</Para></ListItem>
</VarListEntry>
</VariableList>
<Para>Listing all the available distributions is beyond the scope of this
document, so I've listed only the most popular. However, further
information on the available distributions can be found in the
``<Emphasis>Distribution-HOWTO</Emphasis>'' guide, available at <ULink
URL="http://metalab.unc.edu/LDP/HOWTO/Distribution-HOWTO.html">
http://metalab.unc.edu/LDP/HOWTO/Distribution-HOWTO.html</ULink></Para>
<Tip><Para>Tip: If you decide to buy your distribution on CD-ROM, you might be
able to find better pricing at other resellers (for example, I've been
quite satisfied on several dealings with Internet-based software vendor
<ULink URL="http://www.cheapbytes.com/">http://www.cheapbytes.com/</ULink>).
On the other hand, you may wish to pay the higher price to the
distribution vendors to ensure that their offerings continue to
improve.</Para></Tip>
<Para>My distribution of choice is Red Hat Linux (it also happens to be,
unarguably, the most popular distribution among Linux users). For almost
three years, I was a die-hard Slackware fanatic (before that I had messed
around a bit with a small distribution from tsx-11 way back in the kernel
0.90a days), and although I've tried Red Hat in the past, I never could
bring myself to say anything good about their distributions. Then, I
tried Red Hat 5.1, and found myself quickly converted! In my opinion,
with 5.1, Red Hat finally <Quote>got it right</Quote>.</Para>
<Para>Some of the reasons I have become a fan of the Red Hat distribution
include the ease of installation, multi-platform support (until recently,
Red Hat was the only distribution vendor to provide its distribution for
Intel, Alpha, and Solaris platforms), and, above all, the RPM package
manager. In addition, they put updates to included RPM's on their FTP
site (at <ULink URL="ftp://ftp.redhat.com/redhat/updates/">ftp://ftp.redhat.com/redhat/updates/</ULink>)
as they become available, which is a good way of keeping one's system up
to date and free of any bugs or security problems that are discovered from
time to time.</Para>
<Para>Since first loading Red Hat 5.1 on an otherwise unused computer at work
for testing purposes, I have converted two of our main Internet/File &amp;
Print servers over from Slackware to Red Hat and haven't regretted it.
I've also loaded it on my system and home, and installed it on three other
systems as light servers as well. In addition, I have had the opportunity
to not only play with the Intel-based versions but with Alpha- and
Sparc-based versions as well. Recently, I've moved all the Linux systems
I am responsible for over to Red Hat 6.1.</Para>
<Para>Therefore, this document has a definite Red Hat <Quote>feel</Quote>
to it, and is most relevant for the Intel-based 6.1 version. However,
hopefully most or at least some of the information contained in this
document will be useful to users of other distributions.</Para>
</Sect1>
</Chapter>
<Chapter id="linux-overview"><Title>Linux Overview</Title>
<Para>Welcome to Linux!</Para>
<Sect1 id="what-is-linux"><Title>What is Linux?</Title>
<Para>Linux is a true 32-bit operating system that runs on a variety of
different platforms, including Intel, Sparc, Alpha, and Power-PC (on some
of these platforms, such as Alpha, Linux is actually 64-bit). There are
other ports available as well, but I do not have any experience with
them.</Para>
<Para>Linux was first developed back in the early 1990s, by a young
Finnish then-university student named Linus Torvalds. Linus had a
<Quote>state-of-the-art</Quote> 386 box at home and decided to write an
alternative to the 286-based Minix system (a small unix-like
implementation primarily used in operating systems classes), to take
advantage of the extra instruction set available on the then-new chip, and
began to write a small bare-bones kernel.</Para>
<Para>Eventually he announced his little project in the USENET group
<ULink URL="news:comp.os.minix">comp.os.minix</ULink>, asking for
interested parties to take a look and perhaps contribute to the project.
The results have been phenomenal!</Para>
<Para>The interesting thing about Linux is, it is completely free! Linus
decided to adopt the GNU Copyleft license of the Free Software
Foundation, which means that the code is protected by a copyright --
but protected in that it must always be available to others.</Para>
<Para>Free means <Emphasis>free</Emphasis> -- you can get it for free, use
it for free, and you are even free to sell it for a profit (this isn't as
strange as it sounds; several organizations, including Red Hat, have
packaged up the standard Linux kernel, a collection of GNU utilities, and
put their own <Quote>flavour</Quote> of included applications, and sell
them as distributions. Some common and popular distributions are
Slackware, Red Hat, SuSe, and Debian)! The great thing is, you have
access to source code which means you can customize the operating systems
to your <Emphasis>own</Emphasis> needs, not those of the <Quote>target
market</Quote> of most commercial vendors.</Para>
<Para>Linux can and should be considered a full-blown implementation of unix.
However, it can not be called <Quote>Unix</Quote>; not because of
incompatibilities or lack of functionality, but because the word
<Quote>Unix</Quote> is a registered trademark owned by AT&amp;T, and the
use of the word is only allowable by license agreement.</Para>
<Para>Linux is every bit as supported, as reliable, and as viable as any
other operating system solution (well, in my opinion, quite a bit
more so!). However, due to its origin, the philosophy behind it, and the
lack of a multi-million dollar marketing campaign promoting it, there are
lot of myths about it. People have a lot to learn about this wonderful
OS!</Para>
</Sect1>
<Sect1 id="linux-myths"><Title>Breaking the Myths</Title>
<Para>I've been using Linux for several years, and I like to think I know
a bit about the operating system and what it can and cannot do. As I'm an
avid USENET reader, I follow the latest developments and of course, the
various flame-wars that invariably crop up (those darn cross-posting
advocacy people! ;-) ). I've seen my share of myths (often called
<Emphasis>FUD</Emphasis> -- <Quote>Fear, Uncertainty, Doubt</Quote> which
seems to be a common tactic used by commercial technology vendors to
frighten their market away from competing technologies) that more than a
few people believe. So, let me try to run down a few of the more common
ones and attempt to shatter them. :-)</Para>
<ItemizedList Mark="Bullet" Spacing="Normal">
<ListItem><Para>Linux is freeware, hence, it is a toy.</Para></ListItem>
</ItemizedList>
<Para>Some people seem to have the notion that, because a piece of
software was written by volunteers with no profit motive in mind, that the
results must clearly be inferior to commercial-grade offerings.</Para>
<Para>This may have been true in the past (I mean, there
<Emphasis>was</Emphasis> a lot of freeware which was absolute garbage in
the DOS and early Windows world), but it is most certainly not true in
recent days.</Para>
<Para>The power of the Internet has made it possible to bring together
some of the brightest minds in the globe, allowing collaboration on
projects they find interesting. The people who have put a hand into
developing Linux or the thousands of GNU utilities and applications
packages are from a diverse background, and all of them have different
personal reasons for wanting to contribute.</Para>
<Para>Some are hard-core hackers who develop for the love of coding,
others have a need for something (for example, a network traffic monitor
for a LAN at work) and decide to write it themselves, others are academics
and computer scientists who are using Linux for its research
qualities.</Para>
<Para>Unlike a commercial offering where a package is developed and sold,
source code excluded, to the end-user, code used in Linux is scrutinized,
debugged, and improved upon by anyone who has the interest and ability.
This act of peer-review is one of the reasons that Linux offers the high
reliability and high performance that it does.</Para>
<Para>Don't forget: The Internet itself was built and runs almost
exclusively on Open Source projects. The e-mail you exchange on a daily
basis with people around the world has an 80% chance of being handled on
one or both ends by Sendmail, the web pages you browse while
<Quote>Surfin' the Web</Quote> are served to you by Apache on over 50% of
the world's web sites. Reliable enough for you?</Para>
<ItemizedList Mark="Bullet" Spacing="Normal">
<ListItem><Para>There is no support for Linux.</Para></ListItem>
</ItemizedList>
<Para>Hearing this myth somewhat sickens me. And supposedly the
<Quote>other</Quote> vendors <Emphasis>do</Emphasis> offer support? I've
had personal experience with one very popular commercial operating system,
where the vendor's so-called <Quote>support</Quote> was completely
useless.</Para>
<Para>First of all, there <Emphasis>is</Emphasis> support for Linux.
Yes, commercial support. There are some companies that can provide as
much support as you are willing to pay for; offering telephone and e-mail
support, many offering to come right to your door to deal with the
problem!</Para>
<Para>However, in 99% of the situations you will run into with Linux, you
will be able to accomplish what you wish if you can simply get the answer
to a question or two. This is easily accomplished on USENET or on any of
the many mailing lists available!</Para>
<Para>I've never had a problem I couldn't find a solution to, by either
searching on <ULink URL="http://www.dejanews.com/">
http://www.dejanews.com/</ULink>, or by asking in one of the
comp.os.linux.* newsgroups. Normally I can receive an answer to any of the
support issues I ask about within three to twelve hours of my
posting.</Para>
<Para>Another interesting aspect of Linux is that, because the source code
for the entire kernel and most of the other operating system components is
freely available, key-support issues such as security, denial of service,
or CPU bugs (such as Intel's <Emphasis>F00F</Emphasis> fatal exception)
are tracked down and solved <Emphasis>very</Emphasis> quickly -- usually
an order of magnitude faster than solutions offered for similar or
identical problems on the commercial offerings. So, where's the
commercial support!?</Para>
<Para>There are countless others that I would like to debunk, but that is
beyond the scope of this document. However, for further myth debunking,
check out the <Quote>Linux Myth Dispeller</Quote> at <ULink
URL="http://www.KenAndTed.com/KensBookmark/linux/index.html">
http://www.KenAndTed.com/KensBookmark/linux/index.html</ULink> as well as
<Quote>The Linux FUDfactor FAQ</Quote> at <ULink
URL="http://www.geocities.com/SiliconValley/Hills/9267/fud2.html">
http://www.geocities.com/SiliconValley/Hills/9267/fud2.html</ULink></Para>
</Sect1>
<Sect1 id="user-perspective"><Title>One User's Perspective</Title>
<Para>I use Linux both at work and at home.</Para>
<Para>At my place of employment, we are using Linux to provide Internet
services for hundreds of users. These services include TACACS (dial-in
modem user) authentication, web page hosting and proxy caching, as well as
SMTP and POP services. In addition, we are using Linux to provide NFS
services, and also for providing and mounting SMB-protocol
(WfW/Win95/WinNT) file &amp; print and FAX services using the Samba
package.</Para>
<Para>At home, I use Linux for my personal needs, such as Internet
services, software development, and of course game playing (seeing Quake
II running on a Linux box is a thing of beauty)! One of the things I love
about Linux is, no matter how hard I pound on it, it does
<Emphasis>not</Emphasis> crash! It's also a great way to learn, develop,
and maintain my Unix skills.</Para>
<Para>I am using the Red Hat 6.1 distribution of Linux (see <ULink
URL="http://www.redhat.com/">http://www.redhat.com/</ULink> for more
information). This distribution includes all the necessary software for a
full-blown unix system -- shells, compilers &amp; interpreters, networking
support, the X Window System, and all Internet services (eg. Mail, news,
web server, telnet, etc.). The distribution comes standard with Linux
kernel 2.2.12.</Para>
<Para>At my place of employment, the Linux-based system we use as our
primary Internet server has the following configuration:</Para>
<ItemizedList Mark="Bullet" Spacing="Compact">
<ListItem><Para>Kernel: 2.2.12</Para></ListItem>
<ListItem><Para>Machine: Pentium II @ 300 MHz (bogo-mips 299.83) with PCI-bus, 256 Mb RAM</Para></ListItem>
<ListItem><Para>one 3 Gb Fujitsu IDE hard drive (/dev/hda)</Para></ListItem>
<ListItem><Para>four 4.4 Gb Quantum Fireball SCSI hard drives (/dev/sd0 through /dev/sd3),</Para></ListItem>
<ListItem><Para>24x speed SCSI CD-ROM (/dev/scd0),</Para></ListItem>
<ListItem><Para>Adaptec AHA-131 SCSI controller</Para></ListItem>
<ListItem><Para>HP SCSI DAT tape drive (/dev/st0 and /dev/nst0),</Para></ListItem>
<ListItem><Para>Intel EtherExpress Pro 10/100 Ethernet card</Para></ListItem>
</ItemizedList>
<Para>We have a second system -- an even nicer Intel box -- also running
Red Hat 5.2, running in another office location. It provides networked
file &amp; print services via Samba, local web caching via Squid, and
secondary DNS services. Unfortunately, this box is over 50 km away from
where I usually work, and therefore it's left pretty much on its own --
yet this baby is really my pride and joy! Here are some specs:</Para>
<ItemizedList Mark="Bullet" Spacing="Compact">
<ListItem><Para>Kernel: 2.2.12</Para></ListItem>
<ListItem><Para>Machine: Pentium II @ 350 MHz (bogo-mips 349.80) with PCI-bus, 256 Mb RAM</Para></ListItem>
<ListItem><Para>one 4.1 Gb Quantum Fireball SCSI hard drive (/dev/sda)</Para></ListItem>
<ListItem><Para>four 9.4 Gb Quantum Fireball SCSI hard drives (/dev/rd/c0d0, /dev/rd/c0d1) as hardware RAID level 5 array,</Para></ListItem>
<ListItem><Para>36x speed SCSI CD-ROM (/dev/scd0),</Para></ListItem>
<ListItem><Para>BusLogic BT-948 SCSI controller</Para></ListItem>
<ListItem><Para>Mylex AcceleRAID 250 (DAC960) RAID controller,</Para></ListItem>
<ListItem><Para>HP SCSI DAT tape drive (/dev/st0 and /dev/nst0),</Para></ListItem>
<ListItem><Para>Intel EtherExpress Pro 10/100 Ethernetcard</Para></ListItem>
</ItemizedList>
<Para>Having an incredible 24+ Gb of available storage space, with
redundant storage configured as a hardware RAID5 array is a humbling
feeling. The Mylex RAID controller works great, and I would not hesitate
to recommend it to others seeking a hardware RAID solution! (If you are
interested in configuring your Linux system with a RAID array, see
<XRef LinkEnd="hardware-raid"> for details.)</Para>
<Para>We have four other Linux systems in place; an Alpha, a Sparc, and
two Intel boxes; two of which are being used in production, and then there
is my own personal system at home, but I won't bore you with the
details.</Para>
<Para>This document will attempt to remain as hardware independent as
possible but it may be helpful to you if you know where I am coming from
as far as hardware is concerned.</Para>
</Sect1>
</Chapter>
<Chapter id="install-config"><Title>Installation and Hardware Configuration</Title>
<Para>This chapter will detail the procedures needed to install Red Hat
6.1 onto an Intel system; the procedures are similar whether you choose to
install using either GUI- or text-based installation. Since much of this
information is already well documented in the Red Hat User's Guide
(provided as a paper manual in the <Quote>Official</Quote> boxed sets, included
in the ``<Literal><Filename>/doc</Filename></Literal>'' directory on the
CD, as well as available online at
<ULink URL="ftp://ftp.redhat.com/pub/redhat/redhat-6.1/i386/doc/rhinst/index.htm">
ftp://ftp.redhat.com/pub/redhat/redhat-6.1/i386/doc/rhinst/index.htm</ULink>),
I've skimmed over much of the details. However, there are a few things
which I think are lacking in the Red Hat guide, and therefore I will
attempt to cover those items in greater detail.</Para>
<Sect1 id="install-diskette"><Title>Creating an Installation Diskette</Title>
<Para>The first step in getting Red Hat's distribution of Linux onto a
system, you need to find a way of starting the installation program. The
usual method of doing so is to create an installation disk, although if
you are installing from CD-ROM, and your system's BIOS supports it, you
should be able to boot directly into the installation program from the
CD.</Para>
<Para>Otherwise, to create an installation diskette, you'll need to copy
the ``<Literal><Filename>boot.img</Filename></Literal>'' (which is simply
an image of an ext2-formatted Linux boot diskette with an additional
installation program) onto a floppy diskette. The
``<Literal><Filename>boot.img</Filename></Literal>'' file can be obtained
from the <Literal>/images</Literal> directory of the Red Hat CD-ROM disk, or
downloaded via FTP from <ULink
URL="ftp://ftp.redhat.com/">ftp://ftp.redhat.com</ULink> in the <ULink
URL="ftp://ftp.redhat.com/pub/redhat/redhat-6.1/i386/images">
/pub/redhat/redhat-6.1/i386/images</ULink> directory (assuming you are
installing Linux on an Intel box).</Para>
<Para>You can create the boot diskette either from a DOS or Windows
system, or from an existing Linux or Unix system. For your destination
diskette, you can use either an unformatted or a pre-formatted (for DOS)
diskette -- it makes no difference.</Para>
<Para>Under DOS: Assuming your CD-ROM is accessible as drive D:, you can
type:</Para>
<BlockQuote>
<Screen>
<UserInput>d:</UserInput>
<UserInput>cd \images</UserInput>
<UserInput>..\dosutils\rawrite</UserInput>
</Screen>
<Para>For the source file, enter
``<Literal><Filename>boot.img</Filename></Literal>''. For the
destination file, enter ``<Literal>a:</Literal>'' (assuming the diskette
you are created is inserted into the A: drive). The
``<Literal>rawrite</Literal>'' program will then copy the
``<Literal><Filename>boot.img</Filename></Literal>'' file onto
diskette.</Para>
</BlockQuote>
<Para>Under Linux/Unix: Assuming the
``<Literal><Filename>boot.img</Filename></Literal>'' file is located in
the current directory (you may need to mount the CD-ROM under /mnt/cdrom
and find the file in /mnt/cdrom/images), you can type:</Para>
<BlockQuote>
<Screen>
<UserInput>dd if=boot.img of=/dev/fd0</UserInput>
</Screen>
<Para>The ``<Literal>dd</Literal>'' utility will copy, as
its input file (<Quote>if</Quote>), the
``<Literal><Filename>boot.img</Filename></Literal>'' file, onto the
output file (<Quote>of</Quote>) /dev/fd0 (assuming your floppy drive is
accessible from /dev/fd0).</Para>
<Para>Unless your Linux or Unix system allows write permissions to the
floppy device, you may need to do this command as the superuser. (If you
know the root password, type ``<Literal>su</Literal>'' to become the
superuser, execute the ``<Literal>dd</Literal>'' command, and then type
``<Literal>exit</Literal>'' to return to normal user status).</Para>
</BlockQuote>
<Para>With either of the above schemes, you should now have a bootable Red
Hat 6.1 installation diskette that you can use to install your new Red Hat
Linux system!</Para>
</Sect1>
<Sect1 id="booting-install"><Title>Booting Linux Installation Program</Title>
<Para>To begin setting up your new Red Hat system, either boot from the
installation CD, or insert the installation diskette in the system's A:
drive, and reboot or power-on the system. After a few moments, the Red
Hat installation program screen should appear.</Para>
<Para>In most cases, you can just press <Literal>&lt;Enter&gt;</Literal>
to begin the installation process, but if you are a more experienced user
who knows exactly how your hardware devices should be set up, you can
enter ``<Literal>expert</Literal>'' for the additional information and
prompts this feature provides. (If you do nothing, the default
installation procedure will start in about 10 to 15 seconds after the
installation screen first appears.)</Para>
<Para>You will then be asked to choose your language (usually
<Quote><Literal>English</Literal></Quote>) and your keyboard type (even
in Canada I choose <Quote><Literal>US 101-key</Literal></Quote>), as well
as where you are installing from (such as from your CD-ROM or over the
network). Red Hat is very flexible in where it can be installed
from.</Para>
<Para>Most likely you will choose ``<Literal>Local CDROM</Literal>'' to
install from your Red Hat CD-ROM (which should be inserted into your
CD-ROM device). However, if your system is not equipped with a CD-ROM
device, there are a number of other installation methods you can
choose.</Para>
<Para>If you have another Linux system (or any other operating system that
supports NFS file mounting), you can use ``NFS'' to install from an NFS
mount. To do this, you'll need to have your CD-ROM mounted in the other
system (or otherwise have the Red Hat distribution tree somewhere on the
other system -- it is possible to download everything via FTP and then
install from your other system's hard drive), make sure you have an entry
in your /etc/exports file allowing access by the new system to the
appropriate directory (see <XRef LinkEnd="nfs-services"> for details
on how to set up and use NFS), and then enter the appropriate details.
Here's an example walk-through:</Para>
<BlockQuote>
<ItemizedList Mark="Bullet" Spacing="Normal">
<ListItem><Para>Insert the Red Hat CD into the other system (eg. a system
called ``spock'').</Para></ListItem>
<ListItem><Para>To mount the CD, type:</Para>
<Screen>
<UserInput>mount /dev/cdrom /mnt/cdrom -t iso9660</UserInput>
</Screen>
</ListItem>
<ListItem><Para>Edit, as the superuser, your
``<Literal><Filename>/etc/exports</Filename></Literal>'' file and put an
entry like:</Para>
<Screen>
<UserInput>/mnt/cdrom newsys.mydomain.name(ro)</UserInput>
</Screen>
<Para>(This says that the new system at newsys.mydomain.name is allowed
read-only access to the directory
``<Literal><Filename>/mnt/cdrom/</Filename></Literal>'' and any
subdirectories under it).</Para>
<Para>If your new system does not yet have a domain name assigned to it,
you can instead use its IP address:</Para>
<Screen>
<UserInput>/mnt/cdrom 10.23.14.8(ro)</UserInput>
</Screen>
<Para>(Assuming your new system has 10.23.14.8 as its IP
address).</Para></ListItem>
<ListItem><Para>Again, as superuser, type:</Para>
<Screen>
<UserInput>killall -HUP rpc.nfsd ; killall -HUP rpc.mountd</UserInput>
</Screen>
<Para>This will restart your NFS and mountd daemons, which is necessary
before your new NFS export will work.</Para></ListItem>
<ListItem><Para>Now, from your new system, you can choose
``<Literal>NFS</Literal>'' as your installation source. You'll be asked
to provide information on your network card, as well as your IP settings.
You'll likely use static IP settings if your system is sitting on a local
LAN, or DHCP settings if, for example, your system is connected to a
cable modem. Enter the settings as appropriate for your new
system.</Para></ListItem>
<ListItem><Para>You'll then be asked to enter the NFS server name and Red
Hat directory. For our example system, we would type in
``<Literal>spock</Literal>'' as the NFS server name, and
``<Literal><Filename>/mnt/cdrom/</Filename></Literal>'' as the Red Hat
directory.</Para></ListItem>
</ItemizedList>
</BlockQuote>
<Para>There are other ways of installing Red Hat, such as using a Samba
(Windows-style networking) connection, from an existing partition (such
as your DOS or Windows 95 partition) on your hard drive, or via FTP.
Check the Red Hat users guide for more details on installing using these
methods, or just try to struggle through them (the procedures are really
not very difficult!)</Para>
<Para>Once you have chosen your installation source, Red Hat will ask you
if you wish to <Quote><Literal>Install</Literal></Quote> or
<Quote><Literal>Upgrade</Literal></Quote> your system. As you are
installing a new system, you should choose
<Quote><Literal>Install</Literal></Quote>. (As an aside, I'm a fairly
anal person who <Emphasis>never</Emphasis> upgrades new distribution
releases over existing systems -- I guess having suffered through so many
problems with Microsoft products I have developed a significant mistrust
for upgrading systems as a whole. I prefer to install from scratch, and
simply restore from backup my personal/user and local site files.)</Para>
<Para>The installation program will then ask you if you have a SCSI
adapter. If you answer yes, you'll be asked to choose the appropriate
driver. In some circumstances, Red Hat will be able to detect your
adapter automatically.</Para>
<Para>Next, you'll be asked to set up your file systems (ie. partition
one or more drives for Linux). There are two tools available for setting
up these partitions, including the Red Hat-supplied <Quote><Literal>Disk
Druid</Literal></Quote>, and the standard Linux
<Quote><Literal>/fdisk</Literal></Quote> utility.</Para>
<Para>Both tools are similar in function, allowing you to specify the
partition types and sizes. However, Disk Druid seems to be a bit more
<Quote>user friendly</Quote>, and a bit more complete than fdisk. In
fact, if you use fdisk to partition your drives, you'll then be presented
with the Disk Druid screen for specifying your mount points
<Emphasis>anyway</Emphasis>. That being said, as an ex-Slackware user, I
personally always use fdisk -- force of habit, I guess! :-)</Para>
<Para>The next section will detail how and why you should set up your partition
information.</Para>
</Sect1>
<Sect1 id="install-partitioning"><Title>Partitioning Hard Drive(s)</Title>
<Para>Why partition, anyway? Well, although it is possible to get a
perfectly functioning Linux system running on a single-partition system,
and, in fact, is a bit easier to configure this way, there are a number of
benefits from partitioning one or more of your storage devices into
multiple partitions.</Para>
<Para>While it is true that Linux will operate just fine on a disk with
only one large partition defined, there are several advantages to
partitioning your disk for at least the four main file systems (root,
usr, home, and swap). These include:</Para>
<Para>First, it may reduce the time required to perform file system checks
(both upon bootup and when doing a manual fsck), because these checks can
be done in parallel. (By the way, <Emphasis>NEVER</Emphasis> run an fsck
on a mounted file system!!! You will almost certainly regret what happens
to it. The exception to this is if the file system is mounted read-only,
in which case it is safe to do so.) Also, file system checks are a lot
easier to do on a system with multiple partitions. For example, if I knew
my /home partition had problems, I could simply unmount it, perform a file
system check, and then remount the repaired file system (as opposed to
booting my system with a rescue diskette into single-user mode and doing
the repairs).</Para>
<Para>Second, with multiple partitions, you can, if you wish, mount one or
more of your partitions as read-only. For example, if you decide that
everything in /usr will not be touched even by root, you can mount the
/usr partition as read-only.</Para>
<Para>Finally, the most important benefit that partitioning provides is
protection of your file systems. If something should happen to a file
system (either through user error or system failure), on a partitioned
system you would probably only lose files on a single file system. On a
non-partitioned system, you would probably lose them on all file
systems.</Para>
<Para>This little fact can be a big plus. For example, if your root
partition is so corrupted you can't boot, you can basically boot from the
rescue diskette set, mount your root partition, and copy what you can (or
restore from backup; see <XRef LinkEnd="backup-and-restore"> for
details on how files can be backed up and restored), to another partition
such as home, and then reboot once again using the emergency boot disk,
typing <Quote><Literal>mount root=/dev/hda3</Literal></Quote> (assuming the
partition containing your temporary root file system is on the third
partition of hda) and boot your fully functional Linux box. Then you can
run an fsck on your unmounted corrupt root partition.</Para>
<Para>I <Emphasis>have</Emphasis> had personal experience in file system
catastrophies, and I was very grateful for having had the damage limited
due to the use of multiple partitions.</Para>
<Para>Finally, since Linux allows you to set up other operating system(s)
(such as Windows 95/98/NT, BeOS, or what-have-you), and then dual- (or
triple-, ...) boot your system, you might wish to set up additional
partitions to take advantage of this. Typically, you would want to set up
at least one separate partition for each operating system. Linux includes
a decent boot loader (called LILO on Intel-based systems, although much
the same thing is available as MILO on Alpha, and SILO on Sparc) which
allows you to specify which operating system you want to boot at power on,
with a time-out default boot of your favorite operating system (probably
Linux, right?)</Para>
<Para>You should partition a disk (or disks) according to your needs. In
my experience on Intel, Alpha, and Sparc platforms, for a fairly loaded
system (feature-wise), doing a fair amount of tasks (as a desktop system
at home, or as an Internet server at work), I have found the following
approximation of space works pretty effectively for determining a
partition size.</Para>
<Screen>
Given:
A given disk of X Mb/Gb (eg. 2 Gb)
(Or, more than one disk with a combined total of X Mb/Gb)
Calculate:
(swap) about double main RAM (eg. 64 Mb system gets 128 Mb swap)
/ (root) about 10% of available (eg. 200 Mb)
/home about 20% of available (eg. 400 Mb)
/usr any remaining space (eg. 1272 Mb)
/var (optional -- see below)
/boot (optional -- see below)
/archive (optional -- see below)
</Screen>
<Para>Of course, the above amounts are approximate guidelines only.
Obviously you are going to want to juggle those percentages around a bit
depending on what you are going to use your Linux system for. If you are
going to be doing stuff like adding lots of bulky applications such as
WordPerfect or Netscape, or perhaps adding Japanese character support, you
would probably benefit from a bit more /usr space.</Para>
<Para>I <Emphasis>always</Emphasis> seem to have a lot of space available
on /home, so if your users aren't doing much (or you have imposed strict
quota sizes), or you aren't offering shell accounts and personal web
pages, etc., you probably could lower /home space and raise /usr.</Para>
<Para>Here is a description of the various mount points and file system
information, which may give you a better idea of how to best define your
partition sizes for your own needs:</Para>
<ItemizedList Mark="Bullet" Spacing="Normal">
<ListItem><Para><Emphasis>/ (root)</Emphasis> - used to store things like
temporary files, the Linux kernel and boot image, important binary files
(things that are needed before Linux can mount the /usr partition), and
more importantly log files, spool areas for print jobs and outgoing
e-mail, and user's incoming e-mail. It is also used for temporary space
when performing certain operations, such as building RPM packages from
source RPM files. Therefore, if you have a lot of users with a lot of
e-mail, or think you will need plenty of temporary space, you might want
more space available. The partition type should be left as the default of
83 (Linux native). In addition, you'll probably toggle the bootable flag
on this partition to allow boot information to be stored
here.</Para></ListItem>
<ListItem><Para><Emphasis>/usr/</Emphasis> - should be the largest
partition, because most of the binary files required by Linux, as well as
any locally installed software, web pages, Squid proxy cache, Samba share
services, some locally-installed software log files, etc. are stored here.
The partition type should be left as the default of 83 (Linux
native).</Para></ListItem>
<ListItem><Para><Emphasis>/home/</Emphasis> - typically if you aren't
providing shell accounts to your users, you don't need to make this
partition very big. The exception is if you are providing user home pages
(such as school web pages), in which case you might benefit from making
this partition larger. Again, the partition type should be left as the
default of 83 (Linux native).</Para></ListItem>
<ListItem><Para><Emphasis>(swap)</Emphasis> - Linux provides something
called <Quote>virtual memory</Quote> to make a larger amount of memory
available than the physical RAM installed in your system. The swap
partition is used with main RAM by Linux to accomplish this. As a rule of
thumb, your swap partition should be at least double the amount of
physical RAM installed in your system.</Para>
<Para>If you have more than one physical hard drive in your system, you
can create multiple swap partitions. This can improve the performance of
swapping by taking advantage of parallel disk access. For example, on a
256 Mb system with four drives, I would probably create four 128 Mb swap
partitions, for a total of 256 Mb RAM, 512 Mb swap (for a combined total
of 768 Mb available as virtual memory). The partition type needs to be
changed to 82 (Linux swap).</Para>
<Note><Para>Note: It is a common misconception that Linux has a 128 Mb
swap size limit. This was true in the past, but in modern Linux
distributions, the size depends on your architecture (for example, Intel
systems can have swap sizes as large as 2 Gb). Type ``<Literal>man
mkswap</Literal>'' for more information.</Para></Note>
</ListItem>
<ListItem><Para><Emphasis>/var/</Emphasis> (optional) - You may wish to
consider splitting up your / (root) partition a bit further. The /var
directory is used for a great deal of runtime storage, including mail
spools (both ingoing and outgoing), print jobs, process locks, etc.
Having this directory mounted under / (root) may be a bit dangerous
because a large amount of incoming e-mail (for example), may suddenly fill
up the partition. Since bad things can happen (eg. system crash?) when
the / (root) partition fills up, having /var on its own partition may
avoid such problems. I've had success in taking whatever space I've
allocated to / (root), perhaps doubling it, and then creating separate
partitions for / (root) and for /var. The partition type should be left
as the default of 83 (Linux native).</Para></ListItem>
<ListItem><Para><Emphasis>/boot/</Emphasis> (optional) - In some
circumstances (such as a system set up in a software RAID configuration)
it may be necessary to have a separate partition from which to boot the
Linux system. This partition would allow booting and then loading of
whatever drivers are required to read the other file systems. The size of
this partition can be as small as a couple Mb; I recommend approximately
10 Mb (which should give you plenty of room to store the kernel, initial
RAMdisk image, and perhaps a backup kernel or two). The partition type
should be left as the default of 83 (Linux native).</Para></ListItem>
<ListItem><Para><Emphasis>/archive/</Emphasis> (optional) - If you have
any extra space lying around, perhaps you would benefit from a partition
for a directory called, for example, /archive. You can then use the
/archive directory to store backup material, large or infrequently
accessed files, samba file services, or whatever else you can find a use
for it. The partition type can be left as the default of 83 (Linux
native), or if you want to access it from both Linux as well as from
another operating system, you could change it to a different ID, such as 6
(DOS 16-bit >=32M).</Para></ListItem>
</ItemizedList>
<Para>As extra drive(s) are added, further partitions can be added to the
new drives, mounted at various mount-points as required -- this means a
Linux system never needs to worry about running out of space. As an
example, if in the future it is clear that sda6 is starting to get filled
up, we could add another drive, set a nicely sized partition with a
mount-point at /usr/local -- and then transfer all the information from
/usr/local over to the new drive. But no system or application component
would <Quote>break</Quote> because Linux would see /usr/local no matter
where it was located.</Para>
<Para>To give you an example of how one might set up partitions, I have used
the following partitioning scheme on an Intel system (dual boot, Windows 95
and Linux):</Para>
<Screen>
Device Boot Begin Start End Blocks Id System
/dev/hda1 * 1 1 254 1024096+ 6 DOS 16-bit >=32M
/dev/hda2 255 255 782 2128896 5 Extended
/dev/hda5 255 255 331 310432+ 83 Linux native
/dev/hda6 332 332 636 1229728+ 83 Linux native
/dev/hda7 637 637 749 455584+ 83 Linux native
/dev/hda8 750 750 782 133024+ 82 Linux swap
</Screen>
<Para>The first partition, <Emphasis>/dev/hda1</Emphasis>, is a
DOS-formatted file system used to store the alternative operating system
(Windows 95). This gives me 1 Gb of space for that operating
system.</Para>
<Para>The second partition, <Emphasis>/dev/hda2</Emphasis>, is a physical
partition (called <Quote>extended</Quote>) that encompasses the remaining
space on the drive. It is used only to encapsulate the remaining logical
partitions (there can only be 4 physical partitions on a disk; in my case
I required more than 4 partitions, therefore I had to use a logical
partitioning scheme for the others).</Para>
<Para>The third through fifth partitions, <Emphasis>/dev/hda5</Emphasis>,
<Emphasis>/dev/hda6</Emphasis>, and <Emphasis>/dev/hda7</Emphasis>, are
all e2fs-formatted file systems used for the / (root), /usr, and the /home
partitions, respectively.</Para>
<Para>Finally, the sixth partition, <Emphasis>/dev/hda8</Emphasis>, is
used for the swap partition.</Para>
<Para>For yet another example, this time an Alpha box with two hard drives
(sole boot, Linux only), I have chosen the following partitioning
scheme:</Para>
<Screen>
Device Boot Begin Start End Blocks Id System
/dev/sda1 1 1 1 2046 4 DOS 16-bit <32M
/dev/sda2 2 2 168 346859 83 Linux native
/dev/sda3 169 169 231 130851 82 Linux swap
/dev/sda4 232 232 1009 1615906 5 Extended
/dev/sda5 232 232 398 346828 83 Linux native
/dev/sda6 399 399 1009 1269016 83 Linux native
/dev/sdb1 1 1 509 2114355 83 Linux native
/dev/sdb2 510 510 1019 2118540 83 Linux native
</Screen>
<Para>The first partition, <Emphasis>/dev/sda1</Emphasis>, is a
DOS-formatted file system used to store the MILO boot loader. The Alpha
platform has a slightly different method of booting than an Intel system
does, therefore Linux stores its boot information in a FAT partition.
This partition only needs to be as large as the smallest possible
partition allowed -- in this case, 2Mb.</Para>
<Para>The second partition, <Emphasis>/dev/sda2</Emphasis>, is an
e2fs-formatted file system used for the / (root) partition.</Para>
<Para>The third partition, <Emphasis>/dev/sda3</Emphasis>, is used for the
swap partition.</Para>
<Para>The fourth partition, <Emphasis>/dev/sda4</Emphasis>, is an
<Quote>extended</Quote> partition (see previous example for
details).</Para>
<Para>The fifth and sixth partitions, <Emphasis>/dev/sda5</Emphasis>, and
<Emphasis>/dev/sda6</Emphasis>, are e2fs-formatted file systems used for
the /home and /usr partitions, respectively.</Para>
<Para>The seventh partition, <Emphasis>/dev/sdb1</Emphasis>, is an
e2fs-formatted file system used for the /archive partition.</Para>
<Para>The eighth and final partition, <Emphasis>/dev/sdb2</Emphasis>, is
an e2fs-formatted file system used for the /archive2 partition.</Para>
<Para>After you finish setting up your partition information, you'll need
to write the new partition to disk. After this, the Red Hat installation
program reloads the partition table into memory, so you can continue on to
the next step of the installation process.</Para>
</Sect1>
<Sect1 id="install-swap"><Title>Setting up Swap Space</Title>
<Para>Once you've set up your partition information, and have assigned
<Quote>mount points</Quote> (ie. /usr is the mount point for the /usr
file system), the installation program will ask you which partition(s) it
should used for swap space. Since your swap partitions should already be
identified as such (partition ID # 82), you can press
<Literal>&lt;Enter&gt;</Literal> to begin formatting those partition(s)
for swap usage. I recommend you enable the <Quote><Literal>Check for bad
blocks during format</Literal></Quote> to ensure the partition is free of
potentially damaging problems. It does slow down the formatting process
substantially but I believe it is worth the tradeoff.</Para>
</Sect1>
<Sect1 id="install-format"><Title>Choosing Partitions to Format</Title>
<Para>Now, the installation program will display a list of the partitions
you have assigned to Linux, and ask you to select which, if any, of these
partitions you want to format as new file systems. Likely, you will want
to format all of them, except if you are upgrading your system or perhaps
have some information (eg. on /home) that you don't want to lose.</Para>
<Para>Again, I recommend you enable the <Quote><Literal>Check for bad
blocks during format</Literal></Quote> option.</Para>
</Sect1>
<Sect1 id="install-packages"><Title>Choosing Desired Packages to Install</Title>
<Para>Next, you'll be presented with a list of system components and asked
to specify which ones should be installed. If you are an experienced
Linux user, you can pick and choose according to your needs. If you are
new to Linux, you'll likely want to select the bottom option,
<Quote>Everything</Quote>.</Para>
<Para>What I usually do is select the components I know I'll need, and
then enable the <Quote><Literal>Select individual
packages</Literal></Quote> option, which allows me to control the
installation in finer detail.</Para>
<Para>Once you have chosen your desired components, select
<Quote><Literal>Ok</Literal></Quote> to begin installation. If you have
enabled the <Quote><Literal>Select individual packages</Literal></Quote>,
you'll be asked the specify which individual packages should be
installed. This is fairly straightforward, and if you are unsure of what
a given package is for, you can press the
<Literal>&lt;<KeyCap>F1</KeyCap>&gt;</Literal> key for a brief
description of what it does.</Para>
<Para>Don't worry if you make a mistake choosing (or not choosing) a
package or two. After all, all the packages are on your CD-ROM (or other
source media), so you can use the handy Red Hat RPM tool to make
adjustments after your system is up and running (see <XRef
LinkEnd="using-rpm"> for details).</Para>
<Para>After you have chosen the packages you wish to install, the
installation program will now format the partitions you have defined.
This may take several minutes, especially for larger partitions or if
you've enabled bad block checking, so please don't think your system has
frozen during this procedure!</Para>
<Para>After the format completes, Red Hat Linux will begin installation of
the selected packages. This should take between five and fifteen minutes
to complete, depending on the speed of your system.</Para>
</Sect1>
<Sect1 id="install-configuration"><Title>Hardware Configuration</Title>
<Para>After package installation, Red Hat will begin configuring the
devices on your system. In most cases, except with very new hardware that
may not be fully supported by Linux, the installation program does a good
job of automatic configuration.</Para>
<Para>The prompts you will see are very straightforward:</Para>
<ItemizedList Mark="Bullet" Spacing="Compact">
<ListItem><Para>Detection of your mouse (including choosing between 2- and
3-button models. If you have a 2-button mouse you'll likely want to
enable 3-button emulation.)</Para></ListItem>
<ListItem><Para>Detection of your video card</Para></ListItem>
<ListItem><Para>Choosing your monitor</Para></ListItem>
<ListItem><Para>Running of ``<Literal>XConfigurator</Literal>'' to
configure the X Window System (you'll want to <Quote>Probe</Quote> your
card. If you get an error here, don't worry as you can take care of X
configuration later, after your system is up and running; see <XRef
LinkEnd="xwindows-configuration"> for details.)</Para></ListItem>
<ListItem><Para>Selection of video modes (you can choose the defaults, or
you can fine- tune the video modes you'll want to use under the X Window
System)</Para></ListItem>
<ListItem><Para>LAN configuration</Para></ListItem>
<ListItem><Para>Clock and timezone configuration</Para></ListItem>
<ListItem><Para>Startup services (the default selection is probably best,
but again, you can press <Literal>&lt;<KeyCap>F1</KeyCap>&gt;</Literal>
for a description of what a given service does)</Para></ListItem>
<ListItem><Para>Printer configuration</Para></ListItem>
<ListItem><Para>Assignment of root password (choose something
secure!)</Para></ListItem>
<ListItem><Para>Creation of a boot disk [ don't be lazy! Make one!
:-) ]</Para></ListItem>
</ItemizedList>
</Sect1>
<Sect1 id="install-lilo"><Title>Booting with LILO</Title>
<Para>Next, the installation program needs to write a boot loader to your
hard drive. The boot loader (<Emphasis>LILO</Emphasis> on Intel systems)
is responsible for booting Linux along with any other operating systems if
you have set up your system for multi-boot (see <XRef
LinkEnd="install-lilo-multi"> for details on this).</Para>
<Para>The <Quote><Literal>Lilo Installation</Literal></Quote> dialog box
will ask you to choose where the boot loader image should be written to.
You'll likely want to install it on the master boot record of your first
drive (usually /dev/hda for IDE, /dev/sda for SCSI).</Para>
<Para>Once you have selected the location for writing the boot loader, a
second dialog box will appear, allowing you to enter extra boot-time
configuration parameters. Usually you don't need to enter anything here,
but if you have more than 64 Mb of RAM you'll need to enter a special
parameter in order to have Linux make use of the extra RAM (otherwise, it
will only use the first 64 Mb). For example, if your system has 128 Mb of
RAM, you should enter:</Para>
<Screen>
append="mem=128M"
</Screen>
<Para>If your system has SCSI drives, or you wish to install LILO on a
partition with more than 1023 cylinders, it may be necessary to enable
the option to <Quote><Literal>Use linear mode</Literal></Quote>. If it
is not, enabling this option shouldn't hurt anything, so it is probably a
good idea to do so.</Para>
<Sect2 id="install-lilo-multi"><Title>Multi-boot with Other Operating Systems</Title>
<Para>Finally, if you've set up your system to multi-boot Linux with other
operating system(s), you'll be presented with a third dialog box which
lists the available partitions. Here, you can assign names to your other
operating systems (which you enter at the <Quote>LILO</Quote> prompt at
boot time to boot your desired operating system. The installation program
does assign default names to each bootable partition, so it isn't
necessary to change them unless you don't like the defaults.</Para>
<Para>The default operating system that will boot upon system start up will,
of course, be Linux. However, if you wish, you can change the default to
any of the other operating systems you have defined.</Para>
<Para>After installing the boot loader on your hard drive, the
installation program should hopefully present you with a
<Quote>Congratulations</Quote> dialog box, indicating that Linux has been
successfully installed. Remove the installation floppy diskette (if
any), and press <Literal>&lt;<KeyCap>Enter</KeyCap>&gt;</Literal> to
reboot your system...into Linux!</Para>
<Para>Linux will boot, and if all goes well you should see a
<Quote>login</Quote> prompt. From here, you should be able to log in as
<Quote>root</Quote> using whatever password you have assigned during the
installation process.</Para>
</Sect2>
</Sect1>
<Sect1 id="update-redhat"><Title>Downloading and Installing Red Hat Updates</Title>
<Para>Red Hat has produced some pretty impressive versions of their
distribution so far, but seems to have a history of releasing them when
they are not quite <Quote>ready for prime time</Quote>. Therefore in order
to take full advantage of your Linux system, it is necessary to download
and apply updated packages. These packages, also called <Quote>rpm
files</Quote> are applied using the RPM utility (for details on this
utility, see <XRef LinkEnd="using-rpm">).</Para>
<Para>This will prove to be one of the more time-consuming parts of
getting your Linux system ready (unless you have a stellarly fast Internet
connection). However, take the time to do this! You will likely save
yourself a <Emphasis>lot</Emphasis> of grief!</Para>
<Para>First, download all files from:</Para>
<BlockQuote>
<Para><ULink URL="ftp://ftp.redhat.com/redhat/updates/6.1/i386/">
ftp://ftp.redhat.com/redhat/updates/6.1/i386/</ULink></Para>
</BlockQuote>
<Para>(The above assumes you are using Linux on an Intel box).</Para>
<Para>You should probably download everything into a single directory,
and then you can simply type: ``<Literal>rpm -Uvh *</Literal>'' which
will upgrade all the packages. If you've downloaded any kernel rpm files,
you should probably move them to another directory for now. Upgrading or
customizing your kernel is a bit more complicated and needs to be done
with great care (see <XRef LinkEnd="linux-kernel-upgrades"> for details
on this). Therefore before you apply the upgrades, you may wish to
consider moving all the kernel-*.rpm files out of your temporary upgrade
directory.</Para>
<Para>To apply the upgrades, you can simply run
``<Literal>rpm</Literal>'' against all the packages at once (ie.
<Quote><Literal>rpm -Uvh *</Literal></Quote>), or if you prefer, you can
upgrade them one at a time (ie. <Quote><Literal>rpm -Uvh
file_to_upgrade.rpm</Literal></Quote>). The latter method is for us anal
types who wish to ensure that each update is applied correctly without
error. :-)</Para>
<Para>Perhaps you are curious to see if a given package is installed
before you attempt to upgrade it. Or perhaps you wish to find out what
version of a given package is installed. All this can be done with the
RPM utility; see <XRef LinkEnd="using-rpm"> for details.</Para>
</Sect1>
</Chapter>
<Chapter id="xwindows-configuration"><Title>Configuring the X Window System</Title>
<Para>The X Window System, aka <Quote>X</Quote> (commonly and incorrectly
known by many as <Quote>X-Windows</Quote>) is a GUI which sits on top of
Linux. Unlike Microsoft Windows, the X Window System can look and operate
in a large variety of different ways. It can operate very primitively or
very advanced, look beautiful or ugly, be sleek and fast or bloated and
slow (each of which are subjective qualities which cause as many arguments
among users as the <Quote>Linux vs. Microsoft NT</Quote> debate seems
to).</Para>
<Para>Getting X working properly can range from simple to hair-pulling
complicated! It is a common complaint among users who are new to Linux,
and I've fought with configuration settings countless times myself, so I'm
completely empathic about this. Fortunately, such configuration is becoming
easier and more automated in the newer distributions of Linux. In fact,
if you are using Red Hat 6.1 you will probably not have to worry about this
issue.</Para>
<Para>Although in a majority of cases X can be configured automatically,
there are exceptions; I would recommend you know or find out the type of
video card and amount of video RAM your system has installed, as well as
the type of monitor and its horizontal and vertical synch rates (this
information is usually available in the back pages of the monitor's users
guide, or can be found on the WWW).</Para>
<Sect1 id="xwindows-xconfigurator"><Title>Getting the X Window System Working with X-Configurator</Title>
<Para>There are two main methods of getting X working under Red Hat's
distribution of Linux. The first and easiest method, is to use Red Hat's
own ``<Literal>Xconfigurator</Literal>'' utility. The utility tries to
detect your hardware and installs the applicable X software with the
appropriate configuration settings.</Para>
<Para>If you are still unsuccessful after trying out various settings
with Xconfigurator, you may have better luck with the
``<Literal>xf86config</Literal>'' utility. Although certainly not as
user-friendly or attractive as Xconfigurator is, it gives you finer
control over the configuration process.</Para>
<Para>Finally, if you are <Emphasis>still</Emphasis> out of luck you may
have to resort to editing the
``<Literal><Filename>/etc/X11/XF86Config</Filename></Literal>'' file by
hand and tweaking various settings. If this is the case, you may need to
get help from the Linux community (see <XRef LinkEnd="where-to-turn"> for
details). Relax, however -- in a majority of cases Xconfigurator does an
adequate job!</Para>
<Para>After getting X working properly, you may be disappointed in the
lack of rich colours. This is because X uses a default 8-bit per pixel
(``<Emphasis>bpp</Emphasis>'') colour depth. You can use higher colour
depths, however, assuming your video hardware will support them.</Para>
<Para>The various colour depths are listed in your
``<Literal><Filename>/etc/X11/XF86Config</Filename></Literal>'' file, and
look like this:</Para>
<ProgramListing>
Subsection "Display"
Depth 24
Modes "800x600" "1024x768"
ViewPort 0 0
Virtual 1024 768
EndSubsection
</ProgramListing>
<Para>The above section shows the possible resolutions which are
available when using the 24-bit colour depth (800x600 and 1024x768, as
listed in the <Quote>Modes</Quote> line); these resolutions can be
switched between <Quote>on-the-fly</Quote> using the
<Literal>&lt;<KeyCap>Alt</KeyCap>&gt;&lt;<KeyCap>+</KeyCap>&gt;</Literal>
and <Literal>&lt;<KeyCap>Alt</KeyCap>&gt;&lt;<KeyCap>-</KeyCap>&gt;</Literal>
keys.</Para>
<Tip><Para>Tip: As a default, when X starts up it does so using the lowest
resolution. If you dislike this behaviour as much as I do, simply edit
the ``<Literal><Filename>/etc/X11/XF86Config</Filename></Literal>'' file
and reverse the resolutions (ie. <Quote>1024x768</Quote>
<Quote>800x600</Quote>).</Para></Tip>
<Para>When you are getting things set up, you can test each colour depth
manually by typing, ``<Literal>startx -- -bpp 24</Literal>'' (for the
24-bit depth) and make sure X is working properly for the colour depth
you wish to use.)</Para>
<Para>If you are able to successfully use a higher colour depth and wish
to use it as the default, you will need to create a
``<Literal><Filename>/etc/X11/xinit/xserverrc</Filename></Literal>'' file
as follows:</Para>
<ProgramListing>
exec X :0 -bpp 24
</ProgramListing>
<Para>The above change will allow X to use 24 bits per pixel (if you have
problems with this, try 16 or 32 instead of 24).</Para>
<Para>Assuming you have configured X properly, starting it is a simple
matter of typing ``<Literal>startx</Literal>'' as any user. The X GUI
will start, and after you have finished your session and quit X, you will
be returned to the regular Linux console.</Para>
<Para>Optionally, X can start up at system boot, and
<Emphasis>always</Emphasis> run (see <XRef LinkEnd="xwindows-xdm"> for
details on how to accomplish this). This can be handy for those users who
dislike seeing the <Quote>boring</Quote> black &amp; white console, or for
those who wish to avoid dealing with command line shells as much as
possible.</Para>
</Sect1>
<Sect1 id="xwindows-xdm"><Title>Using the X Desktop Manager</Title>
<Para>If you wish, you may use the X Desktop Manager
(``<Literal>xdm</Literal>'') to start up the X Window System automatically
at system boot time. This allows your Linux system to always run under X
(although you can switch from the GUI to the regular consoles with
<Literal>&lt;<KeyCap>Ctrl</KeyCap>&gt;-&lt;<KeyCap>Alt</KeyCap>&gt;-&lt;<KeyCap>F1</KeyCap>&gt;</Literal>,
and then back again to the GUI with
<Literal>&lt;<KeyCap>Alt</KeyCap>&gt;-&lt;<KeyCap>F7</KeyCap>&gt;</Literal>
as needed). This is a nice way of providing an attractive and friendly
environment for you and your users, and avoid having to type
``<Literal>startx</Literal>'' all the time.</Para>
<Para>To enable xdm, simply edit the
``<Literal><Filename>/etc/inittab</Filename></Literal>'' file and change
the line that reads <Quote><Literal>id:3:initdefault:</Literal></Quote>
to the following:</Para>
<ProgramListing>
id:5:initdefault:
</ProgramListing>
<Para>The above change will switch Linux to run level 5 upon system boot
up; this run level, by default, will start xdm. You may also wish to
check your ``<Literal><Filename>/etc/inittab</Filename></Literal>'' file,
probably near the bottom, to ensure the following line is present:</Para>
<ProgramListing>
x:5:respawn:/usr/bin/X11/xdm -nodaemon
</ProgramListing>
<Para>If you have enabled xdm and wish to use a higher ``bpp'' value than
the default of 8 (and your video card and monitor will support it), you
will need to modify the
``<Literal><Filename>/etc/X11/xdm/Xservers</Filename></Literal>'' file as
follows:</Para>
<ProgramListing>
:0 local /usr/X11R6/bin/X -bpp 24
</ProgramListing>
<Para>The above change will start the xdm at 24 bits per pixel.</Para>
<Para>You may also wish to edit the
``<Literal><Filename>/etc/X11/xdm/Xsetup_0</Filename></Literal>'' file
and with a ``<Literal>#</Literal>'' character, comment out the line that
starts ``<Literal>xbanner</Literal>'' as shown:</Para>
<ProgramListing>
#/usr/X11R6/bin/xbanner
</ProgramListing>
<Para>This will prevent the default xdm banner screen from displaying for a
split second between KDE sessions. Aesthestics, I know, but...</Para>
<Tip><Para>Tip: Sometimes you may find it necessary to switch back to the
console (for example, certain games run under the console but not under
X). There are two ways of doing this. To temporarily switch away from X
to the console, press
<Literal>&lt;<KeyCap>Alt</KeyCap>&gt;&lt;<KeyCap>F1</KeyCap>&gt;</Literal>,
and to switch back to X again, press
<Literal>&lt;<KeyCap>Alt</KeyCap>&gt;&lt;<KeyCap>F7</KeyCap>&gt;</Literal>.
Or, if you wish to terminate X altogether (thus freeing up your available
memory), you can type ``<Literal>/sbin/telinit 3</Literal>'' as
<Quote>root</Quote> to switch the system run-level; this tells XDM to
terminate. To switch back, type ``<Literal>/sbin/telinit
5</Literal>''.</Para></Tip>
</Sect1>
<Sect1 id="xwindows-fonts"><Title>Improving Font Appearance Under X</Title>
<Para>Quite frankly, X has never been known for having particularly
attractive fonts. In fact, many people resign themselves to the notion
that having ugly, nasty fonts is an unfortunate fact of life under X.</Para>
<Para>Fortunately, it <Emphasis>is</Emphasis> possible to dramatically
improve the look of, and increase the number of fonts you can use, under
X. In fact, if you own a copy of Windows, you can even copy over the
TrueType fonts from that platform and use them under X as well! Such font
support is accomplished by using a font server such as ``xfstt'' or
``xfs''.</Para>
<Para>Red Hat 6.1 now includes support for ``xfs'' built in, and as a
result provides attractive font support right out of the box. Therefore,
if you're using this version of Linux, you may be satisfied with the way
things are. However, there are a couple of things you can do to improve
things still further, as well as make use of your TrueType fonts if you
have them available.</Para>
<Para>To enable TrueType font support, create a directory (eg.
``<Literal><Filename>/usr/local/share/ttfonts</Filename></Literal>'') and
copy any or all of the font files from your Windows system (where they can be
found in the ``<Literal><Filename>c:\windows\fonts</Filename></Literal>''
directory) into the new directory.</Para>
<Tip><Para>Tip: If you do not have any TrueType fonts available to you,
you can download them directly from Microsoft at <ULink
URL="http://www.microsoft.com/typography/fontpack/default.htm">
http://www.microsoft.com/typography/fontpack/default.htm</ULink>.
</Para></Tip>
<Para>To make use of the fonts, from within your new ``ttfonts'' directory,
type the following (as root):</Para>
<Screen>
ttmkfdir -o fonts.scale
mkfontdir
</Screen>
<Para>Next, edit the
``<Literal><Filename>/etc/X11/fs/config</Filename></Literal>'' file, add
add your new font directory to the list of existing directories. Also,
change the <Literal>default-point-size</Literal> from 120 to 140, which
will give you larger, more readable fonts.</Para>
<Para>Finally, exit X (if you haven't done so already), and restart your
xfs server as follows:</Para>
<Screen>
/etc/rc.d/init.d/xfs restart
</Screen>
<Para>Finally, restart X and enjoy your glorious new fonts!</Para>
<Para>For more detailed information on improving font support under X, there
is a very excellent resource called the
``<Emphasis>XFree86 Font Deuglification Mini HOW-TO</Emphasis>'' at
<ULink URL="http://www.frii.com/~meldroc/Font-Deuglification.html">
http://www.frii.com/~meldroc/Font-Deuglification.html</ULink>.</Para>
</Sect1>
<Sect1 id="xwindows-winmgr"><Title>Choosing a Window Manager for X</Title>
<Para>Now, you should decide on a window manager. The X Window System is simply
the environment which allows graphics to be displayed on your system's
hardware; the window manager is responsible for how X looks and how it
interacts with you and your applications.</Para>
<Para>The Red Hat distribution of Linux contains several window managers,
including fvwm, olvm, twm, AfterStep, and others. The default one
that you will probably see when starting up X for the first time is
fvwm95, a Win95-like environment.</Para>
<Para>Personally, I find the usual offerings differ from my own tastes, and
I recommend using either GNOME or KDE (or both!), whose installation
are covered in the next two sections.</Para>
</Sect1>
<Sect1 id="using-gnome"><Title>GNOME Installation and Configuration</Title>
<Para>The GNU Network Object Model Environment (GNOME) is a windowing
environment that enhances your X window environment. It is full-featured,
including a large selection of applications you may find useful.
However, at the time of this writing, GNOME still has a few minor bugs,
meaning you may have to put up with errant behaviour at times. However, it
is fairly stable and definitely usable!</Para>
<Para>If you're using Red Hat 6.1, the latest version of GNOME (at least,
the latest at the time of this writing!) is included with the
distribution. Otherwise, you will need to download the latest RPM
distribution of the package. At the time of this writing, the RPM files
for Red Hat 6.0 i386 systems can be found at <ULink
URL="ftp://ftp.gnome.org/pub/GNOME/RHAD/redhat-6.0/i386/">
ftp://ftp.gnome.org/pub/GNOME/RHAD/redhat-6.0/i386/</ULink> (or from a
mirror site).</Para>
<Note><Para>Note: If you're using Red Hat 6.0, you should be aware that it
was shipped with a fairly buggy version of GNOME. You should download the
latest RPM's from the FTP site as described above.</Para></Note>
<Para>After you have all the necessary files, the GNOME package can be
installed with a simple command, typed as <Quote>root</Quote>:</Para>
<Screen>
rpm -Uvh gtk*.rpm *.rpm
</Screen>
<Para>(The above command ensures the GTK libraries are installed first, to
avoid dependency errors from occurring).</Para>
<Para>Contrary to popular belief, GNOME is actually
<Emphasis>not</Emphasis> a Window manager, but instead sits on top of your
favorite one, providing added functionality to it. Therefore, once you
have installed GNOME, you should decide which window manager you wish to
use, and create a ``<Literal><Filename>.xinitrc</Filename></Literal>''
file in your directory which loads the appropriate window manager and
starts GNOME. The file should look something like this:</Para>
<ProgramListing>
afterstep &
exec gnome-session
</ProgramListing>
<Para>The above file will load AfterStep for the window manager, and then
run GNOME on top of it.</Para>
<Para>More information on the GNU Network Object Model Environment can be
found on the GNOME web page at <ULink URL="http://www.gnome.org/">
http://www.gnome.org/</ULink>. Don't forget to check out the screen shots,
located at <ULink URL="http://www.gnome.org/screenshots/">
http://www.gnome.org/screenshots/</ULink>.</Para>
</Sect1>
<Sect1 id="using-kde"><Title>KDE Installation and Configuration</Title>
<Para>The K Desktop Package (KDE) is another popular window manager that is
somewhat more mature than GNOME is at the time of this writing. However,
it seems to require a bit more memory resources than GNOME does, so take
into consideration the amount of RAM you have available on your system (if
you have anything less than 64 Mb of RAM and 128 Mb of swap, you might be
better off using GNOME).</Para>
<Para>The first step for installing KDE is to download the latest RPM
distribution of the package. To do so, locate an FTP mirror at <ULink
URL="http://www.kde.org/mirrors.html">
http://www.kde.org/mirrors.html</ULink>. Try to choose a mirror that is
close to your geographic location, but make sure whichever one you choose
is updated often (which can be determined by looking at the list of
mirrors).</Para>
<Para>When you have found a suitable mirror, download all the RPM files
which are applicable to your version of Red Hat and your platform. For
example, if you are using Red Hat 5.2 (or above) on an Intel platform, you
will likely want to download the package from the
``<Literal><Filename>/pub/mirrors/kde/stable/latest/distribution/rpm/RedHat-5.2/i386/</Filename></Literal>''
directory on the FTP mirror.</Para>
<Para>After you have all the necessary files, the KDE package can be
installed with the following simple commands, typed as <Quote>root</Quote>
(make sure you are in the directory where all your KDE rpm files
are):</Para>
<Screen>
rpm -Uvh qt*.rpm
install-kde-1.1-base
</Screen>
<Para>The above commands will install the Qt libraries first, and then
install the KDE base package. Once this is done, you should log off
and log back in (or if you are ``su''ed as root, just exit and ``su''
again) so that your path environment is set appropriately, then type:</Para>
<Screen>
install-kde-1.1-apps
</Screen>
<Para>The above command will install the applications programs.</Para>
<Para>This installation procedure is discussed in more detail in the file
``<Literal><Filename>readme-redhat-rpms.txt</Filename></Literal>'' that
should have been included with the KDE files you downloaded.</Para>
<Para>If all goes well, and KDE has been installed without any error
messages, you may, if you wish, configure KDE to be the default window
manager for any of your users (the one they will see immediately after
typing ``<Literal>startx</Literal>''), by typing the following, again as
<Quote>root</Quote>:</Para>
<Screen>
/opt/kde/bin/usekde <Emphasis>userid</Emphasis>
</Screen>
<Para>(Make sure you replace <Emphasis>userid</Emphasis> with an actual
user id!)</Para>
<Para>More information on the K Desktop Environment can be found on the
KDE web page at <ULink URL="http://www.kde.org/">http://www.kde.org/</ULink>.
Don't forget to check out the screen shots,
located at <ULink URL="http://www.kde.org/kde2shots.html">
http://www.kde.org/kde2shots.html</ULink>.</Para>
</Sect1>
</Chapter>
<Chapter id="administrative-issues"><Title>General System Administration Issues</Title>
<Sect1 id="root-account"><Title>Root Account</Title>
<Para>The <Quote>root</Quote> account is the most privileged account on a
Unix system. This account gives you the ability to carry out all facets
of system administration, including adding accounts, changing user
passwords, examining log files, installing software, etc.</Para>
<Para>When using this account it is crucial to be as careful as possible.
The <Quote>root</Quote> account has no security restrictions imposed upon
it. This means it is easy to perform administrative duties without
hassle. However, the system assumes you know what you are doing, and will
do exactly what you request -- no questions asked. Therefore it is easy,
with a mistyped command, to wipe out crucial system files.</Para>
<Para>When you are signed in as, or acting as <Quote>root</Quote>, the
shell prompt displays '#' as the last character (if you are using bash).
This is to serve as a warning to you of the absolute power of this
account.</Para>
<Para>The rule of thumb is, never sign in as <Quote>root</Quote> unless
absolutely necessary. While <Quote>root</Quote>, type commands carefully
and double-check them before pressing return. Sign off from the
<Quote>root</Quote> account as soon as you have accomplished the task you
signed on for. Finally, (as with any account but especially important
with this one), keep the password secure!</Para>
</Sect1>
<Sect1 id="creating-user-accounts"><Title>Creating User Accounts</Title>
<Warning><Para>(WARNING: SLACKWARE-CENTRIC. NEEDS UPDATE FOR RED
HAT)</Para></Warning>
<Para>This section assumes you are using the Shadow password suite on your
Linux system. If you are not, you should consider doing so, as it helps
to tighten up security somewhat. The Shadow suite is fairly easy to
install and will automatically convert your non-shadow password file
format over to the new shadow format.</Para>
<Para>There are two steps to creating a new user account. The first is to
actually create the account itself, the second is to provide an alias to
their e-mail address (at my place of employment, we follow the convention
of <Quote>Firstname.Lastname@our.domain.name</Quote>.)</Para>
<Para>To create the account, decide on the username you are going to
assign to the user. The username is at most 8 characters long, and
wherever possible you should choose their last name, or last name and
first initial if a user account already exists (the adduser script will
detect and prevent you from adding duplicate account names).</Para>
<Para>You will then be prompted to enter other information: full name of
user, user group (usually the default value), a user id # (automatically
assigned), home directory (automatically assigned), a user shell, some
password expiration values, and finally the desired password (which won't
echo to the screen; you should have the user choose a password between 6
to 8 characters in length for security reasons).</Para>
<Para>Please note that <Emphasis>everything</Emphasis> should be
entered in lowercase, except for the full name of the user which can be
entered in a <Quote>pleasing format</Quote> (eg. Joe Smith) and the
password. Case is sensitive, so inform your user(s) they must use
identical case when entering their username and password.</Para>
<Para>Here is a sample session where we will add a user named Joe
Smith:</Para>
<Screen>
<Prompt>mail:~#</Prompt> <UserInput>/sbin/adduser</UserInput>
<Prompt>User to add (^C to quit):</Prompt> <UserInput>smith</UserInput>
That name is in use, choose another.
<Prompt>User to add (^C to quit):</Prompt> <UserInput>smithj</UserInput>
Editing information for new user [smithj]
<Prompt>Full Name:</Prompt> <UserInput>Joe Smith</UserInput>
<Prompt>GID [100]:</Prompt> <UserInput> </UserInput>
Checking for an available UID after 500
First unused uid is 859
<Prompt>UID [859]:</Prompt> <UserInput> </UserInput>
<Prompt>Home Directory [/home/smithj]:</Prompt> <UserInput> </UserInput>
<Prompt>Shell [/bin/bash]:</Prompt> <UserInput> </UserInput>
<Prompt>Min. Password Change Days [0]:</Prompt> <UserInput> </UserInput>
<Prompt>Max. Password Change Days [30]:</Prompt> <UserInput>90</UserInput>
<Prompt>Password Warning Days [15]:</Prompt> <UserInput> </UserInput>
<Prompt>Days after Password Expiry for Account Locking [10]:</Prompt> <UserInput>0</UserInput>
<Prompt>Password [smithj]:</</Prompt> <UserInput>FL1539</UserInput>
<Prompt>Retype Password:</</Prompt> <UserInput>Fl1539</UserInput>
Sorry, they do not match.
<Prompt>Password:</</Prompt>> <UserInput>FL1539</UserInput>
<Prompt>Retype Password:</</Prompt> <UserInput>FL1539</UserInput>
Information for new user [smithj]:
Name: Joe Smith
Home directory: /home/smithj
Shell: /bin/bash
Password: &lt;hidden&gt;
Uid: 859 Gid: 100
Min pass: 0 maX pass: 99999
Warn pass: 7 Lock account: 0
public home Directory: no
Type 'y' if this is correct, 'q' to cancel and quit the program,
<Prompt>or the letter of the item you wish to change:</Prompt> <UserInput>Y</UserInput>
</Screen>
<Para>The next step is to create the alias for the person's e-mail
account. This gives people the choice of using their account name for
their e-mail address, or their full name (First.Last combination) to make
it <Quote>easier</Quote> for the outside world to guess their e-mail
address when trying to contact them for the first time.</Para>
<Para>To add the e-mail alias, edit the
``<Literal><Filename>/etc/aliases</Filename></Literal>'' file as
follows:</Para>
<Para><Prompt>mail#</Prompt> <UserInput>pico -w /etc/aliases</UserInput></Para>
<Para>Add the new alias at the bottom of the file. The format for an
alias is:</Para>
<Screen>
First.Lastname:username
</Screen>
<Para>You should ask the user what preference they have for this (eg.
Joseph.Smith or Joe.Smith). For our new Joe Smith user, the entry would
be as follows:</Para>
<Screen>
Joe.Smith:smith
</Screen>
<Para>When finished adding the alias, press
<Literal>&lt;<KeyCap>Ctrl</KeyCap>&gt;-&lt;<KeyCap>X</KeyCap>&gt;</Literal>
and save the file. Then, type ``<Literal>newaliases</Literal>'' to
update the aliases database.</Para>
<Para>At this point the user account has been created and is ready for
use. It is a good idea to remind the user that his username and password
must be entered in lowercase characters, and what their e-mail address
would be (eg. ``<Emphasis>Joe.Smith@mail.mydomain.name</Emphasis>'').</Para>
</Sect1>
<Sect1 id="changing-user-passwords"><Title>Changing User Passwords</Title>
<Para>To change a password on behalf of a user, first sign on or
<Quote>su</Quote> to the <Quote>root</Quote> account. Then type,
``<Literal>passwd user</Literal>'' (where user is the username for the
password you are changing). The system will prompt you to enter a
password. Passwords do not echo to the screen when you enter
them.</Para>
<Para>You can also change your own password, by typing
``<Literal>passwd</Literal>'' (without specifying a username). You will
be prompted to enter your old password for verification, and then a new
password.</Para>
</Sect1>
<Sect1 id="disabling-user-accounts"><Title>Disabling User Accounts</Title>
<Para>To disable a user account, edit, as root, the
``<Literal><Filename>/etc/shadow</Filename></Literal>'' file (assuming
you're using shadow passwords; if not, edit the
``<Literal><Filename>/etc/passwd</Filename></Literal>'' file instead),
and replace the password (which is stored in its encrypted form) with a
``*'' asterisk character. All Unix passwords, regardless of length (up
to a maximum of 8 characters), are stored in the password file as
encrypted strings of 13 characters. Therefore, by replacing the password
with a single ``*'' character, it is impossible for the user to sign
in.</Para>
<Note><Para>Note: This method will require you to assign a new password to
the user if you re-enable the account, since the encrypted password field
will have been replaced. One solution to this which seems to be popular
among system administrators is to simply prefix the ``*'' asterisk
character in front of the encrypted password to disable the account, and
simply removing the asterisk to enable it.</Para></Note>
<Para>For more information on the
``<Literal><Filename>/etc/passwd</Filename></Literal>'' and
``<Literal><Filename>/etc/shadow</Filename></Literal>'' files, see <XRef
LinkEnd="shadow-file-formats"> below.</Para>
</Sect1>
<Sect1 id="removing-user-accounts"><Title>Removing User Accounts</Title>
<Para>On occasion, you may wish to remove a user's access from your server
altogether.</Para>
<Para>If you are a Red Hat user, the easiest way to remove an unneeded
user account is with the ``<Literal>userdel</Literal>'' command, which
must be typed as ``root''. An example follows:</Para>
<Screen>
/usr/sbin/userdel baduser
</Screen>
<Para>The above command will remove the entry matching the username
``<Emphasis>baduser</Emphasis> from the
``<Literal><Filename>/etc/passwd</Filename></Literal>'', file, and, if
you're using the Shadow password format (which you should be; see <XRef
LinkEnd="shadow-file-formats"> for details), the
``<Literal><Filename>/etc/shadow</Filename></Literal>''.</Para>
<Note><Para>Note: The ``<Literal><Filename>/etc/group</Filename></Literal>'' is
<Emphasis>not</Emphasis> modified, to avoid removing a group that other
user(s) may also belong to. This isn't much of a big deal, but if this
bothers use, you can edit the group file and remove the entry
manually.</Para></Note>
<Para>Should you wish to remove the user's home directory as well, add
the ``<Literal>-r</Literal>'' option to the ``userdel'' command. For
example:</Para>
<Screen>
/usr/sbin/userdel -r baduser
</Screen>
<Para>I recommend not removing an account right away, but first simply
<Emphasis>disable</Emphasis> it, especially if you are working with a
corporate server with lots of users. After all, the former user may one
day require the use of his or her account again, or may request a file or
two which was stored in their home directory. Or perhaps a
<Emphasis>new</Emphasis> user (such as an employee replacement) may
require access to the former user's files. In any event, make sure you
have backups of the former user's home directory,
<Quote>just-in-case</Quote>. See <XRef LinkEnd="disabling-user-accounts">
for details on disabling an account, and <XRef
LinkEnd="backup-and-restore"> for details on how to perform
backups.</Para>
</Sect1>
<Sect1 id="shadow-file-formats"><Title>Linux Password &amp; Shadow File Formats</Title>
<Para>Traditional Unix systems keep user account information, including
one-way encrypted passwords, in a text file called
``<Literal><Filename>/etc/passwd</Filename></Literal>''. As this file is
used by many tools (such as ``ls'') to display file ownerships, etc. by
matching user id #'s with the user's names, the file needs to be
world-readable. Consequentally, this can be somewhat of a security
risk.</Para>
<Para>Another method of storing account information, one that I always
use, is with the shadow password format. As with the traditional method,
this method stores account information in the /etc/passwd file in a
compatible format. However, the password is stored as a single
<Quote>x</Quote> character (ie. not actually stored in this file). A
second file, called
``<Literal><Filename>/etc/shadow</Filename></Literal>'', contains
encrypted password as well as other information such as account or
password expiration values, etc. The /etc/shadow file is readable only
by the root account and is therefore less of a security risk.</Para>
<Para>While some other Linux distributions forces you to install the
Shadow Password Suite in order to use the shadow format, Red Hat makes it
simple. To switch between the two formats, type (as root):</Para>
<Screen>
/usr/sbin/pwconv To convert to the shadow format
/usr/sbin/pwunconv To convert back to the traditional format
</Screen>
<Para>With shadow passwords, the
``<Literal><Filename>/etc/passwd</Filename></Literal>'' file contains
account information, and looks like this:</Para>
<ProgramListing>
smithj:x:561:561:Joe Smith:/home/smithj:/bin/bash
</ProgramListing>
<Para>Each field in a passwd entry is separated with <Quote>:</Quote>
colon characters, and are as follows:</Para>
<ItemizedList Mark="Bullet" Spacing="Compact">
<ListItem><Para>Username, up to 8 characters. Case-sensitive, usually all
lowercase</Para></ListItem>
<ListItem><Para>An <Quote>x</Quote> in the password field. Passwords are
stored in the ``<Literal><Filename>/etc/shadow</Filename></Literal>''
file.</Para></ListItem>
<ListItem><Para>Numeric user id. This is assigned by the
``<Literal>adduser</Literal>'' script. Unix uses this field, plus the
following group field, to identify which files belong to the
user.</Para></ListItem>
<ListItem><Para>Numeric group id. Red Hat uses group id's in a fairly
unique manner for enhanced file security. Usually the group id will match
the user id.</Para></ListItem>
<ListItem><Para>Full name of user. I'm not sure what the maximum length
for this field is, but try to keep it reasonable (under 30
characters).</Para></ListItem>
<ListItem><Para>User's home directory. Usually /home/username (eg.
/home/smithj). All user's personal files, web pages, mail forwarding,
etc. will be stored here.</Para></ListItem>
<ListItem><Para>User's <Quote>shell account</Quote>. Often set to
``<Literal><Filename>/bin/bash</Filename></Literal>'' to provide access
to the bash shell (my personal favorite shell).</Para></ListItem>
</ItemizedList>
<Para>Perhaps you do not wish to provide shell accounts for your users.
You could create a script file called
``<Literal><Filename>/bin/sorrysh</Filename></Literal>'', for example,
that would display some kind of error message and log the user off, and
then set this script as their default shell.</Para>
<Note><Para>Note: If the account needs to provide <Quote>FTP</Quote> transfers
to update web pages, etc. then the shell account will need to be set to
``<Literal><Filename>/bin/bash</Filename></Literal>'' -- and then special
permissions will need to be set up in the user's home directory to prevent
shell logins. See <XRef LinkEnd="web-server-administration"> for details
on this.</Para></Note>
<Para>The ``<Literal><Filename>/etc/shadow</Filename></Literal>'' file
contains password and account expiration information for users, and looks
like this:</Para>
<ProgramListing>
smithj:Ep6mckrOLChF.:10063:0:99999:7:::
</ProgramListing>
<Para>As with the passwd file, each field in the shadow file is also
separated with <Quote>:</Quote> colon characters, and are as
follows:</Para>
<ItemizedList Mark="Bullet" Spacing="Compact">
<ListItem><Para>Username, up to 8 characters. Case-sensitive, usually all
lowercase. A direct match to the username in the /etc/passwd
file.</Para></ListItem>
<ListItem><Para>Password, 13 character encrypted. A blank entry (eg. ::)
indicates a password is not required to log in (usually a bad idea), and a
``*'' entry (eg. :*:) indicates the account has been
disabled.</Para></ListItem>
<ListItem><Para>The number of days (since January 1, 1970) since the
password was last changed.</Para></ListItem>
<ListItem><Para>The number of days before password may be changed (0
indicates it may be changed at any time)</Para></ListItem>
<ListItem><Para>The number of days after which password
<Emphasis>must</Emphasis> be changed (99999 indicates user can keep his or
her password unchanged for many, many years)</Para></ListItem>
<ListItem><Para>The number of days to warn user of an expiring password (7
for a full week)</Para></ListItem>
<ListItem><Para>The number of days after password expires that account is
disabled</Para></ListItem>
<ListItem><Para>The number of days since January 1, 1970 that an account
has been disabled</Para></ListItem>
<ListItem><Para>A reserved field for possible future use</Para></ListItem>
</ItemizedList>
</Sect1>
<Sect1 id="system-shutdown-and-restart"><Title>System Shutdown and Restart</Title>
<Para>To shut down the system from a terminal session, sign in or
<Quote>su</Quote> to the <Quote>root</Quote> account. Then type
``<Literal>/sbin/shutdown -r now</Literal>''. It may take several moments
for all processes to be terminated, and then Linux will shut down. The
computer will reboot itself. If you are in front of the console, a
faster alternative to this is to press
<Literal>&lt;<KeyCap>Ctrl</KeyCap>&gt;-&lt;<KeyCap>Alt</KeyCap>&gt;-&lt;<KeyCap>Del</KeyCap>&gt;</Literal>
to shut down. Please be patient as it may take a couple of minutes for
Linux to terminate.</Para>
<Para>You can also shut down the system to a halt (ie. it will shut down
and not reboot the system). The system will be unavailable until
power-cycled or rebooted with
<Literal>&lt;<KeyCap>Ctrl</KeyCap>&gt;-&lt;<KeyCap>Alt</KeyCap>&gt;-&lt;<KeyCap>Del</KeyCap>&gt;</Literal>.
This can be useful if you need to power down the system and move it to a
different location, for example. To do this, type
``<Literal>/sbin/shutdown -h now</Literal>'' when signed into or
<Quote>su</Quote>ed to the <Quote>root</Quote> account. Linux will shut
itself down then display a message, <Quote>System halted</Quote>. At
this point you can power down the computer.</Para>
<Para>It is probably a good idea to only shut down the system when you are
at the console. Although you can shut it down remotely via a shell
session, if anything goes wrong and the system does not restart properly,
the system will be unavailable until action is taken at the system unit.
(I haven't experienced any problems doing this myself, however).</Para>
<Para>Upon system bootup, Linux will start automatically, and load all
necessary services including networking support, and Internet
services.</Para>
<Tip><Para>Tip: If you wish to provide some kind of warning to any online
users (online meaning logged in to shell accounts), you can substitute a
time value instead of the <Quote>now</Quote> keyword. You can also
customize the shutdown warning message. For example,
``<Literal>/sbin/shutdown -r +5 Hardware upgrade</Literal>'' would inform
users that the system was about to shutdown for the given reason. They
are then given periodic warnings that they should close files and log off
before the big moment arrives.</Para></Tip>
</Sect1>
</Chapter>
<Chapter id="custom-config"><Title>Custom Configuration and Administration Issues</Title>
<Para>For both personal use as well as at work, I was able to start with a
standard installation of the Red Hat Linux distribution and provide
services <Quote>out-of-the-box</Quote> with little or no changes to
default configuration settings.</Para>
<Para>However, there were a number of small changes and extra services
that were necessary to provide all the Internet, file &amp; print
services, and other services that are in use at my place of employment.
The local administrator should be aware of the following:</Para>
<ItemizedList Mark="Bullet" Spacing="Normal">
<ListItem><Para>The
``<Literal><Filename>/etc/rc.d/rc.local</Filename></Literal>'' file is
executed upon system start-up and contains any extra services you have
added to your server that should be executed upon
bootup.</Para></ListItem>
<ListItem><Para>Look in /etc for any site-specific changes that may be
required. These may include:</Para>
<ItemizedList Mark="Bullet" Spacing="Compact">
<ListItem><Para>``<Literal><Filename>/etc/inetd.conf</Filename></Literal>''
(you should ensure unnecessary services were disabled such as finger,
echo, chargen; as well as add or change any services you may
need)</Para></ListItem>
<ListItem><Para>``<Literal><Filename>/etc/exports</Filename></Literal>''
(contains a list of hosts allowed to mount NFS volumes; see <XRef
LinkEnd="nfs-services"> for details)</Para></ListItem>
<ListItem><Para>``<Literal><Filename>/etc/organization</Filename></Literal>'',
``<Literal><Filename>/etc/nntpserver</Filename></Literal>'',
``<Literal><Filename>/etc/NNTP_INEWS_DOMAIN</Filename></Literal>'' (set
as appropriate)</Para></ListItem>
<ListItem><Para>``<Literal><Filename>/etc/lilo.conf</Filename></Literal>''
(contains information for the LILO boot loader -- the process which loads
the Linux kernel upon bootup; see <XRef LinkEnd="install-lilo"> for
details)</Para></ListItem>
<ListItem><Para>``<Literal><Filename>/etc/sudoers</Filename></Literal>''
(a list of users who should be given special privileges, along with the
commands they are allowed to execute)</Para></ListItem>
<ListItem><Para>``<Literal><Filename>/etc/named.boot</Filename></Literal>''
(for DNS use; see <XRef LinkEnd="domain-name-server"> for
details)</Para></ListItem>
</ItemizedList></ListItem>
<ListItem><Para>Anything in
``<Literal><Filename>/usr/local/</Filename></Literal>'' (and
subdirectories) are extra packages or modifications to existing ones that
you have installed here, if you have installed from things like tarballs
instead of using RPM. (Or at least, you should have installed them
here.) These files, particularly in /usr/local/src/, should be kept
up-to-date. See <XRef LinkEnd="upgrading-linux"> for
details.</Para></ListItem>
</ItemizedList>
<Sect1 id="web-server-administration"><Title>Web Server and HTTP Caching Proxy Administration</Title>
<Warning><Para>(WARNING: DISREGARD THIS SECTION!)</Para></Warning>
<OrderedList Spacing="Normal">
<ListItem><Para>Create an Internet user as per normal. The
<Quote>shell</Quote> account should be
``<Literal><Filename>/bin/bash</Filename></Literal>'' (as FTP requires a
valid shell).</Para></ListItem>
<ListItem><Para>``<Literal>cd /home ; chown root.root theuser</Literal>''
This makes <Quote>theuser</Quote>'s directory belong to root, for
security reasons.</Para></ListItem>
<ListItem><Para>``<Literal>cd /home/theuser ; mkdir www ; chown
theuser.theuser</Literal>'' This creates their <Quote>www</Quote>
directory, and sets ownership so they can read/write to
it.</Para></ListItem>
<ListItem><Para>``<Literal>echo "exit" > .profile</Literal>''
This creates a ``<Literal><Filename>.profile</Filename></Literal>'' file
with the single line ``<Literal>exit</Literal>'' in it. If the user tries
to log in via telnet, they will get disconnected
immediately.</Para></ListItem>
<ListItem><Para>Do an ``<Literal>ls -l</Literal>'' and make sure there
are only 2 files in the directory (not including ``..'' and
``.''):</Para>
<ItemizedList Mark="Bullet" Spacing="Compact">
<ListItem><Para><Emphasis>.profile</Emphasis> (owned by
root.root)</Para></ListItem>
<ListItem><Para><Emphasis>www</Emphasis> (owned by
theuser.theuser)</Para></ListItem>
</ItemizedList>
<Para>All other files can be deleted (eg. ``<Literal>rm .less ; rm .lessrc</Literal>'')</Para></ListItem>
<ListItem><Para>If the user needs to have e-mail forwarding enabled you
could create a .forward file which simply has the proper e-mail as the
first and only line in the file.</Para></ListItem>
</OrderedList>
<Para>That's it. The user can use FTP to update the pages.</Para>
</Sect1>
<Sect1 id="domain-name-server"><Title>Domain Name Server (DNS) Configuration and Administration</Title>
<Para>At my place of employment, we are using Linux as a DNS server. It
performs exceptionally well. This section will address configuration of
DNS tables for these services using the BIND 8.x package which comes standard
with the Red Hat distribution.</Para>
<Note><Para>Note: Red Hat versions 5.1 and earlier used the BIND 4.x package,
which used a slightly different format for its configuration file. BIND
8.x offers more functionality over that offered by BIND 4.x, and as 4.x is
no longer being developed, you should probably consider upgrading your
BIND package to the latest version. Simply install the BIND RPM package
(see <XRef LinkEnd="using-rpm"> for details on using the RPM utility),
then convert your configuration file to the new format.</Para>
<Para>Fortunately, converting your existing BIND 4.x configuration file to
be compliant with BIND 8.x is easy! In the documentation directory
provided as part of BIND (for example,
``<Literal><Filename>/usr/doc/bind-8.1.2/</Filename></Literal>'' for BIND
version 8.1.2), there exists a file called
``<Literal><Filename>named-bootconf.pl</Filename></Literal>'', which is an
executable Perl program. Assuming you have Perl installed on your system,
you can use this program to convert your configuration file. To do so,
type the following commands (as root):</Para>
<Screen>
<UserInput>cd /usr/doc/bind-8.1.2</UserInput>
<UserInput>./named-bootconf.pl < /etc/named.boot > /etc/named.conf</UserInput>
<UserInput>mv /etc/named.boot /etc/named.boot-obsolete</UserInput>
</Screen>
<Para>You should now have an
``<Literal><Filename>/etc/named.conf</Filename></Literal>'' file which
should work with BIND 8.x <Quote>out-of-the-box</Quote>. Your existing
DNS tables will work as-is with the new version of BIND, as the format of
the tables remains the same.</Para>
</Note>
<Para>Configuration of DNS services under Linux involves the following
steps:</Para>
<OrderedList Spacing="Normal">
<ListItem><Para>To enable DNS services,
the ``<Literal><Filename>/etc/host.conf</Filename></Literal>'' file
should look like this:</Para>
<ProgramListing>
# Lookup names via /etc/hosts first, then by DNS query
order hosts, bind
# We don't have machines with multiple addresses
multi on
# Check for IP address spoofing
nospoof on
# Warn us if someone attempts to spoof
alert on
</ProgramListing>
<Para>The extra spoof detection adds a bit of a performance hit to DNS
lookups (although negligible), so if you're not too worried about this you
may wish to disable the <Quote>nospool</Quote> and <Quote>alert</Quote>
entries.</Para></ListItem>
<ListItem><Para>Configure the
``<Literal><Filename>/etc/hosts</Filename></Literal>'' file as needed.
Typically there doesn't need to be much in here, but for improved
performance you can add any hosts you access often (such as local
servers) to avoid performing DNS lookups on them.</Para></ListItem>
<ListItem><Para>The
``<Literal><Filename>/etc/named.conf</Filename></Literal>'' file should be
configured to point to your DNS tables according to the example below.</Para>
<Note><Para>(Note: IP addresses shown are examples only and must be replaced
with your own class addresses!):</Para></Note>
<ProgramListing>
options {
// DNS tables are located in the /var/named directory
directory "/var/named";
// Forward any unresolved requests to our ISP's name server
// (this is an example IP address only -- do not use!)
forwarders {
123.12.40.17;
};
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
};
// Enable caching and load root server info
zone "named.root" {
type hint;
file "";
};
// All our DNS information is stored in /var/named/mydomain_name.db
// (eg. if mydomain.name = foobar.com then use foobar_com.db)
zone "mydomain.name" {
type master;
file "mydomain_name.db";
allow-transfer { 123.12.41.40; };
};
// Reverse lookups for 123.12.41.*, .42.*, .43.*, .44.* class C's
// (these are example Class C's only -- do not use!)
zone "12.123.IN-ADDR.ARPA" {
type master;
file "123_12.rev";
allow-transfer { 123.12.41.40; };
};
// Reverse lookups for 126.27.18.*, .19.*, .20.* class C's
// (these are example Class C's only -- do not use!)
zone "27.126.IN-ADDR.ARPA" {
type master;
file "126_27.rev";
allow-transfer { 123.12.41.40; };
};
</ProgramListing>
<Tip><Para>Tip: Make note of the <Literal>allow-transfer</Literal>
options above, which restricts DNS zone transfers to a given IP address.
In our example, we are allowing the host at 123.12.41.40 (probably a slave
DNS server in our domain) to request zone transfers. If you omit this
option, anyone on the Internet will be able to request such transfers.
As the information provided is often used by spammers and IP spoofers, I
strongly recommend you restrict zone transfers except to your slave DNS
server(s), or use the loopback address, ``<Literal>127.0.0.1</Literal>''
instead.</Para></Tip>
</ListItem>
<ListItem><Para>Now you can set up your DNS tables in the
``<Literal><Filename>var/named/</Filename></Literal>'' directory as
configured in the
``<Literal><Filename>/etc/named.conf</Filename></Literal>'' file in step
three. Configuring DNS database files for the first time is a major
undertaking, and is beyond the scope of this document. There are several
guides, online and in printed form that should be referred to. However,
several examples are provided below.</Para>
<Para>Sample entries in the
``<Literal><Filename>/var/named/mydomain_name.db</Filename></Literal>''
forward lookup file:</Para>
<ProgramListing>
; This is the Start of Authority (SOA) record. Contains contact
; &amp; other information about the name server. The serial number
; must be changed whenever the file is updated (to inform secondary
; servers that zone information has changed).
@ IN SOA mydomain.name. postmaster.mydomain.name. (
19990811 ; Serial number
3600 ; 1 hour refresh
300 ; 5 minutes retry
172800 ; 2 days expiry
43200 ) ; 12 hours minimum
; List the name servers in use. Unresolved (entries in other zones)
; will go to our ISP's name server isp.domain.name.com
IN NS mydomain.name.
IN NS isp.domain.name.com.
; This is the mail-exchanger. You can list more than one (if
; applicable), with the integer field indicating priority (lowest
; being a higher priority)
IN MX mail.mydomain.name.
; Provides optional information on the machine type &amp; operating system
; used for the server
IN HINFO Pentium/350 LINUX
; A list of machine names &amp; addresses
spock.mydomain.name. IN A 123.12.41.40 ; OpenVMS Alpha
mail.mydomain.name. IN A 123.12.41.41 ; Linux (main server)
kirk.mydomain.name. IN A 123.12.41.42 ; Windows NT (blech!)
; Including any in our other class C's
twixel.mydomain.name. IN A 126.27.18.161 ; Linux test machine
foxone.mydomain.name. IN A 126.27.18.162 ; Linux devel. kernel
; Alias (canonical) names
gopher IN CNAME mail.mydomain.name.
ftp IN CNAME mail.mydomain.name.
www IN CNAME mail.mydomain.name.
</ProgramListing>
<Para>Sample entries in the
``<Literal><Filename>/var/named/123_12.rev</Filename></Literal>'' reverse
lookup file:</Para>
<ProgramListing>
; This is the Start of Authority record. Same as in forward lookup table.
@ IN SOA mydomain.name. postmaster.mydomain.name. (
19990811 ; Serial number
3600 ; 1 hour refresh
300 ; 5 minutes retry
172800 ; 2 days expiry
43200 ) ; 12 hours minimum
; Name servers listed as in forward lookup table
IN NS mail.mydomain.name.
IN NS isp.domain.name.com.
; A list of machine names &amp; addresses, in reverse. We are mapping
; more than one class C here, so we need to list the class B portion
; as well.
40.41 IN PTR spock.mydomain.name.
41.41 IN PTR mail.mydomain.name.
42.41 IN PTR kirk.mydomain.name.
; As you can see, we can map our other class C's as long as they are
; under the 123.12.* class B addresses
24.42 IN PTR tsingtao.mydomain.name.
250.42 IN PTR redstripe.mydomain.name.
24.43 IN PTR kirin.mydomain.name.
66.44 IN PTR sapporo.mydomain.name.
; No alias (canonical) names should be listed in the reverse lookup
; file (for obvious reasons).
</ProgramListing>
<Para>Any other reverse lookup files needed to map addresses in a different
class B (such as 126.27.*) can be created, and would look much the same
as the example reverse lookup file above.</Para></ListItem>
<ListItem><Para>Make sure the named daemon is running. This daemon is
usually started from the
``<Literal><Filename>/etc/rc.d/init.d/named</Filename></Literal>'' file
upon system boot. You can also start and stop the daemon manually; type
``<Literal>named start</Literal>'' and ``<Literal>named stop</Literal>'',
respectively.</Para></ListItem>
<ListItem><Para>Whenever changes are made to the DNS tables, the DNS
server should be restarted by typing ``<Literal>/etc/rc.d/init.d/named
restart</Literal>''. You may then wish to test your changes by using a
tool such as <Quote><Literal>nslookup</Literal></Quote> to query the
machine you have added or changed.</Para></ListItem>
</OrderedList>
<Para>More information on configuring DNS services can be found in the
``<Emphasis>DNS-HOWTO</Emphasis>'' guide at
<ULink URL="http://metalab.unc.edu/Linux/HOWTO/DNS-HOWTO-5.html">
http://metalab.unc.edu/Linux/HOWTO/DNS-HOWTO-5.html</ULink>.</Para>
</Sect1>
<Sect1 id="internet-user-authentication"><Title>Internet User Authentication with TACACS</Title>
<Para>At my place of employment, for TACACS authentication of dial-up Internet
users (who are connecting to our modem pool which are in turn connected to
a couple of Cisco 250x access servers), we are using the Vikas version of
<Quote>xtacacsd</Quote>.</Para>
<Para>After compiling and installing the Vikas package (latest versions
are available from <ULink URL="ftp://ftp.navya.com/pub/vikas">
ftp://ftp.navya.com/pub/vikas</ULink>; I don't believe the package is
available in RPM format), you should add the following entries to the
``<Literal><Filename>/etc/inetd.conf</Filename></Literal>'' file so that
the daemon will be loaded by the inetd daemon whenever a TACACS request
is received.</Para>
<ProgramListing>
# TACACS is a user authentication protocol used for Cisco Router products.
tacacs dgram udp wait root /etc/xtacacsd xtacacsd -c /etc/xtacacsd-conf
</ProgramListing>
<Para>Next, you should edit the
``<Literal><Filename>/etc/xtacacsd-conf</Filename></Literal>'' file and
customize it, as necessary, for your system (however you will probably be
able to use the default settings as-is).</Para>
<Note><Para>Note: If you are using shadow passwords (see <XRef
LinkEnd="shadow-file-formats"> for details), you will have some problems
with this package. Unfortunately, PAM (Pluggable Authentication Module),
which Red Hat uses for user authentication, is not supported by this
package. One workaround that I use is to keep a separate
``<Literal><Filename>passwd</Filename></Literal>'' file in
``<Literal><Filename>/usr/local/xtacacs/etc/</Filename></Literal>'' which
matches the one in /etc/ but is non-shadowed. This is a bit of a hassle,
and if you choose to do this make sure you set permissions on the other
password file to make sure it is only readable by root:</Para></Note>
<Screen>
<UserInput>chmod a-wr,u+r /usr/local/xtacacs/etc/passwd</UserInput>
</Screen>
<Para>If you do indeed use shadow, you will most certainly need to edit
the ``<Literal><Filename>/etc/xtacacsd-conf</Filename></Literal>'' file
and location of the non-shadowed password file (assuming you are using
the workaround I have suggested above).</Para>
<Para>The next step is to configure your access server(s) to authenticate
logins for the desired devices (such as dial-up modems) with TACACS.
Here is a sample session on how this is done:</Para>
<Screen>
<Prompt>mail:/tftpboot#</Prompt> <UserInput>telnet xyzrouter</UserInput>
Escape character is '^]'.
User Access Verification
<Prompt>Password:</Prompt> <UserInput>****</UserInput>
<Prompt>xyzrouter></Prompt> <UserInput>enable</UserInput>
<Prompt>Password:</Prompt> <UserInput>****</UserInput>
<Prompt>xyzrouter#</Prompt> <UserInput>config terminal</UserInput>
Enter configuration commands, one per line. End with CNTL/Z.
<Prompt>xyzrouter(config)#</Prompt> <UserInput>tacacs-server attempts 3</UserInput>
<Prompt>xyzrouter(config)#</Prompt> <UserInput>tacacs-server authenticate connections</UserInput>
<Prompt>xyzrouter(config)#</Prompt> <UserInput>tacacs-server extended</UserInput>
<Prompt>xyzrouter(config)#</Prompt> <UserInput>tacacs-server host 123.12.41.41</UserInput>
<Prompt>xyzrouter(config)#</Prompt> <UserInput>tacacs-server notify connections</UserInput>
<Prompt>xyzrouter(config)#</Prompt> <UserInput>tacacs-server notify enable</UserInput>
<Prompt>xyzrouter(config)#</Prompt> <UserInput>tacacs-server notify logouts</UserInput>
<Prompt>xyzrouter(config)#</Prompt> <UserInput>tacacs-server notify slip</UserInput>
<Prompt>xyzrouter(config)#</Prompt> <UserInput>line 2 10</UserInput>
<Prompt>xyzrouter(config-line)#</Prompt> <UserInput>login tacacs</UserInput>
<Prompt>xyzrouter(config-line)#</Prompt> <UserInput>exit</UserInput>
<Prompt>xyzrouter(config)#</Prompt> <UserInput>exit</UserInput>
<Prompt>xyzrouter#</Prompt> <UserInput>write</UserInput>
Building configuration...
<Prompt>[OK]</Prompt> <UserInput> </UserInput>
<Prompt>xyzrouter#</Prompt> <UserInput>exit</UserInput>
Connection closed by foreign host.
</Screen>
<Para>All TACACS activity log messages will be recorded in
``<Literal><Filename>/var/log/messages</Filename></Literal>'' for your
perusal.</Para>
</Sect1>
<Sect1 id="samba-file-and-print"><Title>Windows-style File and Print Services with Samba</Title>
<Para>Linux can provide SMB services (eg. WfW, Win95, and NT-style network
file &amp; printer sharing), using the Samba package. This section will
describe how to configure shares, and how to access them from client
machines.</Para>
<Para>The Samba package is included with the Red Hat distribution, you can
check if it is installed and what version you have by typing:</Para>
<Screen>
<UserInput>rpm -q samba</UserInput>
</Screen>
<Para>If it isn't installed, you will need to install it using the RPM
utility. See <XRef LinkEnd="using-rpm"> for details on how to do
this.</Para>
<Para>The most important Samba files you should concern yourself with
are:</Para>
<VariableList>
<VarListEntry>
<Term>/etc/smb.conf</Term>
<ListItem><Para>Samba configuration file where shares and other
configuration parameters are set up (see below)</Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>/var/log/samba/</Term>
<ListItem><Para>Location of Samba log files</Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>/home/samba/</Term>
<ListItem><Para>Suggested location where file shares should be set up.
However, you should choose a location where you have enough space on the
file system to accomodate the files you will store. Personally, I usually
set up a large partition mounted on /archive/ and place my shares
here.</Para></ListItem>
</VarListEntry>
</VariableList>
<Para>The file ``<Literal><Filename>/etc/smb.conf</Filename></Literal>''
contains configuration information on file &amp; print shares. The first
few lines of the file contain global configuration directives, which are
common to all shares (unless they are over-ridden on a per-share basis),
followed by share sections.</Para>
<Para>The Samba installation includes a default smb.conf file which in
many cases should be adequate for your needs and require only a few
changes.</Para>
<Para>Here is an example of this file (which I have heavily customized to
show you some of the more important and interesting options):</Para>
<ProgramListing>
# Items common to all shares (unless over-ridden on a per-share basis)
[global]
# Number of minutes of inactivity before client is disconnected
# to avoid consuming resources. Most clients will automatically
# reconnect so this is a good idea to enable.
dead time = 10
# Don't let users connect as <Quote>root</Quote>, just-in-case. :-)
invalid users = root
# Specify the account for guest shares (shares that don't require
# a password to connect to. This username must be a valid user
# in the /etc/passwd file.
guest account = guest
# Specify where log files should be written to. The <Quote>%m</Quote> suffix
# means that log files will be created in the format
# log.machine-name (eg. <Quote>log.twixel</Quote>)
log file = /usr/local/samba/logs/log.%m
# Maximum size of log file, in Kilobytes.
max log size = 1000
# Password level 3 means that case is not an issue when entering
# passwords. A little less secure than level 1 or 2 would be,
# but seems to be a fair compromise for user convenience.
password level = 3
# Specify that all shares should appear in the browse list
# (override any you don't want on a per-share basis).
browseable = yes
# If this is enabled, you can see active connections using the
# <Quote>smbstatus</Quote> command.
status = yes
# The level of debugging information that is recorded in the log
# files. Higher values generate more information (which is
# probably not very useful, most of the time).
debug level = 2
# This will send any Windows-style <Quote>POPUP</Quote> messages received on
# the server to the postmaster by e-mail. Not very useful, but
# an interesting demonstration of what can be accomplished.
message command = /bin/mail -s 'Message from %f on %m' postmaster < %s; rm %s &amp;
# This is a form of caching that, when enabled, may improve
# performance when reading files.
read prediction = true
# A list of services that should be added automatically to the
# browse-list.
auto services = cdrom
# The location of your <Quote>printcap</Quote> file, a text file containing
# definitions for your printers.
printcap name = /etc/printcap
# If enabled all printers in the /etc/printcap file will be
# loaded into the browse-list.
load printers = yes
# The print command by which data is spooled to a printer under Linux.
print command = lpr -r -P%p %s
# The print command by which job queue information (printer status)
# can be obtained.
lpq command = lpq -P%p
# The print command by which unwanted print jobs can be deleted
# from the queue.
lprm command = lprm -P%p %j
# The level at which Samba advertises itself for browse elections.
# Currently set to a high value to give it an even <Quote>foot-hold</Quote> with
# any swarmy NT servers on the network. :-)
os level = 34
# These are user's personal shares. If the client's username matches on the
# server, they can access their home directory (provided they enter the
# correct password).
[homes]
# The comments appear in the browse list.
comment = Home Directories
# This matches the username of the client to that of the share.
# If they do not match, no share will be displayed in the browse
# list, or available to connect to.
user = %S
# The path to the share. For example, <Quote>smithj</Quote> would map to
# <Quote>/home/smithj</Quote>
path = /home/%S
# If enabled, allow read/write access to the shares.
writeable = yes
# Just an inverted synonym for <Quote>writeable</Quote>. We don't *really* need
# to use both. :-)
read only = no
# Keep this disabled so that a password is required to access these
# shares.
public = no
# We don't want this share (after all, it is private) to appear in
# the browse-list of other users.
browseable = no
# This is a publicly available print share, called <Quote>hp_laser</Quote>. It appears
# on the browse lists and can be accessed without a password by any client.
[hp_laser]
# The comment that appears in the browse-list.
comment = Main office printer (HP Laserjet 400)
# The username that this share is accessed as (guest means all users).
user = guest
# All generated print files will first be created in the /tmp
# directory.
path = /tmp
# Do not allow file creation except through print spooling.
writeable = no
# Set permissions accordingly -- root access to print jobs only.
create mode = 0700
# If this is enabled a password is not required to access the share.
public = yes
# This should be enabled to indicate that this is a printer share.
printable = yes
# Here is a service providing access to the CD-ROM device.
[cdrom]
comment = Shared CD-ROM drive on Linux
user = guest
path = /cdrom
writeable = no
read only = true
browseable = yes
public = yes
guest ok = yes
</ProgramListing>
<Tip><Para>Tip: Recent versions of Samba, from 2.0 onwards, provide a
very slick web-based configuration utility called
``<Emphasis>swat</Emphasis>'', which makes the process much more
user-friendly. The utility listens on TCP port <Emphasis>901</Emphasis>
of your server, so to use the utility just point your favourite web
browser as follows:</Para></Tip>
<Screen>
mydomain.name:901
</Screen>
<Para>(Of course, in order to use the SWAT utility you will need to have
a web server running, such as Apache. See <XRef
LinkEnd="web-server-administration"> for details.)</Para>
<Para>The latest Samba versions also add considerable features in comparison with
versions prior to 2.0. It is worth taking the time to upgrade this
package.</Para>
<Para>A client must have a TCP/IP network stack running in order to
connect to shares. Further, for browsing to work, the TCP/IP protocol
must be bound to NETBEUI. Under Windows 95 this can be configured from
the <Quote>Network</Quote> icon from within the Control Panel.</Para>
<Para>Assuming the client has been configured properly, you should see the
server shares appear in their <Quote>Network Neighborhood</Quote> (or
equivalent browsing scheme if you are not using Windows 95/NT). You can
then map network drives from the network neighborhood, or type in an
absolute path to the share (<Emphasis>eg.
<Quote>\\mail\cdrom</Quote></Emphasis>). If the shared service requires a
password to be entered, you will be prompted for one.</Para>
<Para>More information on Samba can be obtained from the Samba Home Page
at <ULink URL="http://samba.anu.edu.au/samba/">
http://samba.anu.edu.au/samba/</ULink>.</Para>
</Sect1>
<Sect1 id="netatalk-file-and-print"><Title>Macintosh-style File and Print Services with Netatalk</Title>
<Para>Linux can also provide Appleshare services (eg. Macintosh-style network
file &amp; printer sharing), using the Netatalk package. This section will
describe how to configure shares, and how to access them from client
machines.</Para>
<Para>In order to use Netatalk, you will need to have Appletalk networking
support in your Linux kernel. Stock kernels from Red Hat usually already
include this support as a module, or you can compile your own custom
kernel with such support.</Para>
<Note><Para>Note: Make sure Appletalk support is compiled in as a
<Emphasis>module</Emphasis> and not included as part of the kernel (see
<XRef LinkEnd="linux-kernel-upgrades"> for details on how to upgrade or
customize the Linux kernel). Otherwise you will have difficulties when
stopping and then restarting the Netatalk daemon.</Para></Note>
<Para>Once you have ensured your kernel is capable of supporting Appletalk, you
will need to install the Netatalk package. Because Netatalk is not
included with the Red Hat distribution, you will have to download and
install a copy. The Netatalk package can be found on Red Hat's
<Quote>contrib</Quote> site, at
<ULink URL="ftp://ftp.redhat.com/contrib/libc6/i386/">
ftp://ftp.redhat.com/contrib/libc6/i386/</ULink>.</Para>
<Para>After Netatalk has been installed, you may need to modify one or
more configuration files in
``<Literal><Filename>/etc/atalk/</Filename></Literal>''. Most of the
files contain sample configuration examples, and therefore are at least
somewhat self-documenting. The files are:</Para>
<VariableList>
<VarListEntry>
<Term>config</Term>
<ListItem><Para>This file contains configuration information for tuning
your Netatalk daemon. This information is specified in environment
variables, and this file is <Quote>sourced</Quote> (ie. read) by the
Netatalk start up script before the service is started. You can specify
the number of simultaneous connections, whether or not guest logins are
allowed, etc. You will almost certainly want to modify this file
according to your needs.</Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>atalk.conf</Term>
<ListItem><Para>This file contains information on which network interface
to use, as well as your Appletalk routing, name registration, and other
related information. You will likely not need to modify this file; the
required network information is detected and added to this file the first
time you start the Netatalk server. However, you may wish to add your
server name.</Para>
<Note><Para><Emphasis>Note: Type ``<Literal>man atalkd</Literal>'' for
more information on this file.</Emphasis></Para></Note></ListItem>
</VarListEntry>
<VarListEntry>
<Term>afpd.conf</Term>
<ListItem><Para>This file allows you to specify additional parameters
which are passed to Netatalk by means of command-line options. You can
specify which port or IP address you wish to run the Netatalk server on,
add a login message that is displayed to connecting users, as well as
other related options. You will likely not need to modify this file.</Para>
<Note><Para><Emphasis>Note: Type ``<Literal>man afpd</Literal>'' for more
information on this file.</Emphasis></Para></Note></ListItem>
</VarListEntry>
<VarListEntry>
<Term>papd.conf</Term>
<ListItem><Para>The file contains configuration information for enabling
Mac users to print to network printer shares. I haven't played with this
yet, so unfortunately I can't offer any advice on it.</Para>
<Note><Para><Emphasis>Note: Type ``<Literal>man papd</Literal>'' for more
information on this file.</Emphasis></Para></Note></ListItem>
</VarListEntry>
<VarListEntry>
<Term>AppleVolumes.default</Term>
<ListItem><Para>This file lists the available file shares that a Mac user
will see after logging in. To enable a share, enter the path to the file
directory, followed by a textual description of it. For example:</Para>
<ProgramListing>
~ "Home"
/archive/busdept "Business Department Common Files"
</ProgramListing>
<Para>(The above will provide two shares to connecting Mac users: their
home directory, as well as a shared area for the business
department.)</Para>
<Tip><Para>Tip: A neat trick here is to set up shares with the same
file paths under Samba, which would provide your users with platform-
independent file shares for both your Mac as well as your Windows users.
See <XRef LinkEnd="samba-file-and-print"> for details on using
Samba.</Para></Tip></ListItem>
</VarListEntry>
<VarListEntry>
<Term>AppleVolumes.system</Term>
<ListItem><Para>This file also lists file shares just like
``<Literal><Filename>AppleVolumes.default</Filename></Literal>'' does, the
difference being that these shares will be made available to
<Emphasis>all</Emphasis> users, regardless of whether or not they log in.
This file also contains file-type mappings. You will likely not need to
modify this file unless you want to add general shares available to
anyone; this is probably a bad idea for most people.</Para></ListItem>
</VarListEntry>
</VariableList>
<Para>Once everything has been set up with appropriate configuration
information, you can start the Netatalk services manually by
typing:</Para>
<Screen>
<UserInput>/etc/rc.d/init.d/atalk start</UserInput>
</Screen>
<Para>(The services should start up automatically at system boot).</Para>
<Para>More information on Netatalk can be obtained from the Netatalk Home
Page at <ULink URL="http://www.umich.edu/~rsug/netatalk/">
http://www.umich.edu/~rsug/netatalk/</ULink>. In addition, very helpful
configuration information is available in the Linux Netatalk HOWTO,
available at <ULink URL="http://thehamptons.com/anders/netatalk/">
http://thehamptons.com/anders/netatalk/</ULink>.</Para>
</Sect1>
<Sect1 id="nfs-services"><Title>Network File System (NFS) Services</Title>
<Para>Linux can act as both client and server for file systems shared
using the Network File System (NFS) protocol, which is the defacto
standard for providing file system mounts among Unix systems.</Para>
<Note><Para>Note: Please be aware that having an NFS service available on
your system can be a security risk. Personally, I don't recommend using
it.</Para></Note>
<Para>In order to use NFS, you will need to ensure that NFS support has
been included in your kernel or kernel modules. See
<XRef LinkEnd="linux-kernel-upgrades"> for details on how to upgrade or
customize the Linux kernel.</Para>
<Para>NFS shares are configured by modifying the
``<Literal><Filename>/etc/exports</Filename></Literal>'' file. Here are some
example entries, showing some of the options available:</Para>
<ProgramListing>
/archive spock.mydomain.name(ro)
/archive2 spock.mydomain.name(ro)
/mnt/cdrom other.domain(ro)
/archive2 10.23.14.8(ro,insecure)
</ProgramListing>
<Para>The first couple of lines allow the host, ``spock.mydomain.name''
access to both the ``<Literal><Filename>/archive</Filename></Literal>''
as well as the ``<Literal><Filename>/archive2</Filename></Literal>''
directories via NFS. These shares are made available read-only with the
``<Literal>(ro)</Literal>'' option. For security reasons, it is a good
idea to do this for all of your NFS shares if at all possible.</Para>
<Para>The third line will allow any host in the ``domain.name'' domain
name space to access the CD-ROM drive. Of course, it is necessary to
mount the CD-ROM device to ``<Literal>/mnt/cdrom</Literal>'' first.</Para>
<Note><Para>Note: Using the ``<Literal>(ro)</Literal>)'' option to mark this
device read-only may seem a bit redundant, however doing so will prevent a
miscreant from writing to a real file system should the CD-ROM device not
be mounted.</Para></Note>
<Para>After you have made changes to the
``<Literal><Filename>/etc/exports</Filename></Literal>'' file, you will
need to restart the NFS daemon. To do so, type:</Para>
<Screen>
<UserInput>/etc/rc.d/init.d/nfs restart</UserInput>
</Screen>
<Para>You can also configure your NFS mount points with the
``<Literal>Network Configurator</Literal>'' tool included in the
``<Literal>Linuxconf</Literal>'' utility. For more information on the
Linuxconf utility, see <XRef LinkEnd="linuxconf">.</Para>
<Para>More information on NFS can be found in the
``<Emphasis>NFS-HOWTO</Emphasis>'' guide at <ULink
URL="http://metalab.unc.edu/LDP/HOWTO/NFS-HOWTO.html">
http://metalab.unc.edu/LDP/HOWTO/NFS-HOWTO.html</ULink>, as well as in
the man pages on ``<Literal>nfsd</Literal>'' and
``<Literal>exports</Literal>''.</Para>
</Sect1>
<Sect1 id="linuxconf"><Title>Configuration from A-Z with Linuxconf</Title>
<Para>There is an excellent tool called ``<Literal>linuxconf</Literal>''
which can make many configuration issues easier to do. Linuxconf runs on
whatever means of display environment it has available to it -- you can
run it from the console, over a telnet session, and as a GUI-based tool
under X and it will automatically start up in the appropriate
manner.</Para>
<Para>If you need to adjust your system time, modify your network
settings, set up file systems, perform user administration, as well as
perform many other administrative and configuration duties, you should
give this tool a try. The only caveat I would give is that, at the time of
this writing, the GUI-based tool is still a bit <Quote>buggy</Quote> and
at times may stop responding to mouse clicks. However, this tool is a
promising work in progress, and future revisions should become quite
usable.</Para>
</Sect1>
</Chapter>
<Chapter id="backup-and-restore"><Title>Backup and Restore Procedures</Title>
<Para>Performing regular backups should be considered one of a responsible
system administrator's top priorities. Although Linux is an extremely
reliable operating system, failures can, do, and probably will occur.
They may be caused by hardware failure, power outages, or other unforeseen
problems.</Para>
<Para>More likely will be those problems caused by human error, resulting in
undesired changes to, or even deletions of, crucial files. If you are
hosting users on your system, you will most certainly be requested to
restore an inadvertently deleted file or two.</Para>
<Para>If you perform regular backups, preferably on a daily basis (at least
for user files which are updated often), you will hopefully reduce the
possibility of, and increase your recovery from, such file lossage.</Para>
<Para>The safest method of doing backups is to record them on separate media,
such as tape, removable drive, writeable CD, etc., and then store your
backup sets in a location separate from your Linux system. Sometimes this
may not be practical -- perhaps you do not have a fire-proof vault in
which you can store your backup tapes! Or perhaps you do not have access
to such an external backup system in the first place. Nonetheless, backups
can still be performed, albeit on a slightly limited basis.</Para>
<Para>At my place of employment, I perform backups on several Linux
servers. Depending on the situation, some of these backup sets are
written to tapes, others are written to a separate server over the
network, while still others are simply written to a separate disk
partition (for example, in the
``<Literal><Filename>/archive/</Filename></Literal>'' file system) by an
automatic cron job (perhaps because the server is in a remote location,
for which a daily visit to perform a tape backup is impractical or
impossible).</Para>
<Para>At home, I do not have an external backup system, nor do I have
massive amounts of available disk space to write a backup image.
Therefore, I instead back up only my user files on
``<Literal><Filename>/home/</Filename></Literal>'' as well as some
customized configuration files in
``<Literal><Filename>/etc/</Filename></Literal>'', writing the backup set
to a separate disk partition.</Para>
<Sect1 id="server-backup"><Title>Server Backup Procedures</Title>
<Para>There are a variety of methods of performing backups with Linux.
These include command-line tools included with every Linux distribution,
such as ``dd'', ``dump'', ``cpio'', as well as ``tar''. Also available
are text-based utilities, such as ``Amanda'' and ``Taper'', which is
designed to add a more user-friendly interface to the backup and restore
procedures. There are GUI-based utilities as well, such as ``KDat''.
Finally, commercial backup utilities are also available, such as ``BRU''
and ``PerfectBackup+''. Any one of these backup solutions can provide
protection for your valuable data.</Para>
<Para>A brief listing of some of the tools available, including where they
can be obtained, can be found on the <Quote>Linux Applications and
Utilities Page</Quote>, at <ULink
URL="http://www.xnet.com/~blatura/linapp2.html#back">
http://www.xnet.com/~blatura/linapp2.html#back</ULink>. When deciding on
a backup solution, you will need to consider the following factors:</Para>
<ItemizedList Mark="Bullet" Spacing="Normal">
<ListItem><Para><Emphasis>Portability</Emphasis> - Is backup portability
(ie. the ability to backup on one Linux distribution or implementation of
Unix and restore to another; for example from Solaris to Red Hat Linux)
important to you? If so, you'll probably want to choose one of the
command-line tools (eg. ``dd'', ``dump'', ``cpio'', or ``tar''), because
you can be reasonably sure that such tools will be available on any *nix
system.</Para></ListItem>
<ListItem><Para><Emphasis>Unattended or automated backups</Emphasis> - Is
the ability to automate backups so that they can be performed at regular
intervals without human intervention important to you? If so, you will
need to choose both a tool and a backup medium which will support such a
backup scheme.</Para></ListItem>
<ListItem><Para><Emphasis>User-friendliness</Emphasis> - Is a
user-friendly interface important to you? If so, you will likely want to
choose a tool which provides a text- or GUI-based interface. The
commercial utilities may provide the easiest interfaces as well as added
technical support.</Para></ListItem>
<ListItem><Para><Emphasis>Remote backups</Emphasis> - Is the ability to
start backups and restores from a remote machine important to you? If so,
you'll probably want to choose one of the command-line tools or text-based
utilities instead of the GUI-based utilities (unless you have a reasonably
fast network connection and the ability to run remote X
sessions).</Para></ListItem>
<ListItem><Para><Emphasis>Network backups</Emphasis> - Is performing
backups and restores to and from networked hosts important to you? If so,
you'll probably want to use one of several of the command-line utilities
(such as ``tar'') which support network access to backup devices, or a
specialized utility such as ``Amanda'' or one of several commercial
utilities.</Para></ListItem>
<ListItem><Para><Emphasis>Media types</Emphasis> - Backups can be stored
on a variety of medium, such as tape, an extra hard drive, ZIP drives, or
rewritable CDs. Consider cost vs. reliability, storage capacitity, and
transfer speed.</Para></ListItem>
</ItemizedList>
<Caution><Para>Caution: When backing up your file systems, do
<Emphasis>not</Emphasis> include the
``<Literal><Filename>/proc</Filename></Literal>'' pseudo-filesystem!
The files in /proc are not actually files but are simply file-like links
which describe and point to kernel data structures. Backing up a file
like ``<Literal><Filename>/proc/kcore</Filename></Literal>'', which is
actually a pseudo-file containing the contents of your entire memory,
seems like a pretty big waste of tape to me! :-) You will also likely
want to avoid backing up the
``<Literal><Filename>/mnt</Filename></Literal>'' file system, unless you
have the peculiar desire to back up the files from your CD-ROM device,
floppy drive, network file shares, or other mounted
devices.</Para></Caution>
<Para>Obviously, the procedures for performing a backup and restore will
differ depending on your choice of a backup solution. However, in this
section, I will discuss methods for performing backups with the two tools
I use most: ``tar'' (whose name stands for <Quote>Tape ARchiver</Quote>),
which is a command-line backup tool largely portable across *nix systems;
as well as ``KDat'', a GUI-based tape backup utility which comes included
with the KDE packages (see <XRef LinkEnd="using-kde"> for more information
on KDE).</Para>
<Para>Finally, I should add that, depending on your choice of backup
solution, even if the tool doesn't have the ability built-in to schedule
automated or unattended backups, you may be able to automate such backups
by using the cron facilities. See <XRef LinkEnd="using-cron">
for details on using cron and on creating crontab schedule files.</Para>
<Sect2 id="tar-backup"><Title>Backing up with ``tar'':</Title>
<Para>If you decide to use ``tar'' as your backup solution, you should
probably take the time to get to know the various command-line options
that are available; type <Quote><Literal>man tar</Literal></Quote> for a
comprehensive list. You will also need to know how to access the
appropriate backup media; although all devices are treated like files in
the Unix world, if you are writing to a character device such as a tape,
the name of the <Quote>file</Quote> is the device name itself (eg.
``<Literal><Filename>/dev/nst0</Filename></Literal>'' for a SCSI-based tape
drive).</Para>
<Para>The following command will perform a backup of your entire Linux
system onto the ``<Literal><Filename>/archive/</Filename></Literal>''
file system, with the exception of the
``<Literal><Filename>/proc/</Filename></Literal>'' pseudo-filesystem, any
mounted file systems in
``<Literal><Filename>/mnt/</Filename></Literal>'', the
``<Literal><Filename>/archive/</Filename></Literal>'' file system (no
sense backing up our backup sets!), as well as Squid's rather large cache
files (which are, in my opinion, a waste of backup media and unnecessary
to back up):</Para>
<Screen>
<UserInput>tar -zcvpf /archive/full-backup-`date '+%d-%B-%Y'`.tar.gz \
--directory / --exclude=mnt --exclude=proc --exclude=var/spool/squid .</UserInput>
</Screen>
<Para>Don't be intimidated by the length of the command above! As we
break it down into its components, you will see the beauty of this
powerful utility.</Para>
<Para>The above command specifies the options ``<Emphasis>z</Emphasis>''
(compress; the backup data will be compressed with ``gzip''),
``<Emphasis>c</Emphasis>'' (create; an archive file is begin created),
``<Emphasis>v</Emphasis>'' (verbose; display a list of files as they get
backed up), ``<Emphasis>p</Emphasis>'' (preserve permissions; file
protection information will be <Quote>remembered</Quote> so they can be
restored). The ``<Emphasis>f</Emphasis>'' (file) option states that the
very next argument will be the name of the archive file (or device) being
written. Notice how a filename which contains the current date is
derived, simply by enclosing the ``date'' command between two back-quote
characters. A common naming convention is to add a
``<Literal><Filename>tar</Filename></Literal>'' suffix for non-compressed
archives, and a ``<Literal><Filename>tar.gz</Filename></Literal>'' suffix
for compressed ones.</Para>
<Para>The ``<Emphasis>--directory</Emphasis>'' option tells tar to first
switch to the following directory path (the
``<Literal><Filename>/</Filename></Literal>'' directory in this example) prior to
starting the backup. The ``<Emphasis>--exclude</Emphasis>'' options tell
tar not to bother backing up the specified directories or files.
Finally, the ``<Emphasis>.</Emphasis>'' character tells tar that it should
back up everything in the current directory.</Para>
<Note><Para>Note: It is important to realize that the options to tar
are cAsE-sEnSiTiVe! In addition, most of the options can be specified as
either single mneumonic characters (eg. ``f''), or by their
easier-to-memorize full option names (eg. ``file''). The mneumonic
representations are identified by prefixing them with a ``-'' character,
while the full names are prefixed with two such characters. Again, see
the <Quote>man</Quote> pages for information on using tar.</Para></Note>
<Para>Another example, this time writing only the specified file systems
(as opposed to writing them <Emphasis>all</Emphasis> with exceptions as
demonstrated in the example above) onto a SCSI tape drive follows:</Para>
<Screen>
<UserInput>tar -cvpf /dev/nst0 --label="Backup set created on `date '+%d-%B-%Y'`." \
--directory / --exclude=var/spool/ etc home usr/local var/spool</UserInput>
</Screen>
<Para>In the above command, notice that the ``<Emphasis>z</Emphasis>''
(compress) option is not used. I <Emphasis>strongly</Emphasis> recommend
against writing compressed data to tape, because if data on a portion of
the tape becomes corrupted, you will lose your entire backup set!
However, archive files stored without compression have a very high
recoverability for non-affected files, even if portions of the tape
archive are corrupted.</Para>
<Para>Because the tape drive is a character device, it is not possible to
specify an actual file name. Therefore, the file name used as an
argument to tar is simply the name of the device,
``<Literal><Filename>/dev/nst0</Filename></Literal>'', the first tape
device on the SCSI bus.</Para>
<Note><Para>Note: The ``<Literal><Filename>/dev/nst0</Filename></Literal>''
device does not rewind after the backup set is written; therefore it is
possible to write multiple sets on one tape. (You may also refer to the
device as ``<Literal><Filename>/dev/st0</Filename></Literal>'', in which
case the tape is automatically rewound after the backup set is
written.)</Para></Note>
<Para>Since we aren't able to specify a filename for the backup set, the
``<Emphasis>--label</Emphasis>'' option can be used to write some
information about the backup set into the archive file itself.</Para>
<Para>Finally, only the files contained in the
``<Literal><Filename>/etc/</Filename></Literal>'',
``<Literal><Filename>/home/</Filename></Literal>'',
``<Literal><Filename>/usr/local</Filename></Literal>'', and
``<Literal><Filename>/var/spool/</Filename></Literal>'' (with the exception of
Squid's cache data files) are written to the tape.</Para>
<Para>When working with tapes, you can use the following commands to
rewind, and then eject your tape:</Para>
<Screen>
<UserInput>mt -f /dev/nst0 rewind</UserInput>
<UserInput>mt -f /dev/nst0 offline</UserInput>
</Screen>
<Tip><Para>Tip: You will notice that leading ``<Literal>/</Literal>''
(slash) characters are stripped by tar when an archive file is created.
This is tar's default mode of operation, and it is intended to protect you
from overwriting critical files with older versions of those files, should
you mistakenly recover the wrong file(s) in a restore operation. If you
really dislike this behavior (remember, its a
<Emphasis>feature</Emphasis>!) you can specify the
``<Literal>--absolute-paths</Literal>'' option to tar, which will preserve
the leading slashes. However, I don't recommend doing so, as it is
<Emphasis>Dangerous</Emphasis>!</Para></Tip>
</Sect2>
<Sect2 id="kdat-backup"><Title>Backing up with ``KDat'':</Title>
<Para>If you are using the KDE desktop environment, I believe you will
find the ``KDat'' utility both powerful as well as user-friendly. In
addition, an added bonus is that KDat uses ``tar'' as its backup engine.
Therefore, backup sets written with KDat can be read not only with KDat
but with tar as well! This makes KDat a very nice choice for both
user-friendliness as well as backup portability.</Para>
<Tip><Para>Tip: Even if you choose not to use nor install the full KDE
package, you can <Emphasis>still</Emphasis> use KDat as long as you have
the Qt libraries installed.</Para></Tip>
<Para>The first time you run the KDat program, you will need to create a
backup profile. Such a profile tells KDat which files on your system you
would like to back up. If you wish, you can create more than one backup
profile, depending on your needs (for example, you could create a profile
called <Quote><Emphasis>Full Backup</Emphasis></Quote> for a full system
backup, and <Quote><Emphasis>Quick Backup</Emphasis></Quote> for a backup
of user files only).</Para>
<Para>To create a backup profile, either choose <Quote><Literal>Create
Backup Profile</Literal></Quote> from the
<Quote><Literal>File</Literal></Quote> option on menu bar (or right-click
on the <Quote><Literal>Backup Profiles</Literal></Quote> folder, then
choose <Quote><Literal>Create Backup Profile</Literal></Quote>). On the
right hand side of the KDat window, you can change various settings, such
as the profile name, archive name, tar options, as well as others. Click
the <Quote><Literal>Help</Literal></Quote> menu for more information on
what these settings are for.</Para>
<Para>To specify which files should be included in your backup profile,
left-click the checkbox beside the
``<Literal><Filename>/</Filename></Literal>'' directory folder. This
will enable all files in and below this directory for backups. Then,
left-click on the small ``+'' sign beside the folder. This will expand
the folder, showing a list of files in and below it. This will allow you
to exclude any files you do not wish to backup; simply left-click the
checkbox beside each file or directory you wish to exclude. For example,
a full backup should probably have every file and directory checkmarked,
with the exception of the
``<Literal><Filename>/proc</Filename></Literal>'' (a pseudo-filesystem
containing information about your running system),
``<Literal><Filename>/mnt</Filename></Literal>'' (a directory below which
CD-ROM drives, floppies, and network shares are usually mounted), and, if
you are a Squid user,
``<Literal><Filename>/var/spool/squid</Filename></Literal>'' (Squid's
cache data files). Once you have selected the appropriate files,
left-click on the backup profile you are creating, then left-click the
<Quote><Literal>Files &gt;&gt;</Literal></Quote> button to move the
selected files list to your backup profile.</Para>
<Note><Para>Note: Should your server data be larger in size than can be
physically stored on a tape, you will need to create separate backup
profiles, one for each portion of your backup set.</Para></Note>
<Para>To actually perform a backup, insert a tape into the drive, and
then choose <Quote><Literal>Mount Tape</Literal></Quote> from the
<Quote><Literal>File</Literal></Quote> menu (or left-click the icon that
looks like a tape). This will <Quote><Emphasis>mount</Emphasis></Quote>
the tape (actually, because a tape device is a character device, it isn't
actually possible to mount it -- what KDat actually does is to first
rewind the tape, attempts to read in header information, and if
successful, find the corresponding tape index on your hard drive.
Otherwise, KDat will prompt you to format the tape.</Para>
<Note><Para>(Note: If KDat keeps complaining that a tape isn't in the drive and
it actually <Emphasis>is</Emphasis> in the drive, you should ensure the
correct tape device name is specified in the preferences; left-click the
<Quote><Literal>Edit</Literal></Quote> option on the menu bar and choose
<Quote><Literal>User Preferences</Literal></Quote>.)</Para></Note>
<Para>Once KDat has mounted the tape, before you start the backup you
must first choose the backup profile you wish to use for the backup. To
start the backup, simply right-click on the desired backup profile, and
then left-click on the <Quote><Literal>Backup</Literal></Quote> option.
KDat will first display a dialog box showing you the details of the
backup profile you have selected; left-click the
<Quote><Literal>Ok</Literal></Quote> button to start the backup.</Para>
<Para>While the backup is in progress, KDat will display a dialog box
showing various statistical information (elapsed time, backup size, backup
rate, estimated time remaining, as well as the number of files and total
bytes written), and display a list of files as they are backed up. A full
backup containing several gigabytes of data might take several hours to
complete. If you find it necessary, you can left-click the
<Quote>Abort</Quote> button at any time to interrupt the backup
process.</Para>
<Para>Once the backup is complete, you can unmount the tape by choosing
<Quote>Edit</Quote> from the menu bar, and then <Quote>Unmount
Tape</Quote>, or left-click on the tape icon, which will rewind and eject
the tape.</Para>
</Sect2>
</Sect1>
<Sect1 id="server-restore"><Title>Server Restore Procedures</Title>
<Para>Unarguably, the one thing that is more important than performing
regular backups is having them available when it comes time to recover an
important file!</Para>
<Para>Obviously, as discussed in <XRef LinkEnd="server-backup">, the
procedures for performing a restore will differ depending on your choice
of a backup solution. In this section, I will discuss methods for
restoring files which have been backed up with ``tar'' and
''KDat''.</Para>
<Sect2 id="tar-restore"><Title>Restoring with ``tar'':</Title>
<Para>The following command will restore all files from the
``<Literal><Filename>full-backup-09-October-1999.tar.gz</Filename></Literal>''
archive, which is an example backup of our Linux system (as created in the
example commands shown in <XRef LinkEnd="tar-backup">:</Para>
<Screen>
<UserInput>tar -zxvpf /archive/full-backup-09-October-1999.tar.gz</UserInput>
</Screen>
<Para>The above command extracts all files contained in the compressed
archive, preserving original file ownership and permissions. The
``<Literal>x</Literal>'' option stands for extract. (The other options
are described in <XRef LinkEnd="tar-backup">.</Para>
<Caution><Para>Caution: Extracting files from a tar archive can be a
dangerous thing to do, and should therefore be done with caution.
Perhaps the files were not archived without a file path prepended (a few
misguided or uninformed developers distribute tarballs of their software
offerings like this), meaning they will all be extracted into the current
directory. Perhaps the files were archived with leading
``<Literal>/</Literal>'' slashes (by specify the
``<Literal>--absolute-paths</Literal>'' option when the archive was
created), meaning the files will be restored to their absolute locations
(even if you didn't want them to be). Or, perhaps the files were archived
<Emphasis>without</Emphasis> leading ``<Literal>/</Literal>'' slashes,
meaning the files will be restored under the current directory (even if
you didn't want them to be). This of course, depends on how the backup
was created. For this reason, I strongly recommend testing your ``tar''
command with a ``<Literal>t</Literal>'' (<Emphasis>type</Emphasis>) option
<Emphasis>first,</Emphasis> and then replace the ``<Literal>t</Literal>''
with an ``<Literal>x</Literal>'' (<Emphasis>extract</Emphasis>) when you
are absolutely sure the command will do what you expect it
to.</Para></Caution>
<Para>If you do not need to restore all files contained in the archive,
you can specify one or more files that you wish to restore, as in the
following example:</Para>
<Screen>
<UserInput>tar -zxvpf /archive/full-backup-09-October-1999.tar.gz \
etc/profile usr/local/bin/tolower</UserInput>
</Screen>
<Para>The above command restores the
``<Literal><Filename>etc/profile</Filename></Literal>'' and
``<Literal><Filename>usr/local/bin/tolower</Filename></Literal>'' files
from the example archive.</Para>
<Tip><Para>If you are trying to restore only one or a few files from
your archive, you will not be successful unless you specify the <
file name and directory path <Emphasis>exactly</Emphasis> as stored in
the archive. The following example might help out:</Para>
<Screen>
<UserInput>tar -ztvpf /archive/full-backup-09-October-1999.tar.gz \
| grep -i profile</UserInput>
</Screen>
<Para>In the above example, all files contained in the archive are listed
by file name. The resulting output is then piped to the
``<Literal>grep</Literal>'' command (using grep's ``<Literal>i</Literal>''
option to ignore mixed case), displaying any files containing ``profile''
in either the directory path or file name. Once you determine the exact
file name you wish to restore, you can then specify it for extraction in
a regular tar command expression.</Para></Tip>
<Para>As mentioned in <XRef LinkEnd="server-backup">, when creating an
archive file, tar will strip leading ``<Literal>/</Literal>'' (slash)
characters from file path names. This means that restore files may not
end up in the same locations they were backed up from. Therefore, either
change to the ``<Literal><Filename>/</Filename></Literal>'' root
directory, or use the ``<Literal>--directory /</Literal>'' option.</Para>
<Note><Para>Note: A far safer solution is to restore the desired files under a
different directory (for example, your home directory), and then compare,
move, or update the files to their original locations afterward.</Para></Note>
</Sect2>
<Sect2 id="kdat-restore"><Title>Restoring with ``KDat'':</Title>
<Para>To restore one or more files from a KDat-created backup set, insert
the backup tape into the drive, choose <Quote><Literal>Mount
Tape</Literal></Quote> from the <Quote><Literal>File</Literal></Quote>
menu option (or left-click on the icon that looks like a tape).</Para>
<Para>KDat will try to read header information from the tape, and if
successful, will then try to find the tape index which matches the
identification found in the tape header. This tape index is stored on
your hard drive, and is a unique file created for each backup tape
formatted by KDat, and is updated each time you perform a backup.</Para>
<Para>If this corresponding tape index is missing (perhaps you are
restoring from a backup set created on another machine, or the index file
was deleted or somehow corrupted on your hard drive), KDat will inform you
of this fact, and ask you if it is okay to recreate the index by reading
the tape. Because you will need to recreate it before you will be able to
restore your desired files, it makes perfect sense to left-click
<Quote>Yes</Quote>.</Para>
<Note><Para>(Note: Once a tape is reindexed, its name is changed to
<Quote><Emphasis>Reindexed Tape</Emphasis></Quote>. You should rename the
tape to its original name.)</Para></Note>
<Para>Once the tape index has been successfully read, it can then used to
select the directories or files you wish to restore from the backup set,
in much the same manner you used when creating your backup profiles (see
<XRef LinkEnd="server-backup"> for detailed instructions on the file
selection process).</Para>
<Para>Once you have selected the appropriate files, you can start the
restoration process by choosing
<Quote><Literal>Restore...</Literal></Quote> from the <Quote>File</Quote>
option on the menu bar (or left-click the tape restore icon). KDat will
display a dialog box, allowing you to confirm which files will be
restored. In addition, you have the option of specifying a directory
into which files will be restored. This will allow you to restore
critical system files into your home directory, and then compare, move,
or update those files to their intended location later on. This is
actually the safest way of restoring files.</Para>
<Para>To begin the recovery process, click the
<Quote><Literal>Okay</Literal></Quote> button. KDat will then scan the
tape and restore the selected files.</Para>
<Para>On occasion, you may find it necessary or useful to restore one or
more files from a backup set created with KDat
<Emphasis>without</Emphasis> using KDat to do so. Perhaps you would like
to restore such files on a system that does not offer a GUI-based
environment, or would like to do so over a slow network connection through
which remote execution of KDat would be impractical. Fortunately, KDat
writes its backup data sets using the ``tar'' tool, a command-line based
tool that is available on any *nix system.</Para>
<Para>Should you wish to restore your KDat-created backup set using tar, simply
do so using whatever options you would with any normal backup set created
with tar itself. Bear in mind, however, that data sets are not stored
in compressed format.</Para>
<Note><Para>Note: You will almost certainly get an error message when trying to
access the KDat backup set with tar. This is because of the header and
other information that KDat added to the tape when it was first formatted.
Simply repeat the tar command two or three times to skip to the beginning
of the actual tar archive file.</Para></Note>
</Sect2>
</Sect1>
<Sect1 id="router-configuration"><Title>Cisco Router Configuration Backups</Title>
<Para>At my place of employment, we have a WAN connecting several remote
locations. These remote locations have Cisco routers connected via ISDN,
or in some instances, Centrex data circuits, to provide Internet and WAN
connectivity. Cisco router products allow using TFTP (<Quote>Trivial File
Transfer Protocol</Quote>) on a network server to read and write
configuration files. Whenever a router configuration is changed, it is
important to save the configuration file on the Linux server so that a
backup is maintained.</Para>
<Para>Please note that Red Hat disables the TFTP service by default,
because it can be a real security hole if not configured properly. The
TFTP daemon allows anyone to read and write files without performing
authentication. The way I personally set things up is to create a
``<Literal><Filename>/tftpboot/</Filename></Literal>'' directory, owned
by root, and then modify the existing configuration line in the
``<Literal><Filename>/etc/inetd.conf</Filename></Literal>'' file to
specify the file location:</Para>
<ProgramListing>
tftpd dgram udp wait root /usr/sbin/tcpd in.tftpd /tftpboot
</ProgramListing>
<Note><Para>Note: Adding the ``<Literal>/tftpboot</Literal>'' path at the end of
the above line specifically indicates where the TFTP daemon is allowed to
access files. Although you can actually leave this part out and allow
TFTP to access files anywhere on your system, as TFTP is considered
somewhat of a security risk, this would probably be a very bad
idea.</Para></Note>
<Para>Once you have enabled the TFTP service, don't forget to type:</Para>
<Screen>
<UserInput>killall -HUP inetd</UserInput>
</Screen>
<Para>The above command restarts the INETD daemon to recognize whatever
changes you have made to the inetd.conf file.</Para>
<Para>Creating a backup of a router configuration file involves a 3-step
process: setting permissions on an existing file (or creating a new one)
to allow writes, writing the backup file, and then resetting permissions
to restrict access to the file. An example router backup session
follows:</Para>
<Screen>
<Prompt>mail:~#</Prompt> <UserInput>cd /tftpboot</UserInput>
<Prompt>mail:/tftpboot#</Prompt> <UserInput>chmod a+w xyzrouter-confg</UserInput>
chmod: xyzrouter-confg: No such file or directory
<Prompt>mail:/tftpboot#</Prompt> <UserInput>touch xyzrouter-confg</UserInput>
<Prompt>mail:/tftpboot#</Prompt> <UserInput>chmod a+w loyola-confg</UserInput>
<Prompt>mail:/tftpboot#</Prompt> <UserInput>telnet xyzrouter</UserInput>
Escape character is '^]'.
User Access Verification
<Prompt>Password:</Prompt> <UserInput>****</UserInput>
<Prompt>xyzrouter></Prompt> <UserInput>enable</UserInput>
<Prompt>Password:</Prompt> <UserInput>****</UserInput>
<Prompt>xyzrouter#</Prompt> <UserInput>write network</UserInput>
<Prompt>Remote host []?</Prompt> <UserInput>123.12.41.41</UserInput>
<Prompt>Name of configuration file to write [xyzrouter-confg]?</Prompt> <UserInput> </UserInput>
<Prompt>Write file xyzrouter-confg on host 123.12.41.41? [confirm]</Prompt> <UserInput> </UserInput>
Building configuration...
<Prompt>Writing xyzrouter-confg !! [OK]</Prompt><UserInput> </UserInput>
<Prompt>xyzrouter#</Prompt> <UserInput>exit</UserInput>
Connection closed by foreign host.
<Prompt>mail:/tftpboot#</Prompt> <UserInput>chmod a-wr,u+r xyzrouter-confg</UserInput>
<Prompt>mail:/tftpboot#</Prompt> <UserInput>exit</UserInput>
</Screen>
<Para>In case of router failure (caused, for example, by a power surge
during a lightning storm), these backup files can be helpful to reload the
router configuration. Again, restoring from a configuration file involves
a 3-step process: setting permissions on the existing file, loading the
file, and then resetting permissions to restrict access to the file. An
example router restoration session follows.</Para>
<Screen>
<Prompt>mail:~#</Prompt> <UserInput>cd /tftpboot</UserInput>
<Prompt>mail:/tftpboot#</Prompt> <UserInput>chmod a+r xyzrouter-confg</UserInput>
<Prompt>mail:/tftpboot#</Prompt> <UserInput>telnet xyzrouter</UserInput>
Escape character is '^]'.
User Access Verification
<Prompt>Password:</Prompt> <UserInput>****</UserInput>
<Prompt>xyzrouter></Prompt> <UserInput>enable</UserInput>
<Prompt>Password:</Prompt> <UserInput>****</UserInput>
<Prompt>xyzrouter#</Prompt> <UserInput>config network</UserInput>
<Prompt>Host or network configuration file [host]?</Prompt> <UserInput> </UserInput>
<Prompt>Address of remote host [255.255.255.255]?</Prompt> <UserInput>123.12.41.41</UserInput>
<Prompt>Name of configuration file [xyzrouter-confg]?</Prompt> <UserInput> </UserInput>
<Prompt>Configure using loyola-confg from 123.12.41.41? [confirm]</Prompt> <UserInput> </UserInput>
Loading xyzrouter-confg from 123.12.41.41 (via BRI0): !
[OK - 1265/32723 bytes]
<Prompt>xyzrouter#</Prompt> <UserInput>write</UserInput>
<Prompt>xyzrouter#</Prompt> <UserInput>exit</UserInput>
Connection closed by foreign host.
<Prompt>mail:/tftpboot#</Prompt> <UserInput>chmod a-wr,u+r xyzrouter-confg</UserInput>
<Prompt>mail:/tftpboot#</Prompt> <UserInput>exit</UserInput>
</Screen>
</Sect1>
</Chapter>
<Chapter id="various-and-sundry"><Title>Various &amp; Sundry Administrative Tasks</Title>
<Para>Linux has proven itself to be extremely reliable during the over four
years I have had it in service as an Internet server and requires very
little hands-on administration to keep it running. Where possible, many
repetitive or tedious administrative tasks can and should be automated
through crontab entries and script files. However, to ensure that Linux
continues to operate in a trouble-free manner, various quick checks can be
done from time to time. These include:</Para>
<Sect1 id="checking-storage-space"><Title>Checking Storage Space</Title>
<Para>It is important to check from time to time that adequate free space
remains on the storage devices. Use the <Quote><Literal>df</Literal></Quote>
command to get a report of available space. It will look as follows
(information shown is from the Internet server at my place of
employment):</Para>
<Screen>
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda1 1888052 135908 1654551 8% /
/dev/sdd1 4299828 100084 3977246 2% /archive
/dev/hda2 3048303 897858 1992794 31% /archive2
/dev/hda1 11677 1380 9694 12% /boot
/dev/sdc1 4299828 350310 3727020 9% /home
/dev/sdb1 4299828 598504 3478826 15% /usr
/dev/sda2 1888083 700414 1090075 39% /var
/dev/scd0 593958 593958 0 100% /cdrom
</Screen>
<Para>These file-systems are pretty stable in that they have a fairly slow
growth pattern.</Para>
<Para>The <Quote><Emphasis>/</Emphasis></Quote> (aka root) file-system,
mounted on /dev/hda1, contains the Linux kernel, device drivers, and
other directories. It also is where user mail messages are stored
(<Emphasis>/var/spool/mail/</Emphasis>) as well as log files
(<Emphasis>/var/adm/</Emphasis>) but as mail messages are received and
log files are recycled, the available capacity stays fairly stable (an
estimated growth of about 1% per month). Log files are rotated and
purged automatically on a weekly basis, so you'll always have about a
month's worth of log information available to you.</Para>
<Tip><Para>Tip: If this file-system is growing rapidly, concentrate your
efforts in the /var/spool/mail directory -- look for huge mailboxes
(something like ``<Literal>find /var/spool/mail -size +1000k</Literal>''
would display a list of mailboxes larger than 1Mb in size). If you find a
file much larger than 1,000,000 bytes in size, the user probably isn't
retrieving their mail, is on a high-volume mailing list, or their e-mail
package isn't configured to remove the mail from the server. Contact the
user and/or clear the mail file, using <Quote><Literal>&gt;
mailbox</Literal></Quote>, (eg. ``<Literal>&gt;smithj</Literal>'' to clear
Joe Smith's mail box). Also check the
``<Literal><Filename>/tmp/</Filename></Literal>'' directory, which may
need to be cleaned out on an occasional basis (usually old tin* files left
over from aborted newsreader sessions, old print files, etc).</Para></Tip>
<Para>The <Quote>/usr/</Quote> (aka user) file-system, mounted on
/dev/hda2, contains user-installable (user meaning user-installed by
system administrator) software, things like your web site pages, etc.
This is the largest file-system, and is also fairly slow-growth. The log
files for the web pages may also be stored here, and grow in size; check
and trim them periodically as needed. On my machines, at the beginning of
each month the current web log files are moved to month summary logs (eg.
access_log.11 for November's log entries). At the end of the year these
logs are all deleted and the cycle starts again (which means each January
1st should see a fair improvement in available space).</Para>
<Tip><Para>Tip: If this file-system is growing rapidly, check the
``<Filename>/usr/local/etc/httpd/logs</Filename>'' and the
``<Filename>/usr/local/squid/logs/</Filename>'' directories (if you have
them). There may be log file(s) that are getting too large (if, perhaps,
the web site received a high number of visits). If, however, the logs are
purged automatically on a regular basis as I have them, you shouldn't run
into any problems with space here (indeed, as the logs are used for
statistical analysis of my site's traffic I'd rather not have to delete
them if possible). Another place to check for potentially deletable files
is in ``<Filename>/usr/tmp/</Filename>''.</Para></Tip>
<Para>The <Quote>/home/</Quote> (aka user's personal home) file-system,
mounted on /dev/hda3, contains all the user directories and personal
files. Unless you are giving out shell accounts, most of these will be
useless and inaccessible to the user (these directories are created when
each users' accounts are created, and can later be used to forward the
user's mail, etc.). However shell account users, as well as any non-shell
accounts which have web pages (eg. personal web pages) will probably have
them stored here. In addition, main server pages are stored here in the
/home/httpd directory under Red Hat, while other distributions usually
place them in the /usr file system (see <XRef
LinkEnd="web-server-administration"> for more information).</Para>
<Para>This file-system is probably the slowest growth unless you are
offering a lot of shell accounts.</Para>
<Tip><Para>Tip: If this file-system suddenly grows in size, it is probably
because one of your users is adding web pages or binary files in his/her
personal space. Check the
``<Literal><Filename>/var/adm/xferlog.*</Filename></Literal>'' log files
for recent activity, which should show you which user has added to their
web pages.</Para></Tip>
<Para>I also have an <Quote>/archive/</Quote> (aka archive files) file-system,
mounted on /dev/hdb1, which is a spare 1.02 Gb hard drive that can be used
for any purpose (eg. data files, software kits, etc.) I am using a good
portion (approximately 70%) of this drive for disk-to-disk full current
backups of the system). Generally speaking you can add your own devices
and mount them as you wish.</Para>
<Para>I also have a CD-ROM drive, mounted as <Quote>/mnt/cdrom/</Quote> on
/dev/scd0, which is a 24X-speed SCSI CD-ROM device that can read any
ISO9660 formatted CD. It is used primarily for software installation, but
DOS/Windows CD's can be mounted and then accessed from Windows 3.x/95/NT
network shares as needed via a Samba service (see <XRef
LinkEnd="samba-file-and-print"> for details).</Para>
<Para>The <Quote><Literal>rm</Literal></Quote> command will delete a file.
Usage is ``<Literal>rm filename</Literal>''. If you want confirmation of
deletion, use the <Quote><Literal>-i</Literal></Quote> option (eg.
``<Literal>rm -i *</Literal>''). You would then be asked to confirm each
file before it is deleted.</Para>
<Note><Para>(Note: This is the default for normal shell users, but beware -- the
root account will not confirm before deleting files unless you specify the
<Quote>-i</Quote> option!)</Para></Note>
<Para>Be careful you don't make a silly typo with this command --
particularly when logged in as <Quote>root</Quote> -- because you may end
up regretting deleting the wrong file.</Para>
</Sect1>
<Sect1 id="managing-processes"><Title>Managing Processes</Title>
<Para>From time to time you may wish to view processes that are running
on Linux. To obtain a list of these processes, type ``<Literal>ps
-aux</Literal>'', which will look similar to the following:</Para>
<Screen>
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
bin 69 0.0 1.0 788 320 ? S Nov 30 0:00 /usr/sbin/rpc.portmap
frampton 10273 0.0 2.1 1136 664 p0 S 14:12 0:00 -bash
frampton 10744 0.0 1.1 820 360 p0 R 17:25 0:00 ps -aux
frampton 10745 0.0 0.8 788 264 p0 S 17:25 0:00 more
nobody 10132 0.0 1.8 1016 588 ? S 13:36 0:00 httpd
nobody 10133 0.0 1.8 988 568 ? S 13:36 0:00 httpd
nobody 10413 0.0 1.8 1012 580 ? S 14:56 0:00 httpd
nobody 10416 0.0 1.8 1012 580 ? S 14:56 0:00 httpd
nobody 10418 0.0 1.8 1012 588 ? S 14:57 0:00 httpd
nobody 10488 0.0 1.7 976 556 ? S 15:34 0:00 httpd
nobody 10564 0.0 1.8 988 564 ? S 16:06 0:00 httpd
nobody 10600 0.0 1.8 988 564 ? S 16:15 0:00 httpd
nobody 10670 0.0 1.8 988 568 ? S 16:45 0:00 httpd
nobody 10704 0.0 1.7 976 552 ? S 17:03 0:00 httpd
root 1 0.0 1.0 776 312 ? S Nov 30 1:13 init [3]
root 2 0.0 0.0 0 0 ? SW Nov 30 0:00 (kflushd)
root 3 0.0 0.0 0 0 ? SW Nov 30 0:00 (kswapd)
</Screen>
<Para>The list shows you the owner of the process (<Quote>nobody</Quote>
for special services such as web servers), the process identification
number, the % of CPU time the process is currently using, the % of memory
the process is consuming, and other related information, as well as a
description of the task itself.</Para>
<Para>To get more information on a given process, type ``<Literal>ps
<Option>pid</Option></Literal>'' (where
<Quote><Literal><Option>pid</Option></Literal></Quote> is the process
identification number). Looking at our example above, <Quote><Literal>ps
10704</Literal></Quote> would display:</Para>
<Screen>
10704 ? S 0:00 /usr/local/etc/httpd/httpd
</Screen>
<Para>This would tell you that this particular process is a web server (the
Apache web server appears multiple times in the process list; for
information on why see <XRef LinkEnd="web-server-administration">).</Para>
<Para>If you happen to notice a service is not operating, you can use the
<Quote><Literal>kill -HUP <Option>pid</Option></Literal></Quote> (where
<Quote><Literal><Option>pid</Option></Literal></Quote> is the process
identification number as shown in the process list produced with
<Quote>ps</Quote>). For example, if Internet services (a process called
inetd, process #123 in our example) are not working as they should, a
``<Literal>kill -HUP 123</Literal>'' (or even safer, use the
``<Literal>killall</Literal>'' command and specify the process name:
``<Literal>killall -HUP inetd</Literal>'') should restart the process.
The <Option>-HUP</Option> option to the kill command means <Quote>hang
up</Quote>; the process knows that it is supposed to reload itself.</Para>
<Para>Another thing to try if you are unable to resolve the problem would
be to shut the system down and reboot it (see <XRef
LinkEnd="system-shutdown-and-restart"> for details).</Para>
<Para>At times, you may find it necessary to temporarily suspend a
process, and then resume its execution at a later time. For example,
you may be running a CPU-intensive job and wish to burn an IDE-based
CDRecordable. Since IDE-based devices rely on the CPU for much of the
work behind input/output, they are prone to buffer starvation if your
CPU is too busy, and you end up with a useless coaster instead of a
properly prepared CD! The following two commands will suspend a process,
and the resume it, respectively:</Para>
<Screen>
kill -STOP 945
kill -CONT 945
</Screen>
<Para>Red Hat provides a better way of starting and stopping some processes,
which are covered in <XRef LinkEnd="redhat-processes"> below.</Para>
</Sect1>
<Sect1 id="redhat-processes"><Title>Starting and Stopping Processes</Title>
<Para>The Red Hat distribution of Linux provides a slightly more organized
way of managing processes. Instead of hunting and killing them by finding
their process id in the process table, Red Hat provides a collection of
scripts in the ``<Literal><Filename>/etc/rc.d/init.d</Filename></Literal>''
directory which will allow you to start and stop processes as
desired.</Para>
<Para>For example, to shut down the ``<Literal>httpd</Literal>'' (Apache
web server) service, simply run the httpd script, as follows:</Para>
<Screen>
<UserInput>/etc/rc.d/init.d/httpd stop</UserInput>
</Screen>
<Para>In much the same manner, you can use the
``<Literal>start</Literal>'' option to start a service. Or, if you have
made changes to a configuration file and wish to restart a service so
those changes are recognized, you can use the ``<Literal>restart</Literal>''
option.</Para>
<Note><Para>(Note: Oddly enough, the ``<Literal>restart</Literal>'' option does
not seem to be supported for some services.)</Para></Note>
</Sect1>
<Sect1 id="using-cron"><Title>Automating Tasks with Cron and Crontab files</Title>
<Para>Like most Linux users, you may find it necessary to schedule
repetitive tasks to be run at a certain time. Such tasks can occur as
frequently as once a minute, to as infrequently as once a year. This
scheduling can be done by using the ``cron'' facilities.</Para>
<Para>The cron facilities as implemented in Linux are fairly similar to
those available in other Unix implementations. However, Red Hat has
adopted a slightly different way of scheduling tasks than is usually done
in other distributions of Linux. Just as in other distributions,
scheduling information is placed in the system
``<Literal><Filename>crontab</Filename></Literal>'' file (locating in the
``<Literal><Filename>/etc/</Filename></Literal>'' directory), using the
following format:</Para>
<ProgramListing>
minute hour day month year command
</ProgramListing>
<Para>You can specify each time component as an integer number (eg. 1
through 12 for the months January through December), or specify one or
more components as ``<Literal>*</Literal>'' characters which will be
treated as wildcards (eg. * in the month component means the command will
run at the given day and time in <Emphasis>every</Emphasis> month. Here
are some examples:</Para>
<ProgramListing>
# Mail the system logs at 4:30pm every June 15th.
30 16 15 06 * for x in /var/log/*; do cat ${x} | mail postmaster; done
# Inform the administrator, at midnight, of the changing seasons.
00 00 20 04 * echo 'Woohoo, spring is here!'
00 00 20 06 * echo 'Yeah, summer has arrived, time to hit the beach!'
00 00 20 10 * echo 'Fall has arrived. Get those jackets out. :-('
00 00 20 12 * echo 'Time for 5 months of misery. ;-('
</ProgramListing>
<Para>Note that commands which produce output to standard out (ie. a
terminal) such as the examples above using ``<Literal>echo</Literal>''
will have their output mailed to the ``<Literal>root</Literal>'' account.
If you want to avoid this, simply pipe the output to the null device as
follows:</Para>
<ProgramListing>
00 06 * * * echo 'I bug the system administrator daily at 6:00am!' >/dev/null
</ProgramListing>
<Para>In addition to the standard ``<Literal>crontab</Literal>'' entries,
Red Hat adds several directories:</Para>
<Screen>
/etc/cron.hourly/
/etc/cron.daily/
/etc/cron.weekly/
</Screen>
<Para>As their names suggest, executable files can be placed in any of
these directories, and will be executed on an hourly, daily, or weekly
basis. This saves a bit of time when setting up frequent tasks; just place
the executable script or program (or a symbolic link to one stores
elsewhere) in the appropriate directory and forget about it.</Para>
</Sect1>
</Chapter>
<Chapter id="upgrading-linux"><Title>Upgrading Linux and Other Applications</Title>
<Para>To get the most out of your Linux system, such as adding features,
getting rid of potential bugs, and ensuring it is reasonably free of
security holes, it is a good idea to keep your server -- including the
Linux kernel, modules, and user applications -- upgraded. At times it may
also be necessary to upgrade hardware components such as a larger hard
drive. This chapter will address these issues.</Para>
<Sect1 id="using-rpm"><Title>Using the Red Hat Package Manager (RPM)</Title>
<Para>The Red Hat distribution of Linux, including kernel, libraries, and
applications are provided as RPM files. An RPM file, also known as a
<Quote>package</Quote> is a way of distributing software so that it can
be easily installed, upgraded, queried, and deleted. RPM files contain
information on the package's name, version, other file dependency
information (if applicable), platform (such as Intel or Alpha, etc.),
as well as default file install locations.</Para>
<Para>The RPM utility was first developed by Red Hat and provided as an Open
Source product as is common in the Linux community. Other developers
picked it up and added extra functionality. The RPM method of packaging
files has become popular and is used not only on Red Hat's but on some
other distributions as well.</Para>
<Para>Popular Linux applications are almost always released as RPM files,
usually in fairly short order. However, in the Unix world the
defacto-standard for package distribution continues to be by way of
so-called <Quote>tarballs</Quote>. Tarballs are simply files that are
readable with the ``<Literal>tar</Literal>'' utility. Installing from
tar is usually significantly more tedious than using RPM. So why would
people choose to do so? Unfortunately, sometimes it takes a few weeks
for developers to get the latest version of a package converted to RPM
(many developers first release them as tarballs).</Para>
<Para>If you start installing or upgrading your system or applications with
tar, your RPM database will become out-of-date and inconsistent. This
isn't really a big deal (when I used Slackware, I used tar exclusively
-- there was no other choice -- without too much discomfort), but wherever
possible I try to be patient and wait until an RPM becomes available,
or perhaps send a polite request to the developer of the package. (You
can also build your own RPM files and distribute them to others, which
is sometimes helpful to developers who don't have the ability or time to
produce such files themselves.)</Para>
<Para>A really good place to check if a piece of software is available in RPM
form is the RPM repository at <ULink URL="http://rufus.w3.org/linux/RPM/">
http://rufus.w3.org/linux/RPM/</ULink>. The repository provides indexed
categories which can be helpful to locate a given RPM file, and contains
pointers to thousands of such files.</Para>
<Para>To query a package, use ``<Literal>rpm -q pkg-name</Literal>'' (eg.
``<Literal>rpm -q pine</Literal>''). RPM will either tell you what
version of the package is already installed, or that the package is not
installed.</Para>
<Para>Assuming the package is installed already, and is an earlier
version than the update package you downloaded (which it should be), then
you should be able to apply the update with ``<Literal>rpm -Uvh
pkg-name</Literal>''. If all goes well, the package will be
automatically installed and immediately ready for use. If not, RPM will
give you a pretty good reason (for example, perhaps a supporting package
needs to be upgraded first). This may require a bit of thinking, but
problems such as these are very straightforward to figure out.</Para>
<Para>If, on the other hand, the package is <Emphasis>not</Emphasis> yet
installed, and you decide you wish to install it, type ``<Literal>rpm
-ivh pkg-name</Literal>''. If there are any supporting packages that are
required, RPM will tell you.</Para>
<Para>Sometimes, you will want to install a package that is only available
in source format. In fact, unless you are installing packages from a
trusted source (such as the Red Hat FTP site), you probably
<Emphasis>should</Emphasis> install from source in case the binaries
contain a trojan horse or other nasty thing (of course, a source RPM could
also contain such a thing, but they are unlikely to because they would
probably be exposed in short order by another developer).</Para>
<Para>The way to install a package from source is to specify the
``<Literal>rebuild</Literal>'' switch to the RPM utility. For
example:</Para>
<Screen>
<UserInput>rpm -ivh --rebuild foo.src.rpm</UserInput>
</Screen>
<Para>The above command would configure and compile the ``foo'' package,
producing a binary RPM file in the
``<Literal><Filename>/usr/src/redhat/RPMS/i386/</Filename></Literal>''
directory (assuming you are using Linux on the Intel platform). You can
then install the package as you normally would.</Para>
<Para>Finally, if you are having problems getting a source package to compile
(perhaps you need to modify a makefile, or change a configuration option,
etc.) you can use the following steps (again, illustrating our ficticious
``foo'' package example) to compile the source, build a new
binary package, and then install from the binary package:</Para>
<Screen>
<UserInput>rpm -ivh foo.src.rpm</UserInput>
<UserInput>cd /usr/src/redhat/SPECS</UserInput>
<UserInput>pico -w foo.spec</UserInput>
</Screen>
<Para>Make whatever changes you feel are needed to the ``.spec'' file, and
then type:</Para>
<Screen>
<UserInput>rpm -ba foo.spec</UserInput>
</Screen>
<Para>This will rebuild the package using whatever changes you have made
to the ``.spec'' file. As above, the resultant binary RPM file will be
located in
``<Literal><Filename>/usr/src/redhat/RPMS/i386/</Filename></Literal>'',
and can be installed as you normally would.</Para>
<Para>You should look at the Red Hat documentation for more information
on RPM. It is an extremely powerful tool that is worth learning in finer
detail. The best source of information on RPM is ``Maximum RPM'', which
is available in both book form, as well as in postscript format at <ULink
URL="http://www.rpm.org/maximum-rpm.ps.gz">
http://www.rpm.org/maximum-rpm.ps.gz</ULink>. (If you decide to print
the postscript document, be advised that you'll need a
<Emphasis>lot</Emphasis> of paper to do so!) There is a smaller guide,
the ``<Literal>RPM-HOWTO</Literal>'', at <ULink
URL="http://www.rpm.org/support/RPM-HOWTO.html">
http://www.rpm.org/support/RPM-HOWTO.html</ULink> available as
well.</Para>
</Sect1>
<Sect1 id="using-tarballs"><Title>Installing or Upgrading Without RPM</Title>
<Para>Sometimes, you may find it necessary to install or upgrade an
application for which an RPM package is not available. Of course, it is
certainly possible to do such a thing (in fact, it is the
<Quote>defacto-standard</Quote> way of doing things in the so-called
<Quote>real</Quote> Unix world), but I would recommend against it unless
absolutely necessary (for reasons why, see <XRef
LinkEnd="using-rpm">).</Para>
<Para>Should you need to install anything from tarballs, the general rule
of thumb for system-wide software installations is to place things in your
``<Literal><Filename>/usr/local/</Filename></Literal>'' filesystem.
Therefore, source tarballs would be untarred in
``<Literal><Filename>/usr/local/src/</Filename></Literal>'', while
resultant binaries would probably be installed in
``<Literal><Filename>/usr/local/bin</Filename></Literal>'', with their
configuration files in
``<Literal><Filename>/usr/local/etc/</Filename></Literal>''. Following
such a scheme will make the administration of your system a bit easier
(although, not as easy as on an RPM-only system).</Para>
<Para>Finally, end-users who wish to install software from tarballs for
their own private use will probably do so under their own home
directory.</Para>
<Para>After downloading the tarball from your trusted software archive
site, change to the appropriate top-level directory and untar the archive
by typing commands (as root, if necessary) as in the following
example:</Para>
<Screen>
tar zxvpf cardgame.tar.gz
</Screen>
<Para>The above command will extract all files from the example
``<Literal><Filename>cardgame.tar.gz</Filename></Literal>'' compressed
archive. The ``<Literal>z</Literal>'' option tells tar that the archive
is compressed with gzip (so omit this option if your tarball is not
compressed); the ``<Literal>x</Literal>'' option tells tar to extract all
files from the archive. The ``<Literal>v</Literal>'' option is for
verbose, listing all filenames to the display as they are extracted. The
``<Literal>p</Literal>'' option maintains the original and permissions the
files had as the archive was created. Finally, the
``<Literal>f</Literal>'' option tells tar that the very next argument is
the file name. Don't forget that options to tar are
cAsE-sEnSiTiVe.</Para>
<Caution><Para>Caution: As mentioned in <XRef LinkEnd="tar-restore">, I
recommend first using the ``<Emphasis>t</Emphasis>'' option to display the
archive contents to verify the contents prior to actually extracting the
files. Doing so may help avoid extracting files to unintended locations,
or even worse, inadvertently overwriting existing files.</Para></Caution>
<Para>Once the tarball has been installed into the appropriate directory,
you will almost certainly find a
``<Literal><Filename>README</Filename></Literal>'' or a
``<Literal><Filename>INSTALL</Filename></Literal>'' file included with
the newly installed files, with further instructions on how to prepare
the software package for use. Likely, you will need to enter commands
similar to the following example:</Para>
<Screen>
./configure
make
make install
</Screen>
<Para>The above commands would configure the software to ensure your
system has the necessary functionality and libraries to successfully
compile the package, compile all source files into executable binaries,
and then install the binaries and any supporting files into the
appropriate locations. The actual procedures you will need to follow may,
of course, vary between various software packages, so you should read any
included documentation thoroughly.</Para>
<Para>Again, unless it is absolutely necessary, I really recommend
avoiding tarballs and sticking to RPM if you can.</Para>
</Sect1>
<Sect1 id="keeping-up-to-date"><Title>Strategies for Keeping an Up-to-date System</Title>
<Para>From time to time you may hear of significant upgrades to the Linux kernel
or user applications from various sources. These sources may be
magazines, newsgroups, web pages, etc.</Para>
<Para>Probably the best single online resource that a Linux administrator
should -- nay, <Emphasis>must</Emphasis> -- keep an eye on is the <ULink
URL="http://freshmeat.net/">http://freshmeat.net/</ULink> web site. This
site contains descriptions of new Open Source applications and projects,
documentation, and other announcements of interest to the Linux
community.</Para>
<Para>Another resource for keeping track of new applications announcements is
through the <ULink URL="news:comp.os.linux.announce">
comp.os.linux.announce</ULink> newsgroup. This newsgroup contains
postings of new applications, some kernel or application upgrades, web
pages, etc. available for Linux. It is a moderated newsgroup and
therefore has a high <Quote>signal to noise</Quote> ratio.</Para>
<Para>Not all product upgrade announcements are made to comp.os.linux.announce,
however. Therefore, visiting the web pages or FTP sites for the
applications you are using is probably a very good idea as well.</Para>
</Sect1>
<Sect1 id="linux-kernel-upgrades"><Title>Linux Kernel Upgrades</Title>
<Para>From time to time it may be wise to upgrade your Linux kernel.
This will allow you to keep up with the new features and bug fixes as they
become available. Or, perhaps, you are running Linux on new or specialty
hardware, or wish to enable certain features for which a custom kernel is
needed.</Para>
<Para>This section will describe upgrading and customizing a new kernel.
It isn't as difficult as you might think!</Para>
<Para>Announcements of new kernel versions can be obtained through various
sources, including the <ULink URL="news:comp.os.linux.announce">
comp.os.linux.announce</ULink> newsgroup, as well as on the
<ULink URL="http://freshmeat.net/">http://freshmeat.net/</ULink>
and <ULink URL="http://slashdot.org/">http://slashdot.org/</ULink>
web sites.</Para>
<Para>Please note that there are currently two <Quote>streams</Quote> of
kernel development -- one stream is considered <Quote>stable</Quote>
releases, while the other stream is considered <Quote>development</Quote>
releases. For mission critical applications such as an Internet server,
it is highly recommended that you use the stable releases and stay away
from the development kernels.</Para>
<Para>The difference between the two streams is that, with the development
kernels, new as-yet untested hardware drivers, filesystems, and other
<Quote>cutting edge</Quote> developments are introduced on a regular basis.
These kernels are for use by hackers only -- people who don't mind having
to reboot their system, should a kernel bug rear its ugly head.</Para>
<Para>The stable kernels introduce new features and drivers only after they have
been thoroughly tested. Minor releases in this stream also serve to clean
up any remaining bugs that are found and corrected.</Para>
<Para>The two streams use version numbers which are numbered differently to
help distinguish between them. The stable kernels are numbered with
the second number even (eg. 2.0.35, 2.0.36, 2.2.4) while the development
kernels are numbered with the second number odd (eg. 2.1.120, 2.1.121,
2.3.0).</Para>
<Para>The latest stable kernel is always made available in source as well
as pre-compiled binary formats on the <ULink
URL="ftp://ftp.redhat.com/redhat/updates/">
ftp://ftp.redhat.com/redhat/updates/</ULink> FTP site. Download the
desired kernel packages for your version and platform (for example, you
would want to navigate to the
``<Literal><Filename>/6.1/i386/</Filename></Literal>'' directory and
download the ``<Literal><Filename>kernel-*.i386.rpm</Filename></Literal>''
files for the 6.1 version on the Intel platform).</Para>
<Note><Para>Note: You do not need to download the kernel sources file unless you
are planning on building a custom kernel yourself (see <XRef
LinkEnd="kernel-custom"> for details on building a custom
kernel).</Para></Note>
<Para>Sometimes, you may find it necessary to use a kernel that has not
yet been made available as an RPM. In this case, you can find the latest
kernels from the <ULink
URL="ftp://ftp.kernel.org">ftp://ftp.kernel.org</ULink> FTP site, in the
<ULink URL="ftp://ftp.kernel.org/pub/linux/kernel/">
/pub/linux/kernel/</ULink> directory. Change to the appropriate major
version subdirectory (eg.
``<Literal><Filename>v2.0</Filename></Literal>''), which contains all
kernel releases up to the most current one. Download the desired kernel
package (for example, the compressed tarball for version 2.0.36 would be
called ``<Literal><Filename>linux-2.0.36.tar.gz</Filename></Literal>''
for the Intel platform) and untar it in the
``<Literal><Filename>/usr/src</Filename></Literal>'' directory.</Para>
<Note><Para>Note: Most user-installed applications not installed from RPM should
be untarred under the
``<Literal><Filename>/usr/local/src/</Filename></Literal>'' directory by
convention, but this is a kernel tree so we'll make an exception in this
case. :-)</Para></Note>
<Para>Please be aware that if you decide to upgrade your kernel by
downloading a tarball, you will most certainly need to configure, compile,
and install it yourself. Unless you have special needs that require the
very latest development kernel, I <Emphasis>strongly</Emphasis> recommend
you upgrade your kernel through Red Hat-provided RPM files -- these are
preconfigured and precompiled for you, although you can compile a custom
kernel from RPM files as well should you wish.</Para>
</Sect1>
<Sect1 id="kernel-upgrade"><Title>Upgrading a Red Hat Stock Kernel</Title>
<Para>By far the easiest way of upgrading your kernel is to do so using a
stock kernel RPM as provided by Red Hat. These RPM files contain
pre-compiled binary kernel code, with support for a large variety of
hardware and popular features.</Para>
<Para>Installing a stock kernel is easy to do and involves little risk.
Simply type, as root, the following sequence of commands:</Para>
<Screen>
<UserInput>rpm -Uvh kernel-2.0.36.i386.rpm</UserInput>
<UserInput>cd /boot</UserInput>
<UserInput>ls</UserInput>
</Screen>
<Para>Make note of the new kernel name, as reported by the
``<Literal>ls</Literal>'' command above. You are interested in the
``<Literal><Filename>vmlinuz</Filename></Literal>'' file; for example the
third RPM release of kernel 2.0.36 would look like
``<Literal><Filename>vmlinuz-2.0.36-3</Filename></Literal>''.</Para>
<Para>Now, use an editor to edit the LILO configuation file (type:
``<Literal>pico -w /etc/lilo.conf</Literal>'') and change the
``<Literal>image=/boot/...</Literal>'' line to point to the new kernel
file. After you have done so, type
``<Literal><Filename>/sbin/lilo</Filename></Literal>''. If LILO reports
an error message, double-check the file name in your
``<Literal><Filename>lilo.conf</Filename></Literal>'' file with the file
name in the ``<Literal><Filename>/boot/</Filename></Literal>''
directory.</Para>
<Caution><Para>Caution: Do not forget this step!</Para></Caution>
<Para>(The above commands assume you are using the Intel platform and use
LILO to boot your system. See <XRef LinkEnd="install-lilo"> for details
on the LILO boot loader).</Para>
<Para>After you have upgraded your stock kernel and have updated your boot
loader information, you should be able to shutdown and reboot using the
new kernel (see <XRef LinkEnd="system-shutdown-and-restart"> for
details on shutting down your system).</Para>
</Sect1>
<Sect1 id="kernel-custom"><Title>Building a Custom Kernel</Title>
<Para>If you are running Linux on a system with hardware or wish to use
features not supported in the stock kernels, or perhaps you wish to reduce
the kernel memory footprint to make better use of your system memory, you
may find it necessary to build your own custom kernel.</Para>
<Para>Upgrading the kernel involves configuring desired modules,
compiling the kernel and modules, and finally installing the kernel
image. This is followed by a system reboot (with fingers crossed!) to
load the new kernel. All of this is documented in the
``<Literal><Filename>README</Filename></Literal>'' file which comes with
each kernel package. Further information can be found in the
``<Literal><Filename>Documentation/</Filename></Literal>'' subdirectory.
A particularly helpful file there is
``<Literal><Filename>Configure.help</Filename></Literal>'' which contains
detailed information on the available kernel compile options and
modules.</Para>
<Para>The following is a sample session demonstrating the build of a
custom kernel, version 2.0.36 on the Intel platform. While building a
custom kernel is usually just a matter of configuring, compiling &amp;
installing, sometimes (usually in the case of new hardware) it is
necessary to download additional driver software should your hardware not
yet be supported by the kernel version you are compiling.</Para>
<Para>The first step in building a custom kernel is to download and
install the kernel sources from either RPM (preferred) or from tarball.
See <XRef LinkEnd="linux-kernel-upgrades"> for details on obtaining the
appropriate files.</Para>
<Para>Next, use the ``<Literal>rpm</Literal>'' utility (or
``<Literal>tar</Literal>'', as appropriate) to install the kernel source
tree and header files. For example, to install the 2.0.36-3 kernel RPM
files:</Para>
<Screen>
<UserInput>rpm -Uvh kernel-source-2.0.36-3.i386.rpm kernel-headers-2.0.36-3.i386.rpm</UserInput>
<UserInput>rpm -Uvh kernel-ibcs-2.0.36-3.i386.rpm</UserInput>
</Screen>
<Para>(If you are running Linux on a notebook, you would also likely
install the
``<Literal><Filename>kernel-pcmcia-cs-2.0.36-3.i386.rpm</Filename></Literal>''
file, which provides power management features.)</Para>
<Para>After installing the kernel files, you should be able to find the
new source tree in the
``<Literal><Filename>/usr/src/linux/</Filename></Literal>''
directory.</Para>
<Para>The next step is to download any additional driver files (if
applicable) and install them in the new kernel source tree. For example,
to add support for the Mylex DAC960 hardware RAID controller, I would
download the driver software from the <ULink
URL="http://www.dandelion.com/"> http://www.dandelion.com/</ULink> web
site. Unfortunately, such driver software are usually only offered as
tarballs and need to be installed using the ``<Literal>tar</Literal>''
utility. For example:</Para>
<Screen>
<UserInput>cd /usr/src/</UserInput>
<UserInput>tar zxvpf DAC960-2.0.0-Beta4.tar.gz</UserInput>
</Screen>
<Para>You should read the documentation provided with your additional
driver software, if applicable. For example, the DAC960 driver includes
a ``<Literal><Filename>README</Filename></Literal>'' file which gives
instructions on where the newly downloaded files should be located, and
how to apply the kernel patch:</Para>
<Screen>
<UserInput>mv README.DAC960 DAC960.[ch] /usr/src/linux/drivers/block</UserInput>
<UserInput>patch -p0 < DAC960.patch</UserInput>
</Screen>
<Para>The next step is to ensure your system's symbolic file links are
consistent with the new kernel tree. Actually, this step only needs to be
done once, so the following needs to be done only if you haven't compiled
a custom kernel before:</Para>
<Screen>
<Prompt>mail:/usr/src#</Prompt> <UserInput>cd /usr/include</UserInput>
<Prompt>mail:/usr/include#</Prompt> <UserInput>rm -rf asm linux scsi</UserInput>
<Prompt>mail:/usr/include#</Prompt> <UserInput>ln -s /usr/src/linux/include/asm-i386 asm</UserInput>
<Prompt>mail:/usr/include#</Prompt> <UserInput>ln -s /usr/src/linux/include/linux linux</UserInput>
<Prompt>mail:/usr/include#</Prompt> <UserInput>ln -s /usr/src/linux/include/scsi scsi</UserInput>
</Screen>
<Note><Para>Note: The above step is no longer necessary for 2.2.x or
higher kernel versions.</Para></Note>
<Para>The next step is to configure your kernel settings. This is the
most important step in building the custom kernel. If you disable the
wrong settings, you may leave out support for features or hardware you
need. However, if you <Emphasis>enable</Emphasis> the wrong settings, you
will be needlessly enlarging the kernel and wasting your valuable system
memory (that being said, it is probably better to err on the side of the
latter rather than the former).</Para>
<Para>The best way of ensuring you compile the kernel properly is to know
what features you will need to use, and what hardware is in your system
that you will require support for. After you have gained experience in
customizing your kernel a few times, the process will become <Quote>old
hat</Quote> and won't seem so intimidating!</Para>
<Para>Type the following to begin the configuration process:</Para>
<Screen>
<Prompt>mail:/usr/include#</Prompt> <UserInput>cd /usr/src/linux</UserInput>
<Prompt>mail:/usr/src/linux#</Prompt> <UserInput>make mrproper</UserInput>
<Prompt>mail:/usr/src/linux#</Prompt> <UserInput>make menuconfig</UserInput>
</Screen>
<Para>(You could type ``<Literal>make xconfig</Literal>'' instead of
``<Literal>make menuconfig</Literal>'' if you have the X Window System
running; see <XRef LinkEnd="xwindows-configuration"> for details on how
to get X working.)</Para>
<Para>To configure your kernel, go through the various settings and select
(enable) whichever ones you require, and de-select (disable) the ones you
do not require. You can choose between having such support built right
into the kernel, or having it built as a module which is loaded and
unloaded by the kernel as needed. (If you compile a feature that is
actually needed to boot your system, such as a SCSI driver, as a module,
you will need to create a RAMdisk image or your system will not boot. This
is done with the ``<Literal>mkinitrd</Literal>'' command; this procedure is
described a little further down.)</Para>
<Para>When going through the configuration settings, you can select
<Literal>&lt;Help&gt;</Literal> for a description of what a given kernel
option is for.</Para>
<Para>After you have configured your kernel settings, type the following
commands to compile your kernel:</Para>
<Screen>
<Prompt>mail:/usr/src/linux#</Prompt> <UserInput>make dep ; make clean</UserInput>
<Prompt>mail:/usr/src/linux#</Prompt> <UserInput>make bzImage</UserInput>
<Prompt>mail:/usr/src/linux#</Prompt> <UserInput>make modules</UserInput>
</Screen>
<Para>If you are <Emphasis>recompiling</Emphasis> the same kernel as you
have previously (2.0.36-3 in this example), you will likely want to move
the existing modules to a backup directory as with the following
command:</Para>
<Screen>
<Prompt>mail:/usr/src/linux#</Prompt> <UserInput>mv /lib/modules/2.0.36-3 /lib/modules/2.0.36-3-backup</UserInput>
</Screen>
<Para>Now, type the following command to actually install the new
modules:</Para>
<Screen>
<Prompt>mail:/usr/src/linux#</Prompt> <UserInput>make modules_install</UserInput>
</Screen>
<Para>The next step is to copy the kernel into the
``<Literal><Filename>/boot/</Filename></Literal>'' directory and use LILO
to update the boot record so that the new kernel is recognized. The
following commands will make a backup copy of your existing kernel, copy
the new kernel over, and then refresh the LILO boot record:</Para>
<Screen>
<Prompt>mail:/usr/src/linux#</Prompt> <UserInput>cd /boot</UserInput>
<Prompt>mail:/boot#</Prompt> <UserInput>cp vmlinuz vmlinuz.OLD</UserInput>
<Prompt>mail:/boot#</Prompt> <UserInput>cp /usr/src/linux/arch/i386/boot/bzImage vmlinuz-2.0.36</UserInput>
<Prompt>mail:/boot#</Prompt> <UserInput>/sbin/lilo</UserInput>
</Screen>
<Para>Finally, you will need to edit your
``<Literal><Filename>/etc/lilo.conf</Filename></Literal>'' file, and make
sure the <Quote>image</Quote> reference is pointing to the new kernel.
You should also add a section which points to your backup kernel, called,
perhaps, <Quote>OldLinux</Quote>. Here is an example file:</Para>
<ProgramListing>
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
image=/boot/vmlinuz
label=Linux
root=/dev/hdb1
read-only
image=/boot/vmlinuz.OLD
label=OldLinux
read-only
</ProgramListing>
<Para>By adding your backup kernel information in this way, should your
new kernel fail to boot properly (perhaps a device is not recognized, or
a daemon doesn't start as it should), you can simply type
``<Literal>OldLinux</Literal>'' to boot from the old kernel and
investigate the problem.</Para>
<Note><Para>Note: As mentioned previously, if you've compiled a feature required
to boot your system as a module, you will need to create an initial
RAMdisk image in order to boot your system. (Don't forget to compile your
kernel with support for such an initial boot image.)</Para></Note>
<Para>The procedure to create and use an initial RAMdisk image is as
follows:</Para>
<ItemizedList Mark="Bullet" Spacing="Normal">
<ListItem><Para>Add an entry in your
``<Literal><Filename>/etc/lilo.conf</Filename></Literal>'' to boot off
the initial RAMdisk image; this is shown as an addition to the example
configuration file shown earlier:</Para>
<ProgramListing>
image=/boot/vmlinuz
label=Linux
root=/dev/hdb1
initrd=/boot/initrd-2.2.4-4.img
read-only
</ProgramListing>
</ListItem>
<ListItem><Para>The loopback device needs to be loaded before you are able
to use the mkinitrd command. Make sure the loopback device module is
loaded:</Para>
<Screen>
<UserInput>/sbin/insmod loop</UserInput>
</Screen>
<Para>(If you get an error message about not being able to load the
loopback module, you may need to specify the full path to the module for
the <Emphasis>current</Emphasis> kernel your system is still running on,
for example
``<Literal><Filename>/lib/modules/2.0.35/loop</Filename></Literal>''.)</Para></ListItem>
<ListItem><Para>Use the ``<Literal>mkinitrd</Literal>'' command to
actually create the image:</Para>
<Screen>
<UserInput>/sbin/mkinitrd /boot/initrd-2.0.36-3.img 2.0.36-3</UserInput>
</Screen>
</ListItem>
<ListItem><Para>Run ``<Literal>/sbin/lilo</Literal>'' to update your boot
loader.</Para></ListItem>
</ItemizedList>
<Para>Now, shut down your system and boot the new kernel!</Para>
<Screen>
<Prompt>mail:/boot#</Prompt> <UserInput>/sbin/shutdown -r now</UserInput>
</Screen>
<Para>If your kernel refuses to boot altogether, don't panic. Boot off the boot
disk that was created during the installation of Linux . If you don't
have copies of this disks, you should be able to create one from the Red
Hat CD. Insert the boot diskette into the drive and reboot the computer.
When you see the <Quote>boot:</Quote> prompt, type:</Para>
<Screen>
<UserInput>mount root=/dev/hda1</UserInput>
</Screen>
<Para>The above command assumes your <Quote>/</Quote> (root) partition is
located on /dev/hda1.</Para>
<Para>Linux should then boot normally (although since you are using the
kernel from the boot disk, not all services or devices may operate
properly for this session), and then you can restore your old kernel and
reinstall the LILO boot loader information (ie. ``<Literal>mv /vmlinuz.old
/vmlinuz ; /sbin/lilo</Literal>'') and shutdown/restart. You can then try
recompiling the kernel with different options and try again.</Para>
</Sect1>
<Sect1 id="linux-2.2.x"><Title>Moving to the Linux 2.2.x Kernels</Title>
<Para>The Linux kernel 2.2.0 was released on January 25, 1999, bringing
with it many new features, performance enhancements, and hardware support.
Any existing Linux system can be upgraded with one of these new kernels in
much the same fashion as described in <XRef
LinkEnd="linux-kernel-upgrades"> (with caveats).</Para>
<Para>This section will describe how to upgrade your Red Hat system to the
new kernels. As Red Hat 6.0 (and above) already ships with the new kernel and
supporting packages by default, this section will only be useful to those
of you who are still using an earlier version, such as 5.2. I will likely
remove this section from future versions of this document, once I believe a
majority of users have migrated to 6.0 and beyond.</Para>
<Warning><Para>Warning! If you decide to upgrade your older system to
support the new kernels, be advised that as the process involves a number
of package upgrades, it is possible that something will go horribly wrong.
As always, have recent backups available to you in case something goes
wrong. If you don't have experience with upgrading files with RPM as well
as compiling kernels, perhaps you might wish to upgrade to Red Hat
6.1.</Para></Warning>
<Para>You have the choice of upgrading to either a stock kernel as provided
by Red Hat, or upgrading by compiling a custom kernel. I would recommend
getting things going with a stock kernel first, and then build a customized
kernel later as you normally would (see <XRef LinkEnd="kernel-upgrade"> for
details.)</Para>
<Para>In order to use the latest kernel, it is first necessary to upgrade
to the newest utilities and libraries. Red Hat has identified which
packages need to be upgraded to support the newest kernel, and have placed
the appropriate RPM files on their FTP site at <ULink
URL="ftp://ftp.redhat.com/redhat/updates/5.2/kernel-2.2/i386/">
ftp://ftp.redhat.com/redhat/updates/5.2/kernel-2.2/i386/</ULink> (for Red Hat
5.2 users on the i386 platform).</Para>
<Para>A very good web page, detailing the appropriate system tools that
are necessary for moving to 2.2.x is available at <ULink
URL="http://www-stu.calvin.edu/~clug/users/jnieho38/goto22.html">
http://www-stu.calvin.edu/~clug/users/jnieho38/goto22.html</ULink>; I will
attempt to summarize the information below (items marked with a leading
``&sext;'' indicate you will most likely need to
upgrade the item for Red Hat 5.2; items not indicated as such are
<Emphasis>probably</Emphasis> okay but probably worth checking).</Para>
<ItemizedList Mark="Bullet" Spacing="Compact">
<ListItem><para>&sext; <Emphasis>initscripts-3.78-2.4 or
better</Emphasis> (Type ``<Literal>rpm -q initscripts</Literal>'' to check
your version)</Para></ListItem>
<ListItem><Para>&sext; <Emphasis>modutils-2.1.121 or
better</Emphasis> (Type ``<Literal>rpm -q modutils</Literal>'' to check your
version)</Para></ListItem>
<ListItem><Para>&sext; <Emphasis>mount-2.9-0 or better</Emphasis>
(Type ``<Literal>rpm -q mount</Literal>'' to check your
version)</Para></ListItem>
<ListItem><Para><Emphasis>gcc-2.7.2.3 or better</Emphasis>
(``<Literal>rpm -q gcc</Literal>'')</Para></ListItem>
<ListItem><Para><Emphasis>binutils-2.8.1.0.23 or better</Emphasis>
(``<Literal>rpm -q binutils</Literal>'')</Para></ListItem>
<ListItem><Para><Emphasis>libc-5.4.46 or better</Emphasis> (Red Hat uses
the newer ``<Emphasis>glibc</Emphasis>''. Not needed.)</Para></ListItem>
<ListItem><Para><Emphasis>glibc-2.0.7-6 or better</Emphasis> (``<Literal>rpm -q
glibc</Literal>'')</Para></ListItem>
<ListItem><Para><Emphasis>ld.so 1.9.9 or better</Emphasis> (``<Literal>ls -l
/lib/ld.so.*</Literal>'')</Para></ListItem>
<ListItem><Para><Emphasis>libg++-2.7.2.8 or better</Emphasis> (``<Literal>rpm
-q libg++</Literal>'')</Para></ListItem>
<ListItem><Para><Emphasis>procps-1.2.9 or better</Emphasis> (``<Literal>rpm -q
procps</Literal>'')</Para></ListItem>
<ListItem><Para>&sext; <Emphasis>procinfo-15 or better</Emphasis>
(``<Literal>rpm -q procinfo</Literal>'')</Para></ListItem>
<ListItem><Para><Emphasis>psmisc-17 or better</Emphasis> (``<Literal>rpm -q
psmisc</Literal>'')</Para></ListItem>
<ListItem><Para>&sext; <Emphasis>net-tools-1.50 or
better</Emphasis> (``<Literal>rpm -q net-tools</Literal>'')</Para></ListItem>
<ListItem><Para><Emphasis>loadlin-1.6 or better</Emphasis> (Needed only if
you are booting Linux from DOS using Loadlin. Not sure how to calculate
the version number; download the latest version to be
sure.)</Para></ListItem>
<ListItem><Para><Emphasis>sh-utils-1.16 or better</Emphasis> (``<Literal>rpm -q
sh-utils</Literal>'')</Para></ListItem>
<ListItem><Para><Emphasis>autofs-3.1.1 or better</Emphasis> (``<Literal>rpm -q
autofs</Literal>'')</Para></ListItem>
<ListItem><Para><Emphasis>nfs-server2.2beta37 or better</Emphasis>
(``<Literal>rpm -q nfs-server</Literal>''; needed only if you are serving
NFS file shares.)</Para></ListItem>
<ListItem><Para><Emphasis>bash-1.14.7 or better</Emphasis> (``<Literal>rpm -q
bash</Literal>'')</Para></ListItem>
<ListItem><Para><Emphasis>ncpfs-2.2.0 or better</Emphasis> (``<Literal>rpm -q
ncpfs</Literal>''; needed only if you are mounting Novell file
systems.)</Para></ListItem>
<ListItem><Para><Emphasis>kernel-pcmcia-cs-3.0.6 or better</Emphasis>
(``<Literal>rpm -q kernel-pcmcia-cs</Literal>''; needed only for laptops
which need PCMCIA card support.)</Para></ListItem>
<ListItem><Para><Emphasis>ppp-2.3.5 or better</Emphasis> (``<Literal>rpm
-q ppp</Literal>''; needed only if you are connecting to the Internet
with a modem and PPP.)</Para></ListItem>
<ListItem><Para><Emphasis>dhcpcd-1.3.16-0 or better</Emphasis>
(``<Literal>rpm -q dhcpcd</Literal>''; needed only if you need a DHCP
client to connect to the Internet, such as with a cable
modem).</Para></ListItem>
<ListItem><Para>&sext; <Emphasis>util-linux-2.9.0</Emphasis>
(``<Literal>rpm -q util-linux</Literal>'')</Para></ListItem>
<ListItem><Para><Emphasis>setserial-2.1 or better</Emphasis>
(``<Literal>rpm -q setserial</Literal>'')</Para></ListItem>
<ListItem><Para><Emphasis>ipfwadmin/ipchains</Emphasis> (Only needed if
you are doing IP firewalling; see the
``<Emphasis>IPCHAINS-HOWTO</Emphasis>'' guide at <ULink
URL="http://isunix.it.iltu.edu/resources/ldp/HOWTO/IPCHAINS-HOWTO.html">
http://isunix.it.iltu.edu/resources/ldp/HOWTO/IPCHAINS-HOWTO.html</ULink>.)</Para></ListItem>
</ItemizedList>
<Para>You should download and upgrade any packages using RPM as required
(see <XRef LinkEnd="using-rpm"> for details on how to use RPM).</Para>
<Caution><Para>Caution: Upgrading to the new ``<Literal>modutils</Literal>''
package will result in modules no longer functioning for the older 2.0.x
kernels! Therefore, do not upgrade this package until you have installed
the new kernel in
``<Literal><Filename>/usr/src/linux</Filename></Literal>''.</Para></Caution>
<Para>After bringing your system's tools up to date, you can install the
kernel sources. You can find them on Red Hat's FTP site as well; I
recommend downloading the ones provided as updates for Red Hat 6.1, at
<ULink URL="ftp://ftp.redhat.com/redhat/updates/6.1/i386/">
ftp://ftp.redhat.com/redhat/updates/6.1/i386/</ULink>. To do so, type the
following:</Para>
<Screen>
<UserInput>rpm -Uvh kernel-source*.rpm kernel-headers*.rpm</UserInput>
</Screen>
<Para>Now that the new kernel sources have been installed, it should be
safe to upgrade your modutils package. However, the new kernel no longer
uses the ``<Literal>kerneld</Literal>'' module for on-demand loading of
kernel modules. Therefore, you should disable this module before updating
modutils. To disable kerneld and upgrade the modutils package, type the
following as <Quote>root</Quote>:</Para>
<Screen>
<UserInput>/sbin/chkconfig kerneld off</UserInput>
<UserInput>/etc/rc.d/init.d/kerneld stop</UserInput>
<UserInput>rpm -Uvh modutils*.rpm</UserInput>
</Screen>
<Para>You should now be able to configure, compile, and install your 2.2
kernel as you normally would (see <XRef LinkEnd="kernel-custom"> for
details). You may be surprised to see the dizzying amount of new
configuration settings available. Take your time and read the help text
for any options you are unfamiliar with!</Para>
<Para>With any luck, the next time you boot your system you will be
running the latest and greatest Linux kernel version!</Para>
<Para>Much more detailed information on these procedures can be found on Red
Hat's web site at
<ULink URL="http://www.redhat.com/corp/support/docs/kernel-2.2/kernel2.2-upgrade.html">
http://www.redhat.com/corp/support/docs/kernel-2.2/kernel2.2-upgrade.html</ULink>.</Para>
</Sect1>
<Sect1 id="apache-config"><Title>Configuring the Apache Web Server</Title>
<Para>At my place of employment, we are using the Apache package to
provide web services. Apache is a full-featured web server with full
support for the HTTP 1.1 standard, proxy caching, password authenticated
web pages, and many other features. Apache is one of the most popular
web servers available (according to a recent site survey done by
Netcraft, more than 54% of all web sites on the Internet are using Apache
or one of its derivatives), and provides performance equal or better to
commercial servers.</Para>
<Para>( Under construction. :-p )</Para>
<Para>To keep up with added features and bug-fixes that are made to Apache, it
is a probably a good idea to upgrade your server from time to time. The
Apache web site is located at <ULink URL="http://www.apache.org/">
http://www.apache.org/</ULink> and contains information on the latest
versions.</Para>
</Sect1>
<Sect1 id="squid-upgrades"><Title>Configuring the Squid HTTP Caching Proxy Daemon</Title>
<Para>At my place of employment, we use the Squid package to provide proxy
caching of web pages. Squid offers high-performance caching of web
clients, and also supports FTP, Gopher, and HTTP requests. In addition,
Squid can be hierarchically linked to other Squid-based proxy servers for
streamlined caching of pages.</Para>
<Para>There are two versions of Squid currently available. One, the
<Quote>regular</Quote> version, seems to work well on machines with lots
of RAM. The second version, <Quote><Emphasis>SquidNOVM</Emphasis></Quote>
is suitable for machines with less RAM (I recommend using this version if
you have 64 MB of RAM or less). Basically, the <Quote>NOVM</Quote> version
uses less memory at the expense of more file descriptors. It's the one I
use, and it works well.</Para>
<Para>( Under construction :-p )</Para>
<Para>To keep up with new features and bug-fixes, it is a probably a good
idea to upgrade the Squid server from time to time. More information on
Squid can be found on web site at <ULink URL="http://squid.nlanr.net/Squid/">
http://squid.nlanr.net/Squid/</ULink>.</Para>
</Sect1>
<Sect1 id="sendmail-upgrades"><Title>Configuring the Sendmail E-mail Daemon</Title>
<Para>I use the Sendmail package to provide e-mail services. Sendmail is
<Emphasis>the</Emphasis> definitive mail handler; in fact it is so popular
that it is estimated that over 80% of e-mail passing over the Internet
will be handled at one or both ends by it. It does just about anything
and I couldn't imagine running an Internet server without it (another
e-mail server package called Qmail seems to be quite popular as well --
but I haven't had a reason yet to give it a try).</Para>
<Para>To keep up with new features and bug-fixes, and most importantly,
for reasons of security, it is a probably a good idea to upgrade Sendmail
from time to time. In addition, the very latest versions of Sendmail
include powerful anti-spam features which can help prevent your mail
server being abused by unauthorized users.</Para>
<Para>This section will discuss some of the things you should do if you
wish to use Sendmail as an incoming e-mail server. This would be the
likely scenario for server systems. If, instead, you have no need to use
it for incoming mail and wish to only use it as an outgoing mail queue,
you should ((need some info here)).</Para>
<Para>For this section, it is assumed that you are using the very latest
version of Sendmail (8.9.3 at the time of this writing), have it installed
and running.</Para>
<Para>As packaged with the Red Hat distribution, Sendmail usually
contains appropriate configuration information to operate correctly in
the majority of server setups. Nonetheless, you may find it necessary to
edit the ``<Literal><Filename>/etc/sendmail.cf</Filename></Literal>''
file and customize some settings as required. This, however, is beyond
the scope of this document.</Para>
<Para>One thing I find helpful, however, is to make a couple of changes to
the configuration file to thwart off spammers. These include:</Para>
<ProgramListing>
<emphasis>O PrivacyOptions=authwarnings</emphasis>
<Emphasis>change to:</Emphasis>
O PrivacyOptions=authwarnings,noexpn,novrfy
<emphasis>O SmtpGreetingMessage=$j Sendmail $v/$Z; $b</emphasis>
<Emphasis>change to:</Emphasis>
O SmtpGreetingMessage=$j Sendmail $v/$Z; $b NO UCE C=xx L=xx
</ProgramListing>
<Para>(The first change prevents spammers from using the
``<Literal>EXPN</Literal>'' and ``<Literal>VRFY</Literal>'' commands in
sendmail. I find that these commands are too often abused by unethical
individuals. The second change modifies the banner which Sendmail
displays upon receiving a connection. You should replace the
``<Emphasis>xx</Emphasis>'' in the ``<Literal>C=xx L=xx</Literal>''
entries with your country and location codes. For example, in my case, I
would use ``<Literal>C=CA L=ON</Literal>'' for Ontario, Canada. (The
latter change doesn't actually affect anything, but was recommended by
folks in the <ULink URL="news:news.admin.net-abuse.email">
news.admin.net-abuse.email</ULink> newsgroup as a legal
precaution.</Para>
<Para>Next, if your mail server will have a different host name than the
actual machine it is running on, you can add one or more aliases in the
``<Literal><Filename>/etc/sendmail.cw</Filename></Literal>'' file. For
example, if you have a system called
<Quote><Emphasis>kirk.mydomain.name</Emphasis></Quote> which is set up as
the mail exchanger for mydomain.name, but want incoming mail addressed in
the format ``<Emphasis>user@mydomain.name</Emphasis>'' to be delivered to
your users on <Quote><Emphasis>kirk</Emphasis></Quote>, simply add this
alias as follows:</Para>
<ProgramListing>
mydomain.name
</ProgramListing>
<Para>Finally, If you need to restrict a domain (or subdomain) from
connecting to your sendmail service, you can edit the
``<Literal><Filename>/etc/mail/access</Filename></Literal>'' and add the
domain information as well as type of restriction. For example:</Para>
<ProgramListing>
some.domain REJECT
hax0r.another.domain 550 Contact site administrator at (555) 555-1234.
</ProgramListing>
<Para>The above examples would reject all e-mail connections from the
``<Emphasis>some.domain</Emphasis>'' site, as well as reject the specific
machine name ``<Emphasis>hax0r.another.domain</Emphasis>'' with a
descriptive message.</Para>
<Para>After making changes to this file, you will need to update the
``<Literal><Filename>access.db</Filename></Literal>'' file, and then
restart sendmail as follows:</Para>
<Screen>
<UserInput>/usr/sbin/makemap hash /etc/mail/access.db < /etc/mail/access</UserInput>
<UserInput>/etc/rc.d/init.d/sendmail restart</UserInput>
</Screen>
<Tip><Para>Tip: If you are concerned with e-mail abuse, you can get some
very helpful information from the <Quote>Mail Abuse Prevention
System</Quote> (<Acronym>MAPS</Acronym>) project on dealing with such
abuse; see the web pages at <ULink
URL="http://www.mail-abuse.org/">http://www.mail-abuse.org/</ULink></Para>
<Para>If you're using Sendmail version 8.9 or above, RBL support is
already built in, but not enabled by default. To enable this support, add
the following to your sendmail.mc file:</Para>
<ProgramListing>
FEATURE(rbl)
</ProgramListing>
<Para>Then, reconfigure and restart the Sendmail daemon.</Para>
<Para>For more detailed information, including configuration instructions
for other mail transport agents, see <ULink
URL="http://www.mail-abuse.org/rbl/usage.html">
http://www.mail-abuse.org/rbl/usage.html</ULink>.</Para>
<Para>Sometimes, a domain may end up in the RBL list with which you wish
to continue communications with. Perhaps it is vital for you to
communicate with certain users at the black-listed domain. In this case,
Sendmail allows you to override these domains to allow their e-mail to be
received. Simply edit the
``<Literal><Filename>/etc/mail/access</Filename></Literal>'' file in the
manner described above with the appropriate domain information. For
example:</Para>
<ProgramListing>
blacklisted.domain OK
</ProgramListing>
<Para>Don't forget to rebuild your access.db file (described above)!</Para>
<Para>If you do decide to subscribe to the RBL, it is probably a wise idea
to inform your mail users, if applicable, so they can make other service
arrangements if they disagree with your decision.</Para></Tip>
<Para>For more information on Sendmail, see the FAQ document located at
<ULink URL="http://www.sendmail.org/faq/">
http://www.sendmail.org/faq/</ULink>.</Para>
</Sect1>
</Chapter>
<Chapter id="enterprise-computing"><Title>Enterprise Computing with Linux</Title>
<Para>As Linux has earned a solid reputation for its stability and
reliability, it is being used for more mission critical applications in
the corporate and scientific world.</Para>
<Para>This chapter will discuss issues which are most relevant to those
using Linux in the enterprise, such as tuning your server for better
performance under higher loads, keeping your data safe with RAID
technologies, as well as discuss the general procedures to migrate across
servers.</Para>
<Sect1 id="performance-tuning"><Title>Performance Tuning</Title>
<Para><Emphasis>( Under construction. :-p )</Emphasis></Para>
</Sect1>
<Sect1 id="hardware-raid"><Title>High Availability with RAID</Title>
<Para>As storage needs increase, it sometimes becomes necessary to put
additional drives with larger capacities online. Yet ironically, the law
of probability dictates that as the number of storage devices increases,
so too does the likelihood of a device failure. Therefore, a system with
a single hard drive is only 25% as likely to suffer a hardware failure as
a system with four drives. [ Well, theoretically speaking, anyway :-) ]</Para>
<Para>Fortunately, such failures can be handled gracefully, and more
importantly without downtime, using a technique called <Quote>Redundant
Array of Inexpensive Disks</Quote> (<Emphasis>RAID</Emphasis>) which uses
one of several methods of distributing data over multiple disks. This
redundancy allows for automatic recovery of data should a device
fail.</Para>
<Para>This section will describe the installation, configuration, and
setup of a RAID disk array using the Mylex AcceleRAID DAC960 controller.
I have been very impressed with not only the performance and reliability
of the controller itself, but also with the technical support I've gotten
from Mylex -- they are very Linux-friendly! (However, there are a wide
variety of hardware RAID solutions for Linux, and RAID can be implemented
in software by the Linux kernel itself.) The type of RAID implementation
that is most useful is probably RAID level 5.</Para>
<Para>The first step in getting the RAID controller usable under Linux is to
build a custom kernel with driver support for the hardware. The driver
for the Mylex DAC960 can be downloaded from the Dandelion Digital Linux
page at <ULink URL="http://www.dandelion.com/Linux/DAC960-2.0.tar.gz">
http://www.dandelion.com/Linux/DAC960-2.0.tar.gz</ULink>.</Para>
<Para>The final step in getting your RAID array usable under Linux is to
use the ``<Literal>fdisk</Literal>'' utility to create valid partitions.
This is done in exactly the same manner as you would use on an IDE or
regular SCSI drive. See <XRef LinkEnd="install-partitioning"> for
details on how to set up partition information.</Para>
<Note><Para>Note: The DAC960 driver supports a maximum of 7 partitions per
logical drive. If you need to define more, you will need to define
multiple logical drives in the RAID configuration utility (press
<Literal>&lt;<KeyCap>Alt</KeyCap>&gt;-&lt;<KeyCap>R</KeyCap>&gt;</Literal>
at system boot time to enter the setup utility).</Para></Note>
<Para>Once you are able to see your RAID array, you should initialize any
swap areas and file systems you wish to define. The following is an
example of initializing a swap area on the third partition of the second
drive, as well as an ext2-formatted file system on the first partition of
the first drive:</Para>
<Screen>
<UserInput>/sbin/mkswap -c /dev/rd/c0d1p3</UserInput>
<UserInput>/sbin/swapon /dev/rd/c0d1p3</UserInput>
<UserInput>/sbin/mkfs.ext2 -c /dev/rd/c0d0p1</UserInput>
</Screen>
<Note><Para>Note: The ``<Literal>-c</Literal>'' option in the above
``<Literal>mkswap</Literal>'' and ``<Literal>mkfs.ext2</Literal>''
commands enable bad-block checking as the appropriate swap/file systems
are created. This adds <Emphasis>substantially</Emphasis> to the time it
takes to complete the process, but it is probably a very good idea to
perform such checks.</Para></Note>
<Para>For any new swap areas you have defined, you should make an entry
in the ``<Literal>/etc/fstab</Literal>'' file to ensure the swap area is
actually used from subsequent bootups. As per the above example, the
following line should be added:</Para>
<ProgramListing>
/dev/rd/c0d1p3 swap swap defaults 0 0
</ProgramListing>
<Para>Finally, once your file systems have been initialized, you can
create mount points there and move your large file systems onto the array
as you desire. It is probably a good idea to test the array for a few
days before using it in a production environment.</Para>
<Para>For further information on the Mylex AcceleRAID controller, visit
the Mylex web site at <ULink URL="http://www.mylex.com/">
http://www.mylex.com/</ULink> as well as the Dandelion Digital DAC960
driver page at <ULink URL="http://www.dandelion.com/Linux/DAC960.html">
http://www.dandelion.com/Linux/DAC960.html</ULink>. For further
information on RAID in general (including both software- as well as
hardware-based solutions), see the Linux High Availability web site at
<ULink URL="http://linas.org/linux/raid.html">
http://linas.org/linux/raid.html</ULink>.</Para>
</Sect1>
<Sect1 id="server-migration"><Title>Server Migration and Scalability Issues</Title>
<Para>With support for a diverse selection of hardware, as well as proven
speed and reliability, Linux is up to the challenge of scaling up to meet
resource demands as they increase. This can include moving to an SMP
(<Emphasis>Symmetric Multi Processing</Emphasis>) configuration for
greater processing needs, RAID levels 0 through 5 (either in software or
hardware driven modes), etc.</Para>
<Para>On occasion, you may feel that your Linux server has outgrown the
hardware it is running on, perform a major Linux version upgrade, or
perhaps move to a different distribution of Linux. There are, of course,
two ways of doing this. Either you will be leaving your server on
existing or upgraded hardware (in which case you need simply shut down
services, back up your data, perform the required modifications, and then
restore data if needed), or in the more radical case, migrate your server
to new hardware.</Para>
<Para>This section will concentrate more on the latter situation, where
you will be actually migrating your various services from the old server
to a new one. There are, of course, several migration strategies, however
this section will attempt to provide some rough guidelines which you can
follow in order to ensure your migration effort succeeds with minimal
disruption to your users.</Para>
<ItemizedList Mark="Bullet" Spacing="Normal"> <ListItem><Para>Prepare your
new server as necessary; install and configure Linux so that your new
hardware devices are supported, and any required daemons and kernel-based
features (such as firewalling) are enabled. See <XRef
LinkEnd="install-config">, as well as <XRef LinkEnd="kernel-custom"> for
details.</Para></ListItem>
<ListItem><Para>Set up your existing services (such as the Apache web
server, Samba or Netatalk file &amp; print services, etc.) and make use
of them with test data for at least several days to ensure everything is
working as desired. See <XRef LinkEnd="samba-file-and-print">, as well
as <XRef LinkEnd="netatalk-file-and-print"> for details. Don't forget to
ensure that any changes or custom scripts you have made in the
``<Literal><Filename>/etc/</Filename></Literal>'' directory, including
anything in ``<Literal><Filename>/etc/rc.d/</Filename></Literal>'' have
also been done on the new server as required. It is especially important
that you remember to move over your user account information in the
``<Literal><Filename>/etc/passwd</Filename></Literal>'',
``<Literal><Filename>/etc/group</Filename></Literal>'', and, if you are
using shadow passwords,
``<Literal><Filename>/etc/shadow</Filename></Literal>''!</Para></ListItem>
<ListItem><Para>Shut down services on your old server, so that your file
systems will see a minimal amount of file update activity. Obviously you
don't want users uploading web pages and receiving e-mail on the old
server, while you are restoring the data onto the new one! As root, you
can shut down most services with the following command:</Para>
<Screen>
<UserInput>killall httpd atalkd smbd nmbd squid sendmail ftpd</UserInput>
</Screen>
<Para>The above command will shut down the web server, file &amp; print
services, e-mail server, and FTP service. (You may be running less or
more services than the ones I have listed above. Check your process list
and terminate any other service you feel appropriate; see <XRef
LinkEnd="managing-processes"> for details.)</Para>
<Para>You might also want to edit the
``<Literal><Filename>/etc/inetd.conf</Filename></Literal>'' file on your
old server, and with the ``<Literal>#</Literal>'' character, comment out
any services (such as FTP, IMAP, and POP3 services) which might result in
file system updates. Then, again as root, type:</Para>
<Screen>
<UserInput>killall -HUP inetd</UserInput>
</Screen>
<Para>The above command will reload the TCP wrappers (security wrappers
to Internet services) so that future connections to any services you have
disabled in the
``<Literal><Filename>/etc/inet.conf</Filename></Literal>'' file will not
be loaded).</Para></ListItem>
<ListItem><Para>Now you should be able to move over the data from one
system to another. Likely, you will have prepared your new server to
have everything it needs to function, including any additional software
that you wish to install that did not come with your Red Hat
distribution. Therefore, you will likely need to backup any data stored
in ``<Literal><Filename>/home</Filename></Literal>'',
``<Literal><Filename>/var/spool</Filename></Literal>'', as well as
optional file systems, such as
``<Literal><Filename>/archive</Filename></Literal>'', if applicable.
Here is an example command that uses the ``<Literal>tar</Literal>''
utility to make a compressed backup file of data:</Para>
<Screen>
<UserInput>cd /</UserInput>
<UserInput>tar zcvpf /tmp/backup_data.tar.gz --exclude=var/spool/squid \
home archive var/spool</UserInput>
</Screen>
<Para>The above command will write a backup of your
``<Literal><Filename>/archive</Filename></Literal>'',
``<Literal><Filename>/home</Filename></Literal>'', and
``<Literal><Filename>/var/spool</Filename></Literal>'' file systems (or
subdirectories, depending on how you have set up your system), to a file
called
``<Literal><Filename>/tmp/backup_data.tar.gz</Filename></Literal>'' in
compressed tar format. Make sure you have enough space to create the
backup, or write it elsewhere!</Para>
<Tip><Para>Tip: You can use the ``<Literal>du</Literal>'' utility to help
determine required space. For example, to determine the requirements of
the ``<Literal><Filename>/archive/</Filename></Literal>'' and
``<Literal><Filename>/home/</Filename></Literal>'' directory trees,
type:</Para>
<Screen>
<UserInput>du -h -s /archive /home</UserInput>
</Screen>
<Para>Bear in mind that the above command will report the actual size of
your data, but if you are using tar's ``<Literal>z</Literal>'' option (as
above) to compress the image file, your usage requirements will likely be
significantly less. Consider the output from the ``<Literal>du</Literal>''
command a worst-case estimate of the space required.</Para></Tip>
</ListItem>
<ListItem><Para>Now, you can restore the backup data from the tar file
onto the new server. You can restore it directly over NFS (see <XRef
LinkEnd="nfs-services"> for details on how to configure NFS), or simply
use FTP to transfer it over and untar it locally. Here is an example that
will restore the files that were backed up as above:</Para>
<Screen>
<UserInput>cd /</UserInput>
<UserInput>tar zxvpf /tmp/backup_data.tar.gz</UserInput>
</Screen>
</ListItem>
<ListItem><Para>Next, if necessary, swap your IP addresses so that your
new server is seen on the old address.</Para></ListItem>
<ListItem><Para>Finally, you may wish to shutdown and restart your server
to ensure there are no unexpected error messages that appear. See <XRef
LinkEnd="system-shutdown-and-restart"> for details.</Para></ListItem>
</ItemizedList>
<Para>Once you are done, make sure everything is working as expected!
If not, you can always re-enable any services you disabled on the old
server and restart them so that users can continue using it until you
resolve the problems on the new one (bear in mind, however, that you'll
need to repeat the above steps again if you choose to do that).</Para>
</Sect1>
</Chapter>
<Chapter id="security"><Title>Strategies for Keeping a Secure Server</Title>
<Para>Linux can certainly be considered to be as secure -- or more secure
-- than operating systems from other vendors. Admittedly, with Linux
becoming more and more popular, it is becoming a very attractive target
for crackers to concentrate their break-in efforts on. There are exploits
that are discovered from time to time, however the open nature of Linux
usually means that such exploits are patched quickly, and security
announcements are disseminated widely, containing either temporary
workarounds or pointers to updated software.</Para>
<Para>I won't pretend to be an expert on security issues, however I am at
least aware of these issues, which I believe to be a large part of the
battle towards making one's systems as secure as possible. Although being
aware and diligent in keeping up with security updates will in no way
guarantee that a system's security measures won't be circumvented, the
likelihood of a break-in is greatly reduced.</Para>
<Para>Although there have been security exploits found in external
services which could have been used by crackers to break into a system
(for example, the IMAP daemon exploit), I believe that it is far more
likely that a determined cracker will penetrate the system from
<Emphasis>within</Emphasis>. Compared to the handful of services
communicating with the outside world, there are
<Emphasis>thousands</Emphasis> of commands and utilities available from
the shell, one or more of which may contain bugs which can be exploited to
penetrate security (that being said, I must admit to recently discovering
one of the servers I maintain had been compromised through an external
service).</Para>
<Para>For this reason, I recommend avoiding giving out shell accounts to
users unless they are absolutely necessary. Even if you consider your
users completely trustworthy and have no qualms in providing them with
access to the shell, all it takes is just one of these users to have a
weak password. An outside cracker, finding its way into your system by
exploiting this weak password, will then be able to work at his or her
leisure internally, looking for further weaknesses.</Para>
<Para>There are, fortunately, things you can do to greatly increase the
security of your Linux system. While a detailed discussion of security
issues is beyond the scope of this document, the following checklist
provides some of the most important things you should do to enhance
security:</Para>
<ItemizedList Mark="Bullet" Spacing="Normal">
<ListItem><Para><emphasis>Upgrade system tools, applications, and kernel:</emphasis>
By far the most common cause of system break-ins is by not exercising
diligence in keeping an up-to-date server. Performing regular upgrades of
the system kernel, tools and utilities will ensure that your system is not
filled with older items for which known exploits are available. For
details on keeping an up-to-date server, see <XRef
LinkEnd="update-redhat">, as well as <XRef
LinkEnd="keeping-up-to-date">.</Para></ListItem>
<ListItem><Para><emphasis>Shadow passwords:</emphasis> You should definitely be using
Shadow passwords; switching to this password format is
<Emphasis>easy</Emphasis>! For details, see <XRef
LinkEnd="shadow-file-formats">.</Para></ListItem>
<ListItem><Para><emphasis>Smart password management:</emphasis> Make sure passwords,
<Emphasis>especially</Emphasis> for users you are providing with shell
access, are strong and changed often. Also, if you use multiple servers,
resist the temptation to use the same password for all of them (otherwise,
if a cracker breaks into one server using a discovered password, he or she
can break into them all).</Para></ListItem>
<ListItem><Para><emphasis>Use secure shell (ssh):</emphasis> Switch to using ``ssh''
instead of ``telnet''. Telnet is insecure for two reasons: One, sessions
are unencrypted, which means everything, including username and passwords,
are transmitted as clear text. Second, an open telnet port is one of the
first places a cracker will try to connect to.</Para>
<Para>Ssh provides encrypted and compressed connections and provide
substantially more security than telnet connections. You can run a ssh
server (which allows incoming secure connections) as well as a client (for
outgoing secure connections) under Linux. You can find binary RPM
packages at <ULink URL="ftp://ftp.replay.com/pub/replay/redhat/i386/">
ftp://ftp.replay.com/pub/replay/redhat/i386/</ULink>. You will need the
following files (newer versions may be available by the time you read
this):</Para>
<ItemizedList Mark="Bullet" Spacing="Compact">
<ListItem><Para><ULink URL="ftp://ftp.replay.com/pub/replay/redhat/i386/ssh-1.2.27-5i.i386.rpm">
ssh-1.2.27-5i.i386.rpm</ULink> The base package.</Para></ListItem>
<ListItem><Para><ULink URL="ftp://ftp.replay.com/pub/replay/redhat/i386/ssh-clients-1.2.27-5i.i386.rpm">
ssh-clients-1.2.27-5i.i386.rpm</ULink> Clients for outgoing connections.</Para></ListItem>
<ListItem><Para><ULink URL="ftp://ftp.replay.com/pub/replay/redhat/i386/ssh-extras-1.2.27-5i.i386.rpm">
ssh-extras-1.2.27-5i.i386.rpm</ULink> Some handy perl-based scripts.</Para></ListItem>
<ListItem><Para><ULink URL="ftp://ftp.replay.com/pub/replay/redhat/i386/ssh-server-1.2.27-5i.i386.rpm">
ssh-server-1.2.27-5i.i386.rpm</ULink> Server for incoming connections.</Para></ListItem>
</ItemizedList>
<Note><Para>Note: The SSH RPM files listed above are the international
versions. If you reside in the U.S. or Canada, you can choose to download
the U.S. packages (which may have stronger encryption algorithms); these
packages have a ``us'' instead of an ``i'' suffix after their version
numbers. Under U.S. law, it is <Emphasis>illegal</Emphasis> to export
strong crypto products outside of the U.S. or Canada. Hopefully one day
the morons in the U.S. Department of Justice will finally see the light,
and remove this silly restriction (Red Hat doesn't include SSH with their
distribution because of this very reason, and we <Emphasis>all</Emphasis>
suffer).</Para></Note>
<Para>Should your Windows users be up-in-arms about no longer being able
to connect to your system, they will be happy to know that several free
ssh clients for Windows are available:</Para>
<VariableList>
<VarListEntry>
<Term><Quote>TeraTerm Pro</Quote> client software</Term>
<ListItem><Para><ULink URL="http://hp.vector.co.jp/authors/VA002416/teraterm.html">
http://hp.vector.co.jp/authors/VA002416/teraterm.html</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term><Quote>TTSSH</Quote> client software</Term>
<ListItem><Para><ULink URL="http://www.zip.com.au/~roca/download.html">
http://www.zip.com.au/~roca/download.html</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term><Quote>Cryptlib</Quote> client software</Term>
<ListItem><Para><ULink URL="http://www.doc.ic.ac.uk/~ci2/ssh">
http://www.doc.ic.ac.uk/~ci2/ssh</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term><Quote>Putty</Quote> client software</Term>
<ListItem><Para><ULink URL="http://www.chiark.greenend.org.uk/~sgtatham/putty.html">
http://www.chiark.greenend.org.uk/~sgtatham/putty.html</ULink></Para></ListItem>
</VarListEntry>
</VariableList>
<Note><Para>Note: If you do decide to switch to using ssh, make sure you install
and use it on <Emphasis>all</Emphasis> your servers. Having five secure
servers and one insecure one is a waste of time,
<Emphasis>especially</Emphasis> if you are foolish enough to use the same
password for more than one server.</Para></Note></ListItem>
<ListItem><Para><emphasis>Restrict access to external services:</emphasis> Next, you
should edit the ``<Literal>/etc/hosts.allow</Literal>'' as well as the
``<Literal><Filename>/etc/hosts.deny</Filename></Literal>'' file to
restrict access to services to external hosts. Here is an example of how
to restrict telnet and ftp access. First, the
``<Literal><Filename>/etc/hosts.allow</Filename></Literal>'' file:</Para>
<ProgramListing>
# hosts.allow
in.telnetd: 123.12.41., 126.27.18., .mydomain.name, .another.name
in.ftpd: 123.12.41., 126.27.18., .mydomain.name, .another.name
</ProgramListing>
<Para>The above would allow any hosts in the IP class C's 123.12.41.* and
126.27.18.*, as well as any host within the mydomain.name and another.name
domains to make telnet and ftp connections.</Para>
<Para>Next, the ``<Literal><Filename>/etc/hosts.deny</Filename></Literal>''
file:</Para>
<ProgramListing>
# hosts.deny
in.telnetd: ALL
in.ftpd: ALL
</ProgramListing>
</ListItem>
<ListItem><Para><emphasis>Turn off and uninstall unneeded services:</emphasis> Edit
your ``<Literal><Filename>/etc/inetd.conf</Filename></Literal>'' file,
and disable (ie. comment out using a ``<Literal>#</Literal>'' character)
any services that are not needed (if you're using ssh as recommended
above, you might wish to disable the ``telnet'' service). After you have
done so, as root type ``<Literal>/etc/rc.d/init.d/inet
restart</Literal>'' to restart the inetd daemon with the
changes.</Para></ListItem>
<ListItem><Para><emphasis>Install a security detection system:</emphasis> Consider
installing security programs such as ``Tripwire'' (see <ULink
URL="http://www.tripwiresecurity.com/">
http://www.tripwiresecurity.com/</ULink>) which can detect intrusions, and
``Abacus Sentry'' (see <ULink URL="http://www.psionic.com/abacus/">
http://www.psionic.com/abacus/</ULink>) which can help prevent
them.</Para></ListItem>
<ListItem><Para><emphasis>Due diligence:</emphasis> Keeping your eye on your system, performing
random security audits (which can be as simple as checking for suspicious
entries in the password files, examining your process list, and checking
your log files for suspicious entries) can go a long way towards keeping
a secure system. In addition, report any break-in attempts to the
appropriate authorities -- it may be a hassle to do this, particularly if
your system sees several of these attacks in a given week, but such reports
ensures that would-be crackers are deterred by threat of punishment, as well
as ensuring that others' systems (which may themselves have been compromised)
are kept secure.</Para></ListItem>
<ListItem><Para>Assuming you install and upgrade system tools and
applications using the ``<Literal>RPM</Literal>'' utility, you may wish to
verify the integrity of your installed packages by auditing them with the
following command:</Para>
<Screen>
<UserInput>rpm --verify -a > /tmp/rpm-audit.txt</UserInput>
</Screen>
<Para>The above command will check your system's RPM database with all
relevant files, and indicate any files which have been modified, by
displaying a '5'. Here is some example output of such an audit:</Para>
<Screen>
S.5....T /bin/ls
S.5....T /usr/bin/du
......G. /dev/tty5
.....U.. /dev/vcs5
.....U.. /dev/vcsa5
S.5....T c /etc/lynx.cfg
S.5....T c /etc/sendmail.cf
</Screen>
<Para>In the sample output above, you can see a list of seven files, four
of which have been modified. Now, obviously there are going to be
several, perhaps many, files which have been modified if you have
customized your system at all. A brief check of the
<Filename>/etc/lynx.cfg</Filename> and
<Filename>/etc/sendmail.cf</Filename> files, perhaps visually or perhaps
from backup, might reveal legitimate configuration changes that you have
made to your system.</Para>
<Para>However, notice in the sample above, two of the modified files are
<Emphasis>binary executable</Emphasis> files? It is likely that these two
binaries, the ``ls'' command as well as the ``du'' command, are actually
trojan binaries which a system cracker has installed to perform some
nefarious purposes (a ``<Literal>diff</Literal>'' command performed on any
modified binaries with those restored from backup or RPM might reveal
significant size or other differences; further evidence of
trojans.)</Para>
<Para>(For more information on ``<Literal>RPM</Literal>'', see <XRef
LinkEnd="using-rpm">.)</Para></ListItem>
</ItemizedList>
<Para>For more information on security-related issues, an excellent
resource entitled, <Quote>Securing RedHat 5.x</Quote> document is
available at <ULink URL="http://redhat-security.ens.utulsa.edu/">
http://redhat-security.ens.utulsa.edu/</ULink>. An excellent resource
for Linux crypto and related software is at
<ULink URL="http://replay.com/redhat">http://replay.com/redhat/</ULink>.</Para>
</Chapter>
<Chapter id="trouble-in-paradise"><Title>Help! Trouble in Paradise!</Title>
<Para>Linux is earning a reputation world-wide for its performance and
reliability. Nevertheless, no system is perfect, and from time to time you
are bound to hit a snag. Fortunately, with uptimes measuring in the
months (compared to those measuring in the days or weeks as with NT), such
snags will likely be few and far between.</Para>
<Sect1 id="unsupported-tips"><Title>Getting Linux Installed on new, Unsupported Hardware</Title>
<Para><Emphasis>( Under construction :-p )</Emphasis></Para>
</Sect1>
<Sect1 id="crash-repair"><Title>File System Corruption after Power Outage or System Crash</Title>
<Para>Although Linux is a stable operating system, should it happen to
crash unexpectantly (perhaps due to a kernel bug, or perhaps due to a
power outage), your file system(s) will not have been unmounted and
therefore will be automatically checked for errors when Linux is
restarted.</Para>
<Para>Most of the time, any file system problems are minor ones caused by
file buffers not being written to the disk, such as deleted inodes still
marked in use. In the majority of cases, the file system check will be
able to detect and repair such anomolies automatically, and upon completion
the Linux boot process will continue normally.</Para>
<Para>Should a file system problem be more severe (such problems tend to
be caused by faulty hardware such as a bad hard drive or memory chip;
something to keep in mind should file system corruption happen
frequently), the file system check may not be able to repair the problem
automatically. This is usually, but not always, the case when the root
file system itself is corrupted. In this case, the Red Hat boot process
will display an error message and drop you into a shell, allowing you to
attempt file system repairs manually.</Para>
<Para>As the recovery shell unmounts all file systems, and then mounts the
root file system <Quote>read-only</Quote>, you will be able to perform full
file system checks using the appropriate utilities. Likely you will be
able to run e2fsck on the corrupted file system(s) which should hopefully
resolve all the problems found.</Para>
<Para>After you have (hopefully) repaired any file system problems, simply
exit the shell to have Linux reboot the system and attempt a subsequent
restart.</Para>
<Para>Naturally, to be prepared for situations such as a non-recoverable
file system problem, you should have one or more of the following things
available to you:</Para>
<ItemizedList Spacing="Compact">
<ListItem><Para>The boot/root emergency disk set,
<Emphasis>AND/OR</Emphasis></Para></ListItem>
<ListItem><Para>The LILO emergency boot disk,
<Emphasis>AND</Emphasis></Para></ListItem>
<ListItem><Para>A recent backup copy of your important files -- just in
case!</Para></ListItem>
</ItemizedList>
</Sect1>
<Sect1 id="where-to-turn"><Title>Where to Turn for Help</Title>
<Para>As Linux is developed by members of the Internet community, the best
place to get help is probably by posting a message to any of the following
newsgroups:</Para>
<VariableList>
<VarListEntry>
<Term>Miscellaneous postings not covered by other groups</Term>
<ListItem><Para><ULink URL="news:comp.os.linux.misc">comp.os.linux.misc</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>Networking-related issues under Linux</Term>
<ListItem><Para><ULink URL="news:comp.os.linux.networking">comp.os.linux.networking</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>Security-related issues under Linux</Term>
<ListItem><Para><ULink URL="news:comp.os.linux.security">
comp.os.linux.security</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>Linux installation &amp; system administration</Term>
<ListItem><Para><ULink URL="news:comp.os.linux.setup">
comp.os.linux.setup</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>Everybody is entitled to their opinion :-p</Term>
<ListItem><Para><ULink URL="news:alt.linux.sux">
alt.linux.sux</ULink></Para></ListItem>
</VarListEntry>
</VariableList>
<Para>For non Linux-specific topics, there are a variety of groups in the
comp.* heirarchy that may suit your needs. Here are just a few of
them:</Para>
<VariableList>
<VarListEntry>
<Term>Cisco router/access-server line of products</Term>
<ListItem><Para><ULink URL="news:comp.dcom.sys.cisco">comp.dcom.sys.cisco</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>Miscellaneous web server questions</Term>
<ListItem><Para><ULink URL="news:comp.infosystems.www.servers.misc">
comp.infosystems.www.servers.misc</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>General unix (not Linux-specific) questions</Term>
<ListItem><Para><ULink URL="news:comp.os.unix">
comp.os.unix</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>The SMB protocol (WfW/95/NT-style file/print services)</Term>
<ListItem><Para><ULink URL="news:comp.protocols.smb">
comp.protocols.smb</ULink></Para></ListItem>
</VarListEntry>
</VariableList>
<Para>There are also several resources on the Web that may be useful. Do
a web search for <Quote>Linux</Quote>, or visit any of the
following:</Para>
<VariableList>
<VarListEntry>
<Term>Linux Resources</Term>
<ListItem><Para><ULink URL="http://www.linuxresources.com/">
http://www.linuxresources.com/</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>The Linux Documentation Project</Term>
<ListItem><Para><ULink URL="http://metalab.unc.edu/LDP/">
http://metalab.unc.edu/LDP/</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>The RPM repository</Term>
<ListItem><Para><ULink URL="http://rufus.w3.org/linux/RPM/">
http://rufus.w3.org/linux/RPM/</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>The Linux Software Map</Term>
<ListItem><Para><ULink URL="http://www.boutell.com/lsm">
http://www.boutell.com/lsm</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>Linux Applications &amp; Utilities Guide</Term>
<ListItem><Para><ULink URL="http://www.xnet.com/~blatura/linapps.shtml">
http://www.xnet.com/~blatura/linapps.shtml</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>LinuxHardware.net: Hardware Driver Support</Term>
<ListItem><Para><ULink URL="http://www.linuxhardware.net/">
http://www.linuxhardware.net/</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>Linux User Support Team</Term>
<ListItem><Para><ULink URL="http://www.ch4549.org/lust">
http://www.ch4549.org/lust</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>The Linux v2 Information Headquarters</Term>
<ListItem><Para><ULink URL="http://www.linuxhq.com/">
http://www.linuxhq.com/</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>The Samba Home Page (WfW/95/NT-style file/print services)</Term>
<ListItem><Para><ULink URL="http://samba.anu.edu.au/samba/">
http://samba.anu.edu.au/samba/</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>The Apache Web Server</Term>
<ListItem><Para><ULink URL="http://www.apache.org/">
http://www.apache.org/</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>The Squid HTTP Proxy Caching Daemon</Term>
<ListItem><Para><ULink URL="http://squid.nlanr.net/Squid/">
http://squid.nlanr.net/Squid/</ULink></Para></ListItem>
</VarListEntry>
</VariableList>
<Para>There are a myriad of mailing lists that may prove helpful in
providing answers to your questions as well. These can usually be found
through a simple web search (for example, searching for <Emphasis>``linux
raid mailing list''</Emphasis> might help you find mailing lists devoted
to RAID issues under Linux). Here are some I recommend; to subscribe to
any of these lists, simply send an e-mail message to the subscription
address listed with the word <Quote><Emphasis>subscribe</Emphasis></Quote>
in the body of your message:</Para>
<VariableList>
<VarListEntry>
<Term>Red Hat Mailing Lists</Term>
<ListItem><Para>Description of available Red Hat lists: <ULink URL="http://archive.redhat.com/">
http://www.redhat.com/</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>GNOME Mailing Lists</Term>
<ListItem><Para>Description of available GNOME lists: <ULink URL="http://www.gnome.org/mailing-lists/index.shtml">
http://www.gnome.org/mailing-lists/index.shtml</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>KDE Mailing Lists</Term>
<ListItem><Para>Description of available KDE lists: <ULink URL="http://www.kde.org/contact.html">
http://www.kde.org/contact.html</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>Linux SCSI Mailing List</Term>
<ListItem><Para>Subscription address: <ULink URL="mailto:linux-scsi-request@vger.rutgers.edu">
linux-scsi-request@vger.rutgers.edu</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>Linux RAID Mailing List</Term>
<ListItem><Para>Subscription address: <ULink URL="mailto:linux-raid-request@vger.rutgers.edu">
linux-raid-request@vger.rutgers.edu</ULink></Para></ListItem>
</VarListEntry>
</VariableList>
<Para>Finally, you may be interested in checking out the following two
sites, both of which are my personal <Quote>daily must read</Quote>
favorites. SlashDot covers the latest technology news in general with a
definite Linux slant, while FreshMeat provides an up-to-date listing of
Open Source applications announcements.</Para>
<VariableList>
<VarListEntry>
<Term>SlashDot: News For Nerds</Term>
<ListItem><Para><ULink URL="http://slashdot.org/">
http://slashdot.org/</ULink></Para></ListItem>
</VarListEntry>
<VarListEntry>
<Term>FreshMeat: Open Source Applications Announcements</Term>
<ListItem><Para><ULink URL="http://freshmeat.net/">
http://freshmeat.net/</ULink></Para></ListItem>
</VarListEntry>
</VariableList>
</Sect1>
<Sect1 id="additional-docs"><Title>Pointers to Additional Documentation</Title>
<Para>There is an incredible amount of documentation available for Linux
and its applications. Most of this can be found on the web and in your
local bookstore, but you will probably find that a large quantity of
useful documentation is already available to you, having been loaded as
part of the Red Hat Linux installation procedure.</Para>
<Para>The man pages are a must-view when you are trying to figure out how
a command works. For example, if you are trying to figure out how to use
the ``tar'' utility, you could type ``<Literal>man tar</Literal>'' and be
provided with a very verbose description of tar including all of its
command-line options.</Para>
<Para>You can find more general information in the
``<Literal><Filename>/usr/doc/</Filename></Literal>'' directory. Here
you will find subdirectories which include documentation on utilities and
commands, Frequently Asked Questions (FAQ) documents, as well as HOWTO
documents providing good instruction on a variety of topics, such as how
to set up networking, or install support for the Japanese
language.</Para>
<Para>You should also look in the
``<Literal><Filename>/usr/info/</Filename></Literal>'' directory which
contains tutorials on utilities, libraries, and applications such as
emacs.</Para>
<Para>Finally, you should visit the Red Hat User's Frequently Asked Questions
(FAQ) document at <ULink URL="http://www.pobox.com/~aturner/RedHat-FAQ/">
http://www.pobox.com/~aturner/RedHat-FAQ/</ULink> which contains a lot of
helpful information specific to the Red Hat distribution of Linux.</Para>
</Sect1>
</Chapter>
</Book>
View Git Blame Copy Permalink