lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
eec934fe6cdf00ff46c70c324c1949d18222ecc3
oldlinux-files/docs/Install-Guide/install-guide-1.0.txt.gz
gohigh 9912ec445d add directory docs
2024-02-19 00:23:35 -05:00

8003 lines
306 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
Linux Installation and Getting Started
------------------------------------------------------------------------
Copyright 1993 Matt Welsh, <mdw@TC.Cornell.EDU>
Version 1.0, 5 August 1993.
This book is an introduction to the Linux system, including infor-
mation on how and where to get Linux, installation of the software,
a beginning UNIX tutorial, and an introduction to system adminis-
tration. This is the first book anyone with interest in Linux should
read.
Note: This is the ASCII version of Linux Installation and Getting
Started, which is a quick hack made possible by a combination of
a LaTeX style format, dvi2tty, and a couple of hours of manual
editing. It is only made available to give those with no PostScript
or .dvi viewing/printing capabilities a chance to use the book.
However, if you have access to a PostScript printer, xdvi, or
GhostView, I suggest that you use one of these to view or print the
.dvi or PostScript version of the book, which includes such features
as:
* Fonts
* Page numbers
* Table of contents
* Nicely-formatted page layout
* A complete vi tutorial
* Linux BBS list
* And more!
This ASCII version is slightly ugly, and in the future I hope that
LameTeX will provide enough functionality to format the LDP manuals
for ASCII. However, it's readable. Enjoy. --mdw
Preface
It's unfortunate that the Intel 80386 and 80486 line of processors
has been subjected to the growing popularity of so-called operating
systems such as MS-DOS, an aging system which doesn't exploit
the power of these machines. It's also unfortunate that better
operating systems, commercial UNIXes and OS/2 included, are
so large and expensive_not the enthusiast's forte. The question
everyone's been asking is, "Who's going to save the IBM PC?" Who
is going to save the PC world from the death grip of commercial
operating systems? Where's Richard Stallman when you need him?
Things were looking extremely bleak, as the dark cloud of Mi-
crosoft and IBM loomed menacingly on the horizon. But, at long
last, a messiah emerged unexpectedly from the fjords of Helsinki.
Kernel in hand, with a growing band of programmers, beta testers,
and other such brigands in tow_Linus Torvalds. And his system
was known as Linux: the free UNIX clone for the 386.
The author hopes that this book will bring the masses the god-
foot of that most miraculous of systems. Until recently only those
with a true aptitude for UNIX and, indeed, computers in gen-
eral have been able to take the plunge and run Linux on their
machines. We have braved the jungle of conflicting and obsolete
Linux documentation, and have fought with ardor to clear the path
for newcomers, those without the alleged software machete. But
trailblazing can only go so far. Sometimes it's best to burn down
the entire jungle and start anew. This manual is the result of this
destruction and rebirth.
Finally, the cowering bourgeois can install and run Linux on
almost any 386 or 486 based machine. Even those who have never
seen or touched the likes of UNIX before can immerse themselves
in the beauty of true multitasking, X Windows, TEX, and a myriad
of GNU software. And it doesn't cost a shilling_it is the free soft-
ware buff's dream. It is the chance for all of us UNIX-developer
wannabe's to get our hands dirty with kernel programming, port-
ing software, writing documentation, and fixing bugs. It is the
frustrated programmer's recluse from segmented memory and false
32-bit environments. It is the neophyte's escape from MS-DOS to
the Elysian Fields of UNIX, the future.
Audience
This book is for any personal computer user who wants to install
and use Linux on their system. We assume that you have basic
knowledge about personal computers and operating systems such
as MS-DOS. No previous knowledge about Linux or UNIX is as-
sumed.
Organization
This book contains the following chapters.
Chapter 1, Introduction, gives a general introduction to what
Linux is, what it can do for you, and what is required to run it on
your system.
Chapter 2, Getting Linux, explains how to obtain the Linux
software, either via U.S. Mail or from the Internet, via FTP. This
discussion focuses on the SLS distribution of Linux.
Chapter 3, Installing Linux, explains how to install the Linux
software, from repartitioning your drive, creating filesystems, and
loading the software on the system. Again, this discussion focuses
on the SLS distribution.
Chapter 4, Linux Tutorial, is a complete introduction to using
the Linux system for UNIX novices. If you have previous UNIX
experience, most of this material should be familiar.
Chapter 5, System Administration, introduces many of the im-
portant concepts of system administration under Linux. This will
also be of interest to UNIX system administrators who want to
know about the Linux-specific issues of running a system.
Chapter 6, Advanced Features, introduces the reader to a num-
ber of advanced features supported by Linux, such as the X Win-
dow System and TCP/IP networking.
Appendix A, Tips, Tricks, and Common Problems, contains
other information of interest to those setting up a new Linux sys-
tem, such as how to install Linux from the hard drive, and how to
set up Linux for use with multiple filesystems.
Appendix B, Bibliography and Sources of Information, is a list-
ing of other sources of information about Linux, including news-
groups, mailing lists, online documents, and books.
Appendix C, Quick FTP Tutorial, is a tutorial for downloading
files from the Internet with FTP. This appendix also includes a
listing of FTP archive sites which carry Linux software.
Appendix D, Linux BBS List, is a listing of bulletin board sys-
tems worldwide which carry Linux software. Because most Linux
users are do not have access to the Internet, it is important that
information on BBS systems becomes available.
Appendix E, The GNU General Public License, contains a copy
of the GNU GPL, the license agreement under which Linux is dis-
tributed. It is very important that Linux users understand the
GPL; many disagreements over the terms of the GPL have been
raised in recent months.
Acknowledgments
This book has been long in the making, and many people are re-
sponsible for the outcome. In particular, I would like to thank
Larry Greenfield and Karl Fogel for their work on the first version
of Chapter 4, and to Lars Wirzenius for his work on Chapter 5.
Thanks to Michael K. Johnson for his assistance with the LDP
and the LaTEX conventions used in this manual. I would also like
to thank Andy Oram, Lar Kaufman, and Bill Hahn at O'Reilly
and Associates for their assistance and interest in the Linux Doc-
umentation Project. And, of course, a special thanks to the many
activists, especially Linus Torvalds and Peter MacDonald, without
whom this would not have been possible.
In the last two years, we've seen Linux grow from a single hack-
er's operating systems programming project into a fully-functional
UNIX clone, with an expanding support base of software, users,
and programmers. Linux, as it stands now, is one of the greatest
accomplishments of free software in existence, and I can only antic-
ipate its further growth. I'd like to call it a revolution. I guess we'll
see. So, gentle reader, I give you Linux_soon to be your faithful
companion in the war against the wrath of proprietary operating
systems. Take no prisoners.
Matt Welsh
5 August 1993
Credits and Legalese
The Linux Documentation Project is a loose team of writers, proof-
readers, and editors who are working on a set of definitive Linux
manuals. The overall coordinator of the project is Matt Welsh,
aided by Lars Wirzenius and Michael K. Johnson.
This manual is but one in a set of several being distributed by
the Linux Documentation Project, including a Linux User's Guide,
System Administrator's Guide, and Kernel Hacker's Guide. These
manuals are all available in LaTEX source format and Postscript
output for anonymous FTP from tsx-11.mit.edu, in the directory
/pub/linux/ALPHA/LDP.
We encourage anyone with a penchant for writing or editing to
join us in improving Linux documentation. If you have Internet e-
mail access, you can join the DOC channel of the Linux-Activists
mailing list by sending mail to
linux-activists-request@niksula.hut.fi
with the line
X-Mn-Admin: join DOC
as the first line of the message body.
Feel free to get in touch with the author and coordinator of this
manual if you have questions, postcards, money, or ideas. Matt
Welsh can be reached via Internet e-mail at mdw@tc.cornell.edu,
and in real life at
205 Gray Street
Wilson, N.C. 27893
U.S.A.
UNIX is a trademark of Unix System Laboratories
Linux is not a trademark, and has no connection to UNIX[TM] or
Unix System Laboratories.
Copyright (c) 1993 Matt Welsh
205 Gray Street NE, Wilson NC, 27893 USA
mdw@tc.cornell.edu
Linux Installation and Getting Started may be reproduced and dis-
tributed in whole or in part, subject to the following conditions:
0. The copyright notice above and this permission notice must
be preserved complete on all complete or partial copies.
1. Any translation or derivative work of Linux Installation, Set-
up, and Getting Started must be approved by the author in
writing before distribution.
2. If you distribute Linux Installation and Getting Started in
part, instructions for obtaining the complete version of this
manual must be included, and a means for obtaining a com-
plete version provided.
3. Small portions may be reproduced as illustrations for reviews
or quotes in other works without this permission notice if
proper citation is given.
4. The GNU General Public License referenced below may be
reproduced under the conditions given within it.
5. Several sections of this document are held under separate
copyright. When these sections are covered by a different
copyright, the separate copyright is noted. If you distribute
Linux Installation and Getting Started in part, and
that part is, in whole, covered under a separate, not-
ed copyright, the conditions of that copyright apply.
Exceptions to these rules may be granted for academic purpos-
es: Write to Matt Welsh, at the above address, or email mdw@tc.cornell.edu,
and ask. These restrictions are here to protect us as authors, not
to restrict you as educators and learners.
All source code in Linux Installation and Getting Started is placed
under the GNU General Public License. See appendix E for a copy
of the GNU "GPL."
Documentation Conventions
These conventions should be obvious, but we'll include them here
for the pedantic.
Bold Used to mark new concepts, WARNINGS, and
keywords in a language.
italics Used for emphasis in text, and occasionally for
quotes or introductions at the beginning of a sec-
tion. Also used to indicate commands for the user
to type when showing screen interaction (see be-
low).
<slanted> Used to mark meta-variables in the text, espe-
cially in representations of the command line. For
example,
ls -l <foo>
where <foo> would "stand for" a filename, such as
/bin/cp.
Typewriter Used to represent screen interaction, as in
$ ls -l /bin/cp
-rwxr-xr-x 1 root wheel 12104 Sep
25 15:53 /bin/cp
Also used for code examples, whether it is C code,
a shell script, or something else, and to display
general files, such as configuration files. When nec-
essary for clarity's sake, these examples or figures
will be enclosed in thin boxes.
[Key] Represents a key to press. You will often see it in
this form:
Press [return] to continue.
Chapter 1
Introduction
This book is about Linux, the free clone of the UNIX operating
system for 80386 and 80486 machines. The rationale for writing
this manual is clear: as Linux has grown and gained popularity,
the old approach of searching a myriad of old documentation and
software, downloading megabytes of files, and hoping that every-
thing works is no longer adequate. Surprisingly, the number of
MS-DOS and OS/2 users who are moving to Linux is large, and
many of these users are new to UNIX. Here, rolled into one book,
is a complete guide to installing Linux, with enough introductory
material on using UNIX to get new users on their feet.
Linux is a clone of the UNIX operating system that runs on
Intel 80386 and 80486 based machines. It supports a wide range of
software, from TEX to X Windows to the GNU C/C++ compiler
to TCP/IP. It's a versatile, bona fide implementation of UNIX,
freely distributed by the terms of the GNU General Public License
(see Appendix E). Before we delve any further, a few words about
this book.
1.1 About This Book
In this manual, we'll cover:
o What Linux is;
o How to obtain and install Linux on your system;
o Getting started with Linux, even if you've never UNIX before;
o The basics of Linux system administration;
o An introduction to upgrading and installing new software.
This manual assumes no previous knowledge of Linux or UNIX.
Some experience with Intel-based personal computers is assumed,
and familiarity with MS-DOS or Microsoft Windows is helpful.
If you have previous UNIX experience, you may wish to skip
ahead to Chapter 2, "Getting Linux," and then read through Chap-
ter 3, "Installing Linux," and from there you're set. You may also
wish to read Chapter 6, discussing some of the more advanced and
interesting features of Linux. The rest of the manual covers issues
of concern to those new to UNIX.
1.2 Introduction to Linux and UNIX
UNIX is one of the most popular operating systems worldwide be-
cause of its large support base and distribution. It was originally
developed as a multitasking system for minicomputers and main-
frames in the mid-1970's, but has since grown to become one of the
most widely used operating systems anywhere, despite its some-
times confusing interface and lack of central standardization.
The real reason for UNIX's popularity? Many hackers feel that
UNIX is the Right Thing_the One True Operating System. Hence,
the development of Linux by an expanding group of UNIX hackers
who want to get their hands dirty with their own system. Doug
Gwyn said, "UNIX was never designed to keep people from doing
stupid things, because that policy would also keep them from doing
clever things." Most UNIX hackers would agree.
Versions of UNIX exist for many systems_ranging from person-
al computers to to supercomputers such as the Cray Y-MP. Most
versions of UNIX for personal computers are quite expensive and
cumbersome. At the time of this writing, a one-machine version of
AT&T's System V for the 386 runs at about US$1500.
1.2.1 Where Linux comes in
Linux is a freely distributable version of UNIX developed primarily
by Linus Torvalds (*Note: torvalds@kruuna.helsinki.fi.) at
the University of Helsinki in Finland. Linux was developed with
the help of many UNIX programmers and wizards across the In-
ternet, allowing anyone with enough know-how and gumption to
hack a custom UNIX kernel the ability to develop and change the
system. The Linux kernel uses no code from AT&T or any other
proprietary source, and much of the software available for Linux
is developed by the GNU project at the Free Software Foundation
in Cambridge, Massachusetts. However, programmers all over the
world have contributed to the growing pool of Linux software.
Linux supports almost all of the features of commercial ver-
sions of UNIX, as well as many not found on proprietary UNIX
systems. Furthermore, Linux is closely compatible with the IEEE
POSIX.1 standard, and has been developed with software porta-
bility in mind, thus supporting many important features of other
UNIX standards. Linux also utilizes all of your system's memory_
without memory limits or segmentation. The Linux system runs
exclusively in 80386's protected mode, which allows it to operate
as a true 32-bit operating system. A little-known fact about the
80386 and 80486 chips is that, internally, these processors were
designed to support multitasking systems such as UNIX. Unfortu-
nately, even MS-DOS 6.0 has yet to exploit these features.
There is a rumor abound that UNIX is a large, unwieldy system,
unapproachably hungry for resources such as disk space and mem-
ory. In Linux, the proof to dispell those myths was implemented.
Linux is small, fast, and flexible. It requires fewer resources than
IBM's OS/2, and uses less space than many MS-DOS or Microsoft
Windows systems including large applications (such as Microsoft
Word or Lotus 1-2-3). Linux has built-in support for networking,
multitasking, and other features which you'll see touted as "New
Technology" in systems such as in Windows NT. In fact, UNIX
(and now, Linux) has implemented this "New Technology" for well
over 15 years. The proprietary PC software industry is still catch-
ing up.
When using Linux, keep in mind that it is truly "a hacker's
operating system"_developed by and for UNIX hackers. This is
a strong distinction between commercial versions of UNIX, which
are designed for customers, not for hackers. Commercial versions
of UNIX are expected to work "out of the box". This is not the
case with Linux.
Because of this distinction, many newcomers get easily frustrat-
ed with Linux. The only problem is a lack of basic UNIX know-how.
Setting up and running your own UNIX system is something which
most UNIX users never get to do, even after years of experience.
Linux has provided UNIX newcomers the unique opportunity to
"do it yourself"_but nobody said it was going to be easy.
It takes a lot of time and effort to run your own UNIX system
(and a certain knack for fixing problems). Even with standard
Linux distributions, such as SLS, there are sometimes little quirks
which need to be fixed by hand in order for everything to work
correctly. If you have previous UNIX experience, it should be easy
to find these problems. However, if you're new to UNIX, it would
serve you well to read up on using and running a UNIX system
before you dive in.
Put simply, Linux isn't for everyone. Many users get in "over
their heads" when getting started with Linux. To keep your head
above water, we strongly encourage you to find a good book on
using UNIX, as well as a book on UNIX system administration. In
this manual, we include an introductory UNIX and system admin-
istration tutorial, but this is the bare minimum that is needed to
get started.
The Linux Documentation Project is working to solve this dilem-
ma. In the future, the LDP's Linux User's Guide and Linux System
Administration Guide will be available. Until then, you'll need to
rely on other sources.
See Appendix B for a list of relevant UNIX books and other
sources of information.
1.3 About Linux's Copyright
Linux is copyrighted under the GNU General Public License, some-
times called the GPL or copyleft. This license was developed by
the Free Software Foundation to allow programmers to write "free
software", where "free" refers to freedom, not just cost. The GPL
provides for the protection of such free software in a number of
ways. First of all, it allows the original author to retain the soft-
ware's copyright. Secondly, it allows others to take the software
and modify it, or base other programs on it. Thirdly, it allows
others to redistribute or resell the software, or modified versions of
the software. You can even resell the software for profit. However,
in reselling or redistributing the software, you cannot restrict any
of these rights from the party you're selling it to. Also, if you sell
the software, you have to provide at no cost the full source code so
that others can modify the software and resell it if they wish.
This might sound a bit silly at first. Why sell software for prof-
it, if someone else can give it away for free? Essentially, that's the
point. However, let's say someone bundles a large amount of free
software together on a CD-ROM and wishes to distribute it world-
wide. They'll probably need to charge for this service to cover their
cost and risk in distributing the software. Right now, several or-
ganizations are distributing Linux on CD-ROM, and making profit
from it. The original authors of the Linux software may never see
a penny of these revenues. This is allowed by the GNU GPL_
the point of free software isn't to make money; nobody's getting
ripped off. That's simply an understanding between the authors of
the software and those who are using it or selling it.
One other thing: Free software, as covered by the GNU G-
PL (which includes Linux), comes with absolutely no warranty.
However, individual vendors may provide support for the software,
which usually includes a warranty. However, unless you purchased
such support, the assumption is that the software comes with no
such warranty, and if you use a piece of free software which goes
haywire and wipes everything on your system, neither the authors
nor those that distributed the software to you are liable (*Note:
Hopefully, this won't happen.).
Free software as covered by the GPL is not shareware, nor is
it in the public domain. Neither of these terms correctly describe
what free software really is. The complete GNU GPL is printed in
Appendix E. To sum it all up, you can freely distribute Linux as
much as you like, and you can even modify it and distribute your
own version of Linux. But in doing so, you can't take away those
rights from others. Furthermore, you must attribute the original
authors of the work.
1.4 Features of Linux
Here are some of the benefits and features that Linux provides over
single-user operating systems (such as MS-DOS) and other versions
of UNIX for the PC.
o Full multitasking and 32-bit support. Linux, like all oth-
er versions of UNIX, is a real multitasking system, allowing
multiple users to run many programs on the same system at
once. The performance of a 50 MHz 486 system running Lin-
ux is comparable to many low- to medium-end workstations,
such as those from Sun Microsystems and DEC, running pro-
prietary versions of UNIX. Linux is also a full 32-bit operating
system, utilizing the special protected-mode features of the
Intel 80386 and 80486 processors.
o GNU software support. Linux supports a wide range of
free software written by the GNU Project, including utilities
such as the GNU C and C++ compiler, gawk, groff, and so
on. Many of the essential system utilities used by Linux are
GNU software.
o The X Window System. The X Window System is the
de facto industry standard graphics system for UNIX ma-
chines. A free version of The X Window System (known as
"Xfree86") is available for Linux. The X Window System is
a very powerful graphics interface, supporting many applica-
tions. For example, you can have multiple login sessions in
different windows on the screen at once. Other examples of
X Windows applications are Seyon, a powerful telecommuni-
cations program; Ghostscript, a PostScript language proces-
sor; and XTetris, an X Windows version of the popular game.
See Section 6.1 for an introduction to the X Window System.
o TCP/IP networking support. TCP/IP ("Transmission
Control Protocol/Internet Protocol") is the set of protocol-
s which links millions of university and business computers
into a worldwide network known as the Internet. With an
Ethernet connection, you can have access to the Internet or
to a local area network from your Linux system. Or, using
SLIP ("Serial Line Internet Protocol"), you can access the
Internet over the phone lines with a modem. Section 6.2 has
an introduction to configuring the Linux TCP/IP software.
o Virtual memory and shared libraries. Linux can use
a portion of your hard drive as virtual memory, expanding
your total amount of available RAM. Linux also implements
shared libraries, allowing programs which use standard sub-
routines to find the code for these subroutines in the libraries
at runtime. This saves a large amount of space on your sys-
tem, as each application doesn't store its own copy of these
common routines.
1.5 Hardware Requirements
Unlike some other versions of UNIX for the PC, Linux is very
small. You can run an entire system from a single high-density
5.25" floppy. However, to run a complete Linux system, there are
other hardware requirements, listed below.
Linux, by its very nature, is continuously expanding, and more
features are added every day. However, hardware compatibility
is limited to that hardware which the developers themselves have
access to. For instance, if none of the Linux developers has access
to the Foobaz Net-O-Driver 3000 card, then chances are it isn't
supported. On the other hand, there are many "generic" drivers_
for example, the IDE disk driver for Linux should work with all
IDE hard drives and adapters.
If your favorite peripheral isn't supported by Linux, all that's
required is to write a kernel driver for it. This may be easy or dif-
ficult, depending on the hardware and the technical specifications
that are available. For example, some hardware developers prefer
to write their own drivers for MS-DOS and Windows, and not re-
lease specifications for third parties to write their own. Therefore,
writing drivers for Linux will be difficult, if not impossible. (We call
this practice "bad business" for the hardware vendors involved.)
1.5.1 Suggested setup
Below, the suggested hardware configuration for Linux is listed. If
you're in the market for a new system, you should follow the recom-
mendations given below. In the next section, we'll talk about some
of the hardware drivers which are currently under development for
Linux, and other hardware which is known not to work.
o An Intel 80386 or 80486 based system. You don't need a
math coprocessor, although it's strongly recommended that
you have one. (If you have an 80386 chip, 80387 math copro-
cessors are available separately, and are installed in a socket
on your motherboard. If you have an 80486 processor, the
math coprocessor is on the 486 chip itself. The exception
is the 80486SX, which is a 486 chip without the coprocessor
components.) If you don't have a math coprocessor, the Lin-
ux kernel will emulate floating-point math for you. If you do
have one, however, floating point math will be handled by
the hardware, which for some applications is a real plus.
The 386SX, 486SX, and the accelerated 486DX and 486DX2
chips are all reported to work. It is suggested that you have
a genuine Intel processor, instead of a clone (such as a CTX
processor). Look for the "Intel Inside" logo on the machine.
The forthcoming Intel Pentium chip should work with Linux
without any changes.
o Your system must be either an ISA, EISA, or local bus ar-
chitecture machine. These terms specify how the CPU com-
municates with hardware, and are a characteristic of your
motherboard. Most existing systems use the ISA bus archi-
tecture. The EISA bus is a newer form of the ISA bus, which
is reportedly faster on some machines. Local bus architec-
ture is often the fastest of the three, as it allows the CPU
to communicate directly to video and drive adapters. If your
machine uses local bus, it is strongly recommended that it
comply with the VESA Local Bus standard (most local bus
systems do).
MicroChannel architecture (MCA) machines, such as the IBM
PS/2 line, are not currently supported.
o At least four megabytes of RAM. Technically, Linux is capa-
ble of running on a system with only two megabytes, however,
some distributions of Linux require four megabytes for instal-
lation. Memory is speed, so if you have more physical RAM
you'll thank yourself for it later. If you're a "power user,"
8 megabytes should be more than enough for most applications.
o An AT-standard compatible hard drive controller. This in-
cludes MFM, RLL, ESDI, and IDE controllers. Many SCSI
controllers are also supported. These terms specify the means
used to communicate with the hard drive through the con-
troller card; most controllers are either IDE or SCSI.
Drivers for XT-standard driver controllers are under devel-
opment; see the next section.
o A hard drive (compatible with your controller card, of course),
with free space available for installing Linux. The amount
of space required depends on the amount of software you're
installing and how much free space you wish to leave your-
self. If you only install a small amount of software, less than
10 megabytes is required. However, if you install a number
of optional software packages, including the X Window Sys-
tem, perhaps 80 megabytes or more, including space for users,
would be required. In addition, you will probably want to set
aside some amount of space on your drive as a swap partition,
used for virtual memory. This is covered in Chapter 3.
o A Hercules, CGA, EGA, VGA, or Super VGA video card and
monitor. In general, if your video card and monitor work
under MS-DOS or Microsoft Windows, then Linux should be
able to use them without any problem. However, if you're go-
ing to use the X Window System, there are certain hardware
configurations which are not yet supported. See Section 6.1
for more.
1.5.2 Other hardware
There are other hardware drivers currently under development for
Linux. However, to use these drivers, you usually have to patch
them into your kernel code, which assumes that you already have
a running Linux system.
The Linux FAQ has information on patching in hardware driver-
s with Linux. See Appendix B for more information.
Linux will also run on a number of laptop machines (some lap-
tops use certain software interrupts to power the memory, and Lin-
ux doesn't cooperate with these systems, yet). The best way to find
out if Linux will run on your hardware is just to try it out.
1.6 Before You Get Started
Assuming that you have hardware compatible with Linux, obtain-
ing and installing the system is not difficult. However, there are
a number of burning questions which most users want answers to
before they dive in.
1.6.1 Running other operating systems with Linux
You can install other operating systems, such as MS-DOS or OS/2,
along with Linux on the same machine. Each operating system uses
its own partitions on the hard drive, and they do not interfere with
each other. For example, if you want to install both MS-DOS and
Linux on the same drive, fine. However, MS-DOS will use one
partition on the drive, and Linux will use another. Partitioning
your drive for use with Linux is covered in Section 3.2.3.
To select which operating system to run at boot time, you can
install LILO, a program which replaces the standard MS-DOS boot
loader on your hard drive. With LILO installed, at boot time you
select the operating system to run from a simple menu. Or, you
can set a default operating system to boot, and override the default
by holding down the [shift] key as the system is booting. LILO is
covered in detail in Section 5.2.2.
Alternately, if you use OS/2, you can boot Linux from the OS/2
Boot Manager. See Section 5.2.2 for more information.
1.6.2 Accessing files from MS-DOS
Linux supports several features which will allow you to access y-
our MS-DOS files from Linux. The mtools package, included with
most distributions of Linux, allows you to use commands such as
mcopy and mdir to access your MS-DOS files. Or, you can mount
an MS-DOS partition or floppy directly under Linux, giving you
direct access to your files using the MS-DOS filesystem. (See Sec-
tion 6.1.6.)
There is also an MS-DOS Emulator available for Linux, and
work is beginning on a Microsoft Windows emulator to run under
the X Window System. The MS-DOS Emulator isn't perfect; don't
expect to play Wing Commander from Linux. However, it will
enable you to run many standard MS-DOS applications, such as
Wordperfect or Lotus 1-2-3. Watch out, Microsoft!
1.6.3 How to pronounce Linux
Pronouncing the word "Linux" is one of the great mysteries of the
Linux world. Americans pronounce the name Linus with a long i
sound, as in pie. However, because Linux was originally based on
a small, PC-based implementation of UNIX called "Minix" (pro-
nounced with a short i ), the actual pronunciation of Linux pre-
serves this characteristic_it's LIH-nucks. Think Finnish.
1.7 Finding Help
There are many people out there who enjoy helping new users get
started with Linux. If you have any problems with installing or us-
ing the system, the first thing you should do is consult this manual
(and the other Linux manuals) to see if your problem is covered
there. Another good source of information is the Linux Frequently
Asked Questions list, which covers many disparate topics not in
this manual. Appendix B for information on the Linux FAQ and
other sources of information.
If you have access to USENET news, you can post questions
to the newsgroup comp.os.linux. The moderated newsgroup
comp.os.linux.announce is also available for announcements and
important information. However, it's strongly suggested that you
read all of the available documentation before posting questions;
most problems are covered in this manual and the Linux FAQ list.
You can also direct questions about this manual, or Linux in
general, to the authors of this book. We're very open to any
questions, comments, or suggestions. Matt Welsh can be reached
on the Internet at mdw@tc.cornell.edu and Lars Wirzenius at
wirzeniu@cc.helsinki.fi.
Chapter 2
Getting Linux
This chapter covers how to obtain the Linux software. If you re-
ceived this manual with a set of Linux software, on disk or CD-
ROM, then you can go ahead and skip to Chapter 3 on installing
the system.
2.1 Distributions of Linux
There is no single, "official" release of the Linux software. In fact,
there are many releases, each independently coordinated by various
companies and individuals. While these releases differ somewhat in
their goals and specifications, each release has a number of elements
in common with the rest:
o The Linux kernel_the lowest level program of the Linux
system, the operating system itself. The kernel is constantly
running, handling the low-level details of memory manage-
ment, process scheduling, device access, and so on. In any
UNIX system, the kernel is the software which controls ac-
cess to system resources (such as memory and processor time)
from user programs (such as a text editor). This is in sharp
contrast to operating systems such as MS-DOS, which allow
only a single program to run at a time.
o A set of utilities which handle basic system tasks such as
manipulating files, creating users, reporting system activity,
and so on. These programs are essentially the same on any
UNIX system, and provide a standard interface for users. For
example, the command to copy a file on all UNIX systems is
known as cp. Therefore, using Linux will be very similar, if
not identical, to using other versions of UNIX.
o The system libraries, which contain common subroutines
used by software to handle everything from file I/O to dis-
playing graphics. Linux implements shared libraries, which
allow programs to share the code in these subroutines, reduc-
ing the size of program binaries significantly.
o A set of system configuration files, containing information
about the users on the system, available devices, network
interface configuration, and so on. Many individual applica-
tions also have their own set of configuration files.
o Online documentation, in the form of manual pages (often
abbreviated as "man pages"). Man pages document the com-
mands, library routines, kernel system calls, file formats, and
device driver interfaces available on the system. They are an
excellent source of online help and are easy to use. The man
pages available for Linux are incomplete, but most of the im-
portant system commands and library calls are documented.
o And, of course, application software. There are many appli-
cations available for Linux, such as TEX (a document pro-
cessing system), Emacs (a powerful yet baroque text editor),
the X Window System (a graphics interface), and more.
The application software is what really composes the Linux
system from the user's point of view. However, it is all of these
elements combined which form the entire system. As mentioned
before, there isn't a single official distribution for all of this soft-
ware. There are many distributions available_each of which differ
somewhat in their installation methods and supported software,
but all of which contain the essential elements listed above.
In this book, we focus on the Softlanding Linux System (SLS)
distribution of Linux. SLS has become the de facto standard for
Linux installations worldwide. Because of its completeness and
ease of use, we will only cover how to get and install the SLS
distribution here.
We don't mean to be biased towards a particular release; how-
ever, it takes a lot of time and effort to keep up with all of the Linux
distributions available. However, all of the concepts discussed in
this book apply to Linux distributions other than SLS.
2.2 The SLS Distribution
The Linux distribution that many people have installed is known as
the Softlanding Linux System ("SLS") distribution. SLS is coordi-
nated by Peter MacDonald (*Note: pmacdona@sanjuan.uvic.ca.),
and has become the most widely-used release of Linux, because of
its completeness and ease of installation.
The SLS distribution is broken into various sets of disks, each
of which is denoted by a letter followed by a disk number. For
example, the a series disks are numbered a1, a2, a3, and a4. The
disk series in the current SLS distribution are shown below.
o a1-a4: The minimal base system, required. Contains the
Linux kernel, libraries, basic binaries, and tools used to set
up and install the system.
o b1-b7: Base system extras, such as man pages, Emacs, and
so on.
o c1-c3: Compilers, such as gcc, p2c, f2c, and others.
o x1-x10: The X Window System and related software.
o t1-t3: TEX, a document formatting system.
o s1: Source code for several of the packages. Currently under
development.
o d1-d2: Documentation for various things.
As more packages are added to SLS, new series are added, or
extra disks are added to the existing series.
The only set of disks which you must install are the a set.
However, you should probably install at least the b and c disk sets
as well, which contain the full base system and compilers. For
X Windows (see Section 6.1) you should install the x series in
addition to a, b, and c.
It is easy to upgrade your software with the SLS distribution.
For example, you could install only the a and b series, and install
the c and x series at another time. Therefore, you may wish to
only install the SLS a series at first, to try out a minimal system,
and install the rest later.
The amount of disk space required for installing the SLS release
depends on how many of the series you install. Table 2.1 summa-
rizes the disk space requirements for installing each SLS package.
Package Disk series Approximate space requirements
------------ -------------------- ------------------------------------
Tiny a 15 megabytes
Base a, b, c 45 megabytes
Main a, b, c, x 70 megabytes
Full a, b, c, x, d, s, t 90 megabytes
Table 2.1: SLS Disk Space Requirements
Also keep in mind that in addition to the space requirements
listed in Table 2.1, you'll need to set aside extra space for swap
(see Section 3.2.3) and for user accounts, free space to install new
software, and so on.
2.2.1 Getting SLS from the Internet
If you have access to the Internet, you can download the SLS distri-
bution via FTP from a number of sites. If you've never used FTP
before, see Appendix C for a quick tutorial. If you don't have In-
ternet access, you can get SLS either via mail or from a number of
BBS's worldwide; see sections 2.2.2 and 2.3 for more information.
2.2.1.1 Downloading the files
The two primary FTP sites from which to obtain the SLS distri-
bution are tsx-11.mit.edu and sunsite.unc.edu. In addition, a
large number of FTP sites around the world mirror these two_see
Appendix C for a listing of Linux FTP sites.
The SLS release is kept in the directory /pub/linux/SLS on
tsx-11.mit.edu, and in /pub/Linux/SLS on sunsite.unc.edu
(note that the filenames are case-sensitive).
You should download the following files. Be sure to use binary
mode when downloading them.
o If you boot from a 3.5" floppy, download the file a1.3. If you
boot from a 5.25" floppy, download a1.5 instead. These files
are images of the SLS a1 disk which is used for booting the
system (*Note: Some FTP sites have the files a1.3.Z and
a1.5.Z instead. These are compressed images of the a1 disk;
you'll need to use the UNIX uncompress command to uncom-
press it. We've requested that FTP sites leave the files a1.3
and a1.5 uncompressed for this step to be unnecessary for
those downloading to a non-UNIX machine; both tsx-11 and
sunsite should have them both in uncompressed format.).
Hereafter, we'll be referring to the files a1.3 and a1.5 simply
as "a1"_because you'll only be downloading one or the other.
o rawrite.exe: A DOS program to "raw write" a given file,
block by block, to an MS-DOS formatted floppy. You will
use rawrite to create the a1 disk.
Note that rawrite.exe may not be in the SLS directory,
but it should be somewhere nearby on the FTP site. On
sunsite.unc.edu, rawrite is found in:
/pub/Linux/SLS/DOSUTILS/rawrite2.exe
On tsx-11.mit.edu, rawrite is found in:
/pub/Linux/INSTALL/dos_utils/rawrite.exe
o The files in the a2, a3 and a4 directories. Be sure to keep
these files in separate directories when you download them.
Later, you'll simply copy these files to MS-DOS floppies, but
you don't want to get the a2, a3 and a4 files mixed up.
o If you plan to get any of the other series, you need to down-
load the files in their corresponding directories. For example,
if you're downloading the b disk series, grab the files in the
directories b1 through b7. As with a2 through a4, keep the
files in each directory separate as you download them.
o The files SLS.FAQ and SLS.README, which are text files giving
important information about the current release of SLS.
2.2.1.2 Transferring the files to MS-DOS
Once you have these files, transfer all of them to an MS-DOS sys-
tem, in order to create the installation disks (*Note: If you have
access to a UNIX machine with a floppy drive, you can create the
installation disks from there. See Section A.4.).
If you did not FTP the files directly to an MS-DOS system,
you may need to ask your local computer guru for information on
transfering the files to MS-DOS. The methods used to do this vary
from site to site.
2.2.1.3 Making the installation disks
To create the installation disks, you'll be using rawrite.exe as well
as the MS-DOS COPY command. First, be sure that you have one
MS-DOS formatted, blank floppy for each disk in the SLS series
that you downloaded (*Note: It is possible to install SLS directly
from your hard drive, instead of from floppies. See Section A.1
for more information.). All of the floppies must be formatted high
density (either 1.2Mb 5.25" or 1.44Mb 3.5").
The floppy used for the a1 disk must be the type of floppy that
you boot from on your system. To create the a1 disk, run the
command
C:\> rawrite
from MS-DOS. You should see something like
RaWrite 1.2 - Write disk file to raw floppy diskette
Enter source file name:
Specify the filename that you wish to rawrite (such as a1.3 or
a1.5), followed by the drive that you wish to write it to (either A:
or B:).
Enter source file name: a1.5
Enter destination drive: A:
Please insert a formatted diskette into drive A: and press
-ENTER- :
Press [return] and rawrite will copy the file to the disk in the
specified drive.
Number of sectors per track for this disk is 15
Writing image to drive A:. Press ^C to abort.
Track: 00 Head: 0 Sector: 1
...
Done.
Once rawrite is done, the floppy will no longer be accessible by
MS-DOS. The floppy has been completely overwritten with the a1
image, and is now a "Linux-format" floppy.
If you have problems with rawrite, make sure that the floppy is
MS-DOS formatted, high density. If the floppy has any bad sectors
you may just need to use another disk.
The rest of the disks are created using the MS-DOS copy com-
mand. All of these disks must be of the same type (either 3.5" or
5.25") and must be high-density MS-DOS formatted as well. Copy
all of the files from the a2 directory to a floppy labeled a2. For
example,
For example,
C:\A2> copy *.* A:
will copy all of the files in the directory C:\A2 to the disk in A:.
Repeat the procedure for the rest of the disks in the SLS dis-
tribution. Remember that you must have at least a1 through a4.
After you are finished creating the disks, you can install the soft-
ware. This is covered in Chapter 3.
2.2.2 Getting SLS via U.S. Mail
The SLS distribution is also available on floppy via U.S. Air or
Land mail. A small fee is charged on a per-disk basis, but this fee
is nominal and more than worth the service. This is a reliable way
to get the SLS distribution, even if you do have network access_it
saves you a lot of time downloading and creating the disks yourself.
To order, send a check or money order to:
Softlanding Software
910 Lodge Ave.
Victoria, B.C., Canada
V8X-3A8
By the beginning of 1993, they hope to take Visa and/or Mas-
tercard orders by telephone. Their number is +1 604 360 0188.
They do take international orders, so if you're not in the States
or Canada you can still get the SLS distribution by mail from this
address.
The charge is on a per disk basis. The complete distribution
(that is, all of the a, b, c, x, and t series) is currently 29 disks, but
more disks are added to the distribution on occasion.
The copying charge is $3.25/disk US ($4.00/disk Canadian).
For 3.5" disks, add $1.00/disk. There is also a $10.00 shipping and
handling charge. Table 2.2 summarizes the various packages and
prices.
Package #Disks Series 5.25" Disks 3.5" Disks
-------- ------- --------- ------------------------ ------------------------
Tiny 4 a US $23.00 (CDN $26.00) US $27.00 (CDN $30.00)
Base 16 a,b,c US $62.25 (CDN $74.00) US $78.00 (CDN $90.00)
Main 24 a,b,c,x US $88.00 (CDN $106.00) US $112.00 (CDN $130.00)
Full 29 a,b,c,x,t US $104.25 (CDN $126.00) US $133.25 (CDN $155.00)
Table 2.2: SLS by-mail disk prices
2.3 Getting Linux from BBSs
Using a modem and standard communications software, you can
also download Linux from a number of bulliten board systems (BB-
Ss) worldwide. You'll likely find a version of the SLS distribution
on these BBS sites, with each disk image packed into a PKZIP
.zip archive file. The PKUNZIP utility, used to unpack these files
before you transfer the files to floppies, should be easy to locate
(perhaps on the BBS itself).
For the most part, you can follow the directions for creating the
SLS floppies in Section 2.2.1.3 once you have downloaded the files.
Just be sure that the files on the a2, a3, etc. disks are expanded_
in other words, the SLS a2 contains a number of .tgz files. If
you download a single a2.zip from the BBS, you may need to use
PKUNZIP to get those .tgz files before you place them on the
floppy.
In any case, there should be a README describing how to load
and install the release of Linux found on the BBS. What version
and distribution of Linux you find on these BBS's is really up in the
air_we can make no guarantees that you'll find a particular release
in a particular format, or that the files on the BBS are up-to-date.
Every BBS is different.
If you're unfamiliar with downloading files from BBS's, it's real-
ly quite simple. You need a modem and communications software,
to begin with. The communications software should come with
complete instructions on how to dialup a BBS and how to down-
load software_the mechanism differs greatly depending on your
modem and your software. If all else fails, have a computer guru
near you show you how it's done.
Printed in Appendix D is a list of BBS sites which carry Linux
software. You should be able to find a BBS within reasonable
calling distance. If not, and if you don't have Internet access of
some kind, you may want to consider ordering the SLS distribution
of Linux via mail. See Section 2.2.2 for details.
Chapter 3
Installing Linux
In this chapter, we'll go through the steps of installing Linux, from
repartitioning your drive, to setting up the Linux filesystems, to
actually installing the software.
As you're partitioning your drive and installing Linux, it's al-
ways a good idea to take notes of every command you type and
what goes on during the process, just so you have something to
refer to when you run into those inevitable problems. Trust me;
it's worth the time it takes just to jot down notes while installing,
especially if you're a newcomer to Linux. If you have problems lat-
er and have to ask for help, having a list of exactly what commands
you typed and what the results were will be invaluable.
3.1 SLS installation overview
This is an overview of installing the SLS release of Linux. As
mentioned before, the basic ideas are applicable to distributions
other than SLS as well.
To install the SLS release, you're doing to do the following:
o Backup any software (for MS-DOS, OS/2, etc.) on your sys-
tem. (Section 3.2.3.)
o Repartition your drive to allocate space for Linux. (Sec-
tion 3.2.3.)
o Reinstall the original software on your system. (Section 3.2.3.)
o Boot the SLS a1 disk, and create partitions for Linux. (Sec-
tion 3.3.4.)
o Create filesystems on those partitions. (Section 3.3.7.)
o Finally, install the software. (Section 3.4.)
3.2 Repartitioning your Drive
As we have mentioned, in order to allocate space for Linux on your
hard drive(s), you'll need to repartition the drive(s), resizing any
existing partitions.
Until now, most users of 386 and 486 systems haven't had to
worry about partitioning their hard drive, or even running more
than one operating system on the same drive (unless you're an
OS/2 user). Thus, some explanation of hard drives and partitions
is probably in order.
3.2.1 Hard drive geometry
A typical hard drive consists physically of one or more circular
platters which rotate about a central axis. The read/write heads
move to specified place on the disk surface to access information.
There is typically one head on each side of every platter, which all
move in unison back and forth across the platter (that is, either
closer to the center of the disk, or closer to the outer edge).
The drive platters are divided into cylinders, which is the area
of each platter which can be accessed without moving the heads.
A cylinder is a barrel-shaped cross section of a disk, consisting of a
circular strip from each side of each platter. The part of a cylinder
which is the circular strip on a single platter is called a track.
Thus, if there are 3 platters in a given drive (stacked on each
other, like a sandwich), then you have a read/write head on each
side of each platter, to make up 6 heads. (In actuality, the outer
surface of the outermost platters don't usually have heads accessing
them, so in this case you'll have only 4 heads.)
Thus if you position the heads at a single radius from the center
of the disk, the area which they can access by rotating the platters
is one cylinder. A track is the area which one head can access.
Thus, for our drive with 4 heads, there are 4 tracks per cylinder.
Each track is divided into a number of pie-shaped sliced called
sectors, which are the smallest parts of the disk which can be read
or written at one time.
Therefore, the geometry of the disk is specified as
o The number of cylinders that the disk contains;
o The number of tracks per cylinder (same as the number of
heads);
o The number of sectors per track; and,
o The size of each sector (in bytes).
Some of these numbers will vary, but a typical disk might have
about 1000 cylinders, 6 heads, 15 or 20 sectors per track, and each
sector containing 512 bytes. The size of the disk is
(1000 cylinders) * (6 tracks per cylinder) * (15 sectors per
track) * (512 bytes per sector)
or 46,080,000 bytes (about 46 megs).
3.2.2 Partitions
Hard drives are divided into one or more partitions which are
sections of the hard drive set aside for some operating system to
use. The concept of a partition allows you to have, for instance,
MS-DOS running on one partition on your hard drive, and Linux
on another.
Many MS-DOS systems have only a single partition taking up
the entire drive. To MS-DOS, this partition is known as C:. If you
have more than one partition on your drive, MS-DOS names them
D:, E:, and so on. In a way, each partition acts like a separate hard
drive.
On the the first cylinder, first head, and first sector of the disk
is a 1-sector master boot record along with a partition table.
The boot record (as the name implies) is used to boot the system.
The partition table contains information about the locations and
sizes of your partitions.
There are three kinds of partitions: primary, extended, and
logical. Of these primary partitions are by far used most often.
However, because of a limit in the size of the partition table, you
can only have 4 primary partitions on any given drive.
The way around this 4 partition limit is to use an extended
partition. An extended partition doesn't hold any data by itself;
instead, it acts as a "container" for logical partitions. Therefore,
you could create one extended partition, covering the entire drive,
and within it create several logical partitions. However, you may
have only one extended partition per drive.
3.2.3 Resizing your current partitions
If your hard drive is currently taken up by partitions for other
operating systems, you'll need to delete and resize those partitions
to allocate space for Linux. If you don't have any other operating
systems installed (you're installing Linux on a clean system), you
can skip to Section 3.3.
There isn't any safe or reliable way to resize an existing partition
without deleting it. Therefore, before repartitioning your drive,
backup your system. After you have repartitioned the drive, you
can reinstall your original software from the backups. Also keep in
mind that because you'll be shrinking your original partitions, you
may not have space to reinstall everything.
How much space should you leave free for Linux? This depends
greatly on how much software you're installing, and how much free
space you want to leave yourself. In Section 3.3.2 we'll cover this
in detail.
Under MS-DOS, the program used to modify partitions is FDISK
(*Note: Instructions for modifying partitions for operating systems
other than MS-DOS are similar to those presented here. Refer
to the documentation for those systems, if applicable.) In order
to repartition, you should create an MS-DOS bootable "system
disk" which contains all of the necessary DOS utilities, including
FDISK.EXE and FORMAT.COM (*Note: You can format an MS-DOS
system disk with the command format /s A:.). Boot from this
disk, and run FDISK.
Use of FDISK should be self-explanatory, but consult your MS-
DOS documentation for details. When you start FDISK, use the
menu option to display the partition table, and write down the
information displayed there. It is important to keep a record of your
original setup in case you want to back out of the Linux installation.
To delete an existing partition, choose the fdisk menu option to
Delete an MS-DOS Partition or Logical DOS Drive. Specify
the type of partition that you wish to delete (primary, extended, or
logical) and the number of the partition. Verify all of the warnings.
Poof!
To create a new (smaller) partition for MS-DOS, just choose the
fdisk option Create an MS-DOS Partition or Logical DOS Drive.
Specify the type of partition (primary, extended, or logical), and
the size of the partition to create (specified in megabytes). fdisk
should create the partition and you're ready to roll.
After you're done using fdisk, you should exit the program and
reformat the new partition(s). For example, if you resized the first
DOS partition on your drive (C:) you should run the command
format /s C:
You may now reinstall your original software from backup.
A warning: When repartitioning, you should only use the ver-
sion of fdisk for the operating system that you are manipulating
partitions for. That is, you should not use MS-DOS's fdisk to
make partitions for Linux, and vice versa. In some cases, doing
so won't cause any damage, but will cause MS-DOS not to boot
correctly. For manipulating MS-DOS partitions, use MS-DOS's
version of fdisk, and for Linux partitions use Linux's version of
fdisk.
3.3 Creating your Linux Partitions and Filesystems
Setting up partitions for Linux is very similar to setting them up
for other operating systems such as MS-DOS. To create your Linux
partitions, you use the Linux version of the fdisk program. After
you create the partitions, you create filesystems on them, which
allows them to be used by the Linux system. Making a filesystem
is analogous to "formatting" a partition under MS-DOS.
Because your swap partition doesn't hold files, we call preparing
it "making the swap space".
3.3.1 Drives and partitions under Linux
Drives and partitions under Linux are given different names than
their MS-DOS counterparts. Under MS-DOS, floppy drives are
referred to as A: and B:, while hard drive partitions are named
C:, D:, and so on. Under Linux, the naming convention is quite
different, but easier to comprehend.
Device drivers, found in the directory /dev, are used to com-
municate with devices on your system (such as hard drives, mice,
and so on). For example, if you have a mouse on your system,
access to it is through the driver /dev/mouse.
Floppy drives, hard drives, and individual partitions are all
given device drivers through which you access them. Table 3.1
lists the names of these various device drivers.
Device Name
--------------------------------------------------- --------------
First floppy (A:) /dev/fd0
Second floppy (B:) /dev/fd1
First hard drive (entire drive) /dev/hda
First hard drive, primary partition 1 /dev/hda1
First hard drive, primary partition 2 /dev/hda2
First hard drive, primary partition 3 /dev/hda3
First hard drive, primary partition 4 /dev/hda4
First hard drive, logical partition 1 /dev/hda5
First hard drive, logical partition 2 /dev/hda6
.
.
.
Second hard drive (entire drive) /dev/hdb
Second hard drive, primary partition 1 /dev/hdb1
.
.
.
First SCSI hard drive (entire drive) /dev/sda
First SCSI hard drive, primary partition 1 /dev/sda1
.
.
.
Second SCSI hard drive (entire drive) /dev/sdb
Second SCSI hard drive, primary partition 1 /dev/sdb1
(and so on...)
Table 3.1: Linux partition names
A few notes about this table. Note that /dev/fd0 corresponds
to the first floppy drive (A: under MS-DOS) and /dev/fd1 corre-
sponds to the second floppy (B:).
Also, SCSI hard drives are handled differently than other drives.
IDE, MFM, and RLL drives are accessed through the devices /dev/hda,
/dev/hdb, and so on. The individual partitions on the drive /dev/hda
are /dev/hda1, /dev/hda2, and so on. However, SCSI drives are
named /dev/sda, /dev/sdb, etc., with partition names such as
/dev/sda1 and /dev/sda2.
Here's an example. Let's say that you have a single IDE hard
drive, with 3 primary partitions. The first two are set aside for
MS-DOS, and the third is an extended partition which has two
logical partitions, both for use by Linux. The devices referring to
these partitions would be:
First MS-DOS partition (C:) /dev/hda1
Second MS-DOS partition (D:) /dev/hda2
Extended partition /dev/hda3
First Linux logical partition /dev/hda5
Second Linux logical partition /dev/hda6
Note that /dev/hda4 is skipped; it corresponds to the fourth
primary partition, which we don't have. Logical partitions start
with /dev/hda5 and go on up.
3.3.2 Partition sizes for Linux
For Linux, you will need to create at least two partitions. One will
be used as the root partition, which contains the Linux software
(*Note: You may choose to create separate partitions for each part
of your Linux directory tree, using multiple filesystems. If you have
UNIX system administration experience, you may be able to par-
tition you drive more creatively. See Section A.3 for information.).
The second will be used as the swap partition, which acts as
virtual memory on your system (*Note: Instead of using a swap
partition, you may use a swap file. See Section A.5 for more infor-
mation.). Swap space is very important for Linux: it allows you to
run many more programs at once than you would be able to other-
wise. This is especially important if you're low on physical RAM,
or if you're running X Windows. Even if you have 16 megabytes
or more of physical RAM, using swap space on your hard drive is
a good idea.
The size of your root partition depends greatly on how much
software you're installing. Section 2.2 should give you an idea of the
diskspace requirements for the SLS distribution of Linux. For ex-
ample, a minimal SLS installation (only the a series disks) requires
about 15 megabytes for the root partition, while a full installation
requires 90 megabytes. You should also leave yourself room for
expansion_space to install new software, space for users, and so
on.
The size of your swap partition depends on the amount of phys-
ical RAM you have, and how much swap space you want. Swap
space is used as virtual memory by Linux. Remember that Linux
is a multitasking operating system; this allows you to run many
programs at once. Because the number of simultaneously running
programs may require more memory than you have, use of swap
space is vital. Also, the more swap space you have, the less Linux
will need to swap programs back and forth between real memory
and virtual memory.
It is generally suggested that you have twice the amount of swap
space than you have physical RAM. For example, if you have 4
megabytes of physical RAM, an 8-megabyte swap partition should
suffice. However, the decision is really up to you. If you have
16 megabytes or more of physical memory, an 8- or 16-megabyte
swap partition should be more than enough. However, your swap
partition cannot be larger than 16 megabytes. You can use multiple
swap partitions (up to 8) if you wish_if you'd like to have 32
megabytes of swap, simply create two 16-megabyte swap partitions.
3.3.3 Booting SLS
You are now ready to boot the SLS release on your system to start
the installation.
To boot SLS, simply boot the a1 disk on your system. While
booting, hold down the [ctrl] or [alt] key. You should see the
prompt
LILO
Followed by a boot menu.
At this point, you have two options: to boot the floppy with
the ramdisk enabled, or to boot without the ramdisk. If you have
at least 4 megs of RAM in your machine, then you can just press
[return] or type
ramdisk
to boot with the ramdisk enabled. This will speed up operations
while you're using the a1 disk. However, if you have only 2 megs
of RAM in your machine, you'll need to type
floppy
to boot without the ramdisk.
The other options on the menu are for installing the Mitsumi
CD-ROM release of SLS (see Section A.2) or for booting Linux
from the hard drive (after you've installed it).
As the system boots, you'll be asked to
Press <return> to see SVGA-modes available or <space> to continue
Press [space] to use the standard 80x25 mode (not all SVGA
modes work on all displays). There will be a short pause wile the
system uncompresses the kernel (you should see "Uncompressing
Linux" at the top of your screen. Also, there may be a 5-10 second
pause after the lp_init... line at bootup, while the system checks
for SCSI devices. Don't panic! Finally, you should see the message
Welcome to the SLS install/bootdisk.
and be given the login prompt
softland login:
Here, login as root (no password, of course).
softland login: root
softland:/#
To look at the installation information on the disk, use the com-
mand
softland:/# install.info
Instead, if you login as install, you will be presented with
an installation menu. In the following sections, we cover how to
install the system by hand, instead of using the SLS menus. This
is because manual installation is applicable to Linux distributions
other than SLS, and also because it's a good idea to know how to
use the commands directly (without the menu). However, the con-
cepts behind using the SLS install menu and using the commands
directly are the same.
3.3.4 Running fdisk
After booting Linux, run fdisk by typing
fdisk <drive>
where <drive> is the Linux device name of the drive you plan to
add partitions to (see Table 3.1 on page 26). For instance, if you
want to run fdisk on the first SCSI disk in your system, use the
command fdisk /dev/sda. /dev/hda (the first IDE drive) is the
default if you don't specify one.
If you are creating Linux partitions on two separate drives, run
fdisk once for each drive.
# fdisk /dev/hda
Command (m for help):
Here fdisk is waiting for a command; you can type m to get a list
of options.
Command (m for help): m
Command action
a toggle a bootable flag
d delete a partition
l list known partition types
m print this menu
n add a new partition
p print the partition table
q quit without saving changes
t change a partition's system id
u change display/entry units
v verify the partition table
w write table to disk and exit
x extra functionality (experts only)
Command (m for help):
The n command is used to create a new partition. Most of the other
options you won't need to worry about. To quit fdisk without
saving any changes, use the q command. To quit fdisk and write
the changes to the partition table to disk, use the w command.
The first thing you should do is display your current partition
table and write the information down, for later reference. Use the
p command.
Command (m for help): p
Disk /dev/hda: 16 heads, 38 sectors, 683 cylinders
Units = cylinders of 608 * 512 bytes
Device Boot Begin Start End Blocks Id System
/dev/hda1 * 1 1 203 61693 6 DOS 16-bit >=32M
Command (m for help):
In this example, we have a single DOS partition on /dev/hda1,
which is 61693 blocks (about 60 megs). This partition starts at
cylinder number 1, and goes to cylinder 203. We have a total of
683 cylinders in this disk; so there are 480 cylinders left to make
Linux partitions on.
To create a new partition, use the n command. In this example,
we'll create two primary partitions (/dev/hda2 and /dev/hda3,
respectively) for Linux.
Command (m for help): n
Command action
e extended
p primary partition (1-4)
Here, fdisk is asking the type of the partition to create: extended
or primary. In our example, we're creating only primary partitions,
so we choose p.
Partition number (1-4):
Fdisk will then ask for the partition to create; since partition 1 is
already used, our first Linux partition will be number 2.
Partition number (1-4): 2
First cylinder (204-683):
Now enter the starting cylinder number of the partition. Since
cylinders 204 through 683 are unused, we'll use the first available
one (number 204). There's no reason to leave empty space in be-
tween your partitions.
First cylinder (204-683): 204
Last cylinder or +size or +sizeM or +sizeK (204-683):
Fdisk is asking for the size of the partition to create. We can either
specify an ending cylinder number, or a size in bytes, kilobytes, or
megabytes. Since we want our partition to be 80 megs in size, we
specify +80M.
Last cylinder or +size or +sizeM or +sizeK (204-683): +80M
Warning: Linux cannot currently use 33090 sectors of this
partition
This warning can be ignored. Fdisk prints the warning because it's
an older program, and dates before the time that Linux partitions
were able to be larger than 64 megabytes.
Now we're ready to create our second Linux partition. For sake
of demonstration, we'll create it with a size of 10 megabytes.
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 3
First cylinder (474-683): 474
Last cylinder or +size or +sizeM or +sizeK (474-683): +10M
Lastly, we'll display the partition table. Again, write down all
of this information_especially the block sizes of your new parti-
tions. You'll need to know the sizes of the partitions when creating
filesystems, later.
Command (m for help): p
Disk /dev/hda: 16 heads, 38 sectors, 683 cylinders
Units = cylinders of 608 * 512 bytes
Device Boot Begin Start End Blocks Id System
/dev/hda1 * 1 1 203 61693 6 DOS 16-bit >=32M
/dev/hda2 204 204 473 82080 81 Linux/MINIX
/dev/hda3 474 474 507 10336 81 Linux/MINIX
As you can see, /dev/hda2 is now a partition of size 82080 block-
s (which corresponds to about 80 megabytes), and /dev/hda3 is
10336 blocks (about 10 megs).
Finally, we use the w command to write the changes to disk and
exit fdisk.
Command (m for help): w
#
Keep in mind that none of the changes you make while running
fdisk will take effect until you give the w command, so you can toy
with different configurations and only save them when you're done.
Also, if you want to quit fdisk at any time without saving the
changes, use the q command. Also remember that you shouldn't
modify partitions for any operating systems other than Linux with
the Linux fdisk program.
3.3.5 Rebooting the system
Before you create your filesystems, you need to reboot the system
in order for the changes to the partition table to take effect.
You should boot the system from the diskette or CD-ROM for
your distribution of Linux, as before. (You can't boot from the
hard drive, yet, because you haven't installed the Linux software).
Under Linux, you should never reboot the system with [ctrl-
alt-del] (the "Vulcan Nerve Pinch") or by pressing the reset button
on your system. This is because Linux, like other versions of UNIX,
buffers disk I/O in memory. The system only writes the memory
buffers to disk every 30 seconds or so. If you were to reset the
system before it was able to "sync" and write the information to
disk, you would corrupt the data on your hard drive.
To reboot your system, use the command
shutdown -r now
This will sync and reboot the system safely. If you only want to
shutdown the system (that is, so you can turn it off), give the
command
shutdown now
(without the -r).
3.3.6 Making the swap space
After you have created your Linux partitions, you are ready to
"format" them by creating a filesystem on the root partition, and
preparing the swap space on the swap partition.
First, let's create the swap space. Reboot the system, as de-
scribed above, and login as root. The command used to prepare
swap space is mkswap, and it takes the form
mkswap -c <partition> <size>
where <partition> is the name of the swap partition you have cre-
ated, and <size> is the size of the partition, in blocks (*Note: This
is the size as reported by fdisk, using the p menu option.). For
example, if your swap partition is on /dev/hda2 and is 8208 blocks
in size, use the command
# mkswap -c /dev/hda2 8208
The -c option tells mkswap to check for bad blocks on the partition
when creating the swap space.
3.3.7 Creating the filesystems
As mentioned previously, before you may use your Linux root par-
tition to store files, you must create a filesystem on it. There are
several types of filesystems available for Linux. The most common-
ly used filesystem type is the Linux Second Extended Filesys-
tem, or ext2fs_it is used by the majority of Linux users worldwide.
Because of the ext2fs's popularity, speed, and robustness, we'll on-
ly cover the creation of an ext2fs-type filesystem here (*Note: If
you're interested in using a filesystem type other than the ext2fs,
see the Linux FAQ. Information on obtaining the FAQ is found in
Appendix B.).
To create a filesystem on the Linux root partition, use the com-
mand
mke2fs -c <partition> <size>
where <partition> is the name of the Linux root partition, and
<size> is the size of the partition in blocks. For example, to create
a 60400-block filesystem on /dev/hda3, use the command
mke2fs -c /dev/hda3 60400
If you're creating more than one filesystem for Linux (see Sec-
tion A.3), you'll need to use the appropriate mke2fs command for
those partitions as well.
3.4 Installing SLS
The doinstall command is used to install SLS. It is relatively
straightforward, and prompts you for a number of options before
installing.
3.4.1 The SLS bootdisk
Before you begin, make sure you have in hand an MS-DOS for-
matted floppy, which will be used during the installation process
to create a Linux boot disk: essentially, a copy of the Linux kernel
used to boot your system (*Note: In Section 5.2.2, we'll cover how
to install LILO to boot your system from the hard drive. Booting
Linux from floppy is no big deal; once it's finished booting con-
trol is transferred to the hard drive, and the floppy isn't accessed
again.).
3.4.2 Using doinstall
The syntax of the doinstall command is
doinstall <partition> [<directory> <partition> ...]
The first <partition> is required: it is the partition which the root
filesystem is mounted on (such as /dev/hda2). The other argu-
ments are used to tell doinstall where to mount any additional
filesystems if you're using them. See Section A.3 for details on this
procedure.
For example, if your Linux root filesystem is on /dev/hda2, use
the command
softland:/# doinstall /dev/hda2
The doinstall command will step you through the installation
process. It will ask you what media to install from (e.g., floppy,
hard drive, CD-ROM, or network). Choose the appropriate option
(which is probably "floppy", unless you're installing from CD-ROM
or the hard drive. See Sections A.1 and A.2.)
doinstall will also ask you how much of the software to install,
depending on which disk sets you're installing.
Tiny base system a disk series only (15 megs)
Main base system a, b, and c series (45 megs)
Main base system + X11 a, b, c, and x series (70 megs)
Full system a, b, c, x, d, s, and t series (90 megs)
You can selectively install packages from the disk series during
the installation process_you need not install all of the software on
each disk series. Just answer "yes" to the question "Prompt for
each package?" when you run doinstall.
During the installation, if you receive numerous error mes-
sages such as "No space left on device", then you didn't create
filesystems large enough to hold the software. You should go back
and either repartition your drive to allocate more space, or being
the installation again (this time not installing as much of the soft-
ware). In any case, if you choose to reinstall SLS for some reason,
it is important that you redo the mke2fs command (i.e., re-create
your filesystems). This will delete any existing software on your
Linux partitions before you attempt to reinstall.
If everything goes well, then congratulations! You've just in-
stalled Linux on your system. Go have a Diet Coke or something_
you deserve it.
3.4.3 Rebooting the system
To boot Linux, simply boot the Linux boot disk that was created
during the installation procedure (not the a1 disk). Also, it's a
good idea to keep your SLS installation disks around_if you acci-
dentally trash your system, for example, you can use the SLS a1
disk to recover your files (with a little luck).
3.5 Now That You Have Linux Installed
You've probably run into a few problems along the way while trying
to install Linux. The most common problem is having corrupt
files on your installation disks, caused by either a mistake while
downloading or a mistake by the folks who put together the release
you're trying to install. Hopefully, however, all has gone well and
you now have a running Linux system.
The next few chapters will help you get aquainted with the
Linux system.
Chapter 4
Linux Tutorial
4.1 Introduction
New users of UNIX and Linux may be a bit intimidated by the
size and apparent complexity of the system before them. There
are many good books on using UNIX out there, for all levels of
expertise from novice to expert. However, none of these books
covers, specifically, an introduction to using Linux. While 95% of
using Linux is exactly like using other UNIX systems, the most
straightforward way to get going on your new system is with a
tutorial tailored for Linux. Herein is such a tutorial.
This chapter does not go into a large amount of detail or cover
many advanced topics. Instead, it is intended to get the new Linux
user running, on both feet, so that he or she may then read a more
general book about UNIX and understand the basic differences
between other UNIX systems and Linux.
Very little is assumed here, except perhaps some familiarity
with personal computer systems, and MS-DOS. However, even if
you're not an MS-DOS user, you should be able to understand
everything here. At first glance, UNIX looks a lot like MS-DOS
(after all, MS-DOS was modeled on the CP/M operating system,
which in turn was modeled on UNIX). However, only the very
superficial features of UNIX resemble MS-DOS in any way. Even
if you're completely new to the PC world, this tutorial should be
of help.
And, before we begin: Don't be afraid to experiment. The sys-
tem won't bite you. You can't destroy anything by working on the
system. UNIX has some amount of security built in, to prevent
"normal" users (the role which you will now assume) from damag-
ing files which are essential to the system. Even so, the absolute
worst thing that can happen is that you'll delete all of your files_
and you'll have to go back and re-install the system. So, at this
point, you have nothing to lose.
4.2 Basic UNIX Concepts
UNIX is a multitasking, multiuser operating system. This means
that there can be many people using one computer at the same
time, running many different applications. (This differs from MS-
DOS, where only one person can use the system at any one time.)
Under UNIX, for users to identify themselves to the system, they
must log in, which entails two steps: Entering your login name
(the name which the system identifies you as), and entering your
password, which is your personal secret key to logging into your
account. Because only you know your password, no one else can
login to the system under your username.
On traditional UNIX systems, the system administrator will
assign you a username and an initial password when you are given
an account on the system. However, because you are the system
administrator, you must set up your own account before you can
login_see Section 4.2.1, below. For the following discussions, we'll
use the imaginary username "larry".
In addition, each UNIX system has a hostname assigned to
it. It is this hostname that gives your machine a name, gives it
character and charm. The hostname is used to identify individual
machines on a network, but even if your machine isn't networked,
it should have a hostname. In Section 5.9.2 we'll cover setting
your system's hostname. For our examples, below, the system's
hostname is "mousehouse".
4.2.1 Creating an account
Before you can use the system, you must set up a user account
for yourself. This is because it's usually not a good idea to use the
root account for normal use. The root account should be reserved
for running priveleged commands and for maintaining the system,
as discussed in Section 5.1.
In order to create an account for yourself, you need to login as
root and use the useradd or adduser command. See Section 5.4
for information on this procedure.
4.2.2 Logging in
At login time, you'll see the a prompt resembling the following on
your screen:
mousehouse login:
Here, enter your username, and press the [Return] key. Our
hero, larry, would type the following:
mousehouse login: larry
Password:
Now, enter your password. It won't be echoed to the screen
when you login, so type carefully. If you mistype your password,
you'll see the message
Login incorrect
and you'll have to try again.
Once you have correctly entered the username and password,
you are officially logged into the system, and are free to roam.
4.2.3 Virtual consoles
The system's console is the monitor and keyboard connected di-
rectly to the system. (Because UNIX is a multiuser operating sys-
tem, you may have other terminals connected to serial ports on
your system, but these would not be the console.) Linux, like some
other versions of UNIX, provides access to virtual consoles (or
VC's), which allow you to have more than one login session from
your console at a time.
To demonstrate this, login to your system (as demonstrated
above). Now, press [alt-F2]. You should see the login: prompt
again. You're looking at the second virtual console_you logged
into the first. To switch back to the first VC, press [alt-F1]. Voila!
You're back to your first login session.
A newly-installed Linux system probably allows you to access
the first four VC's, using [alt-F1] through [alt-F4]. However, it is
possible to enable up to 12 VC's_one for each function key on your
keyboard. As you can see, use of VC's can be very powerful_you
can be working on several different VC's at once.
While the use of VC's is somewhat limiting (after all, you can
only be looking at one VC at a time), it should give you a feel for
UNIX's multiuser capabilities. While you're working on VC #1,
you can switch over to VC #2 and start working on something else.
4.2.4 Shells and commands
For most of your explorations in the world of UNIX, you'll be talk-
ing to the system through the use of a shell. A shell is just a
program which takes user input (e.g., commands which you type)
and translates them into instructions. This can be compared to
the COMMAND.COM program under MS-DOS, which does essentially
the same thing. The shell is just one interface to UNIX. There are
many possible interfaces_such as the X Window System, which
lets you run commands by using the mouse and keyboard in con-
junction.
As soon as you login, the system starts the shell, and you can
type commands to it. Here's a quick example. Here, Larry logs in,
and is left sitting at the shell prompt.
mousehouse login: larry
Password: larry's password
Welcome to Mousehouse!
/home/larry#
"/home/larry#" is the shell's prompt, indicating that it's ready
to take commands. (More on what the prompt itself means later.)
Let's try telling the system to do something interesting:
/home/larry# make love
make: *** No way to make target `love'. Stop.
/home/larry#
Well, as it turns out make was the name of an actual program
on the system, and the shell executed this program when given the
command. (Unfortunately, the system was being unfriendly.)
This brings us to one burning question: What are commands?
What happens when you type "make love"? The first word on the
command line, "make", is the name of the command to be executed.
Everything else on the command line is taken as arguments to this
command. Examples:
/home/larry# cp foo bar
Here, the name of the command is "cp", and the arguments are
"foo" and "bar".
When you type a command, the shell does several things. First
of all, it looks at the command name, and checks to see if it is
a command which is internal to the shell. (That is, a command
which the shell knows how to execute itself. There are a number
of these commands, and we'll go into them later.) The shell also
checks to see if the command is an alias, or substitute name, for
another command. If neither of these conditions apply, the shell
looks for a program, on the disk, with the command's name. If
it finds such a program, the shell runs it, giving the program the
arguments specified on the command line.
In our example, the shell looks for the program called make,
and runs it with the argument love. Make is a program often used
to compile large programs, and it takes as arguments the name of
a "target" to compile. In the case of "make love", we instructed
make to compile the target love. Because make can't find a target
by this name, it fails with a humorous error message, and we are
returned to the shell prompt.
What happens if we type a command to a shell, and the shell
can't find a program with the command name to run? Well, we
can try it:
/home/larry# eat dirt
eat: command not found
/home/larry#
Quite simply, if the shell can't find a program with the name given
on the command line (here, "eat"), it prints an error message which
should be self-explanatory. You'll often see this error message if you
mistype a command (for example, if you had typed "mkae love"
instead of "make love").
4.2.5 Logging out
Before we delve much further, we should tell you how to log out of
the system. At the shell prompt, use the command
/home/larry# exit
to logout. There are other ways of logging out as well, but this is
the most foolproof one.
4.2.6 Changing your password
You should also be aware of how to change your password. The
command passwd will prompt you for your old password, and your
new password. It will ask you to reenter the new password for
validation. Be careful not to forget your password_if you do, you
will have to ask the system administrator to reset it for you. (If
you're the system administrator, see Section 5.4.)
4.2.7 Files and directories
Under most operating systems (UNIX included), there is the con-
cept of a file, which is just a bundle of information which is given a
name (called a filename). Examples of files would be your history
term paper, an e-mail message, or an actual program which can be
executed. Essentially, anything which is saved on disk is saved in
an individual file.
Files are identified by their filenames. For example, the file
containing your history paper might be saved with the filename
history.txt. These names usually identify the file and its contents
in some form which is meaningful to you.
With the concept of files comes the concept of directories. A
directory is just a collection of files. It can be thought of as a
"folder" which contains many different files. Directories themselves
are given names, with which you can identify them. Furthermore,
directories are maintained in a tree-like structure; that is, directo-
ries may contain other directories.
A file may be referred to by its pathname, which is made up of
the filename, preceded by the name of the directory which contains
the file. For example, let's say that Larry has a directory called
papers, which contains three files: history-final, english-lit,
and masters-thesis. (Each of these three files contains informa-
tion for three of Larry's ongoing projects.) To refer to the file
english-lit, Larry can specify the file's pathname:
papers/english-lit
As you can see, the directory and file names are separated by a
single slash (/). MS-DOS users will find this convention familiar,
although in the MS-DOS world, the backslash (") is used instead.
As mentioned, directories can be nested within each other as
well. For example, let's say that Larry has another directory, within
papers, called notes. This directory contains the files math-notes
and cheat-sheet. The pathname of the file cheat-sheet would
be
papers/notes/cheat-sheet
Therefore, the pathname really is a "path" which you take to
locate a certain file. The directory above a given subdirectory is
known as the parent directory. Here, the directory papers is
the parent of the notes directory.
4.2.8 The directory tree
Most UNIX systems have a standard layout for files, so that system
resources and programs can be easily located. This layout forms
a directory tree, which starts at the "/" directory, also known as
"the root directory". Directly underneath / are some important
subdirectories: /bin, /etc, /dev, and /usr, among others. These
directories in turn contain other directories which contain system
configuration files, programs, and so on.
In particular, each user has a home directory, which is the
directory set aside for that user to store his or her files. In the
examples above, all of Larry's files (such as cheat-sheet and
history-final) were contained in Larry's home directory. Usual-
ly, user home directories are contained under /home, and are named
for the user who owns that directory. Therefore, Larry's home di-
rectory is /home/larry.
4.2.9 The current working directory
At any given time, commands that you type to the shell are given
in terms of your current working directory. You can think of
your working directory as the directory in which you are currently
"located". When you first login, your working directory is set to
your home directory_/home/larry in our case. Whenever you
reference a file, you may refer to it in relationship to your current
working directory, instead of specifying the full pathname of the
file.
Here's an example. Larry has the directory papers, and papers
contains the file history-final. If Larry wants to look at this file,
he can use the command
/home/larry# more /home/larry/papers/history-final
The more command simply displays a file, one screen at a time.
However, because Larry's current working directory is /home/larry,
he can instead refer to the file relative to his current location. The
command would be
/home/larry# more papers/history-final
Therefore, if you begin a filename (such as papers/final) with a
character other than "/", the system assumes that you're referring
to the file in terms relative to your current working directory. This
is known as a relative pathname.
On the other hand, if you begin a filename with a "/", the
system interprets this as a full pathname_that is, a pathname
including the entire path to the file, starting from the root directory,
/. This is known as an absolute pathname.
4.2.10 Referring to home directories
Under both Tcsh and Bash on Linux, your home directory can
be referred to using the tilde character ("~"). For example, the
command
/home/larry# more ~/papers/history-final
is equivalent to
/home/larry# more /home/larry/papers/history-final
The "~" character is simply replaced with the name of your home
directory by the shell.
In addition, you can specify other user's home directories with
the tilde as well. The pathname "~karl/letters" translates to
"/home/karl/letters" by the shell (if /home/karl is karl's home
directory). The use of the tilde is simply a shortcut; there is no di-
rectory named "~", it's just syntactic sugar provided by the shell.
4.3 First Steps into UNIX
4.3.1 Moving around
Now that we can login, and know how to refer to files using path-
names, how can we change our current working directory, to make
life easier?
The command for moving around in the directory structure is
cd, short for "change directory". You'll notice that many often-
used Unix commands are two or three letters. The usage of the cd
command is:
cd <directory>
where <directory> is the name of the directory which you wish to
change to.
As we said, when you login, you begin in your home directory.
If Larry wanted to move down into the papers subdirectory, he'd
use the command
/home/larry# cd papers
/home/larry/papers#
As you can see, Larry's prompt changes to reflect his current work-
ing directory (so he knows where he is). Now that he's in the
papers directory, he can look at his history final with the com-
mand
/home/larry/papers# more history-final
Now, Larry is stuck in the papers subdirectory. To move back
up to the parent directory, use the command
/home/larry/papers# cd ..
/home/larry#
(Note the space between the "cd" and the "..".) Every directory
has a subdirectory named ".." which refers to the parent directory.
Similarly, every directory has a subdirectory named "." which
refers to itself. Therefore, the command
/home/larry/papers# cd .
gets us nowhere.
You can also use absolute pathnames in the cd command. To
cd into Karl's home directory, we can use the command
/home/larry/papers# cd /home/karl
/home/karl#
Also, using cd with no argument will return you to your own
home directory.
/home/karl# cd
/home/larry#
4.3.2 Looking at the contents of directories
Now that you know how to move around directories you probably
think, "So what?" The basic skill of moving around directories is
fairly useless, so let's introduce a new command, ls. ls prints a
listing of files and directories, by default from your current direc-
tory. For example:
/home/larry# ls
Mail
letters
papers
/home/larry#
Here we can see that Larry has three entries in his current
directory: Mail, letters, and papers. This doesn't tell us much_
are these directories or files? We can use the -F option on the ls
command to tell us more.
/home/larry# ls -F
Mail/
letters/
papers/
/home/larry#
From the / appended to each filename, we know that these three
entries are in fact subdirectories.
Using ls -F may also append "*" to the end of a filename.
This indicates that the file is an executable, or a program which
can be run. If nothing is appended to the filename using ls -F,
the file is a "plain old file", that is, it's neither a directory, or an
executable.
In general, each UNIX command may take a number of options
in addition to other arguments. These options usually begin with
a "-", as demonstrated above with ls -F. The -F option tells ls
to give more information about the type of the files involved_in
this case, printing a / after each directory name.
If you give ls a directory name, it will print the contents of
that directory.
/home/larry# ls -F papers
english-lit
history-final
masters-thesis
notes/
/home/larry#
Or, for a more interesting listing, let's see what's in the system's
/etc directory.
/home/larry# ls /etc
Images ftpusers lpc rc.new shells
adm getty magic rc0.d startcons
bcheckrc gettydefs motd rc1.d swapoff
brc group mount rc2.d swapon
brc~ inet mtab rc3.d syslog.conf
csh.cshrc init mtools rc4.d syslog.pid
csh.login init.d pac rc5.d syslogd.reload
default initrunlvl passwd rmt termcap
disktab inittab printcap rpc umount
fdprm inittab.old profile rpcinfo update
fstab issue psdatabase securetty utmp
ftpaccess lilo rc services wtmp
/home/larry#
(For those MS-DOS users out there, notice how the filenames
can be longer than 8 characters, and can contain periods in any
position. It is even possible to have more than one period in a
filename.)
Let's cd up to the top of the directory tree, using "cd ..", and
then down to another directory: /usr/bin.
/home/larry# cd ..
/home# cd ..
/# cd usr
/usr# cd bin
/usr/bin#
You can also move into directories in multiple steps, as in cd
/usr/bin.
Try moving around various directories, using ls and cd. In
some cases, you may run into a foreboding "Permission denied"
error message. This is simply the concept of UNIX security kick-
ing in: in order to ls or to cd into a directory, you must have
permission to do so. We'll talk more about this in Section 4.9.
4.3.3 Creating new directories
It's time to learn how to create directories. This involves the use
of the mkdir command. Try the following:
/home/larry# mkdir foo
/home/larry# ls -F
Mail/
foo/
letters/
papers/
/home/larry# cd foo
/home/larry/foo# ls
/home/larry/foo#
Congrats! You've just made a new directory and moved into it.
Since there aren't any files in this new directory, let's learn how to
copy files from one place to another.
4.3.4 Copying files
Copying files is done with the command cp:
/home/larry/foo# cp /etc/termcap .
/home/larry/foo# cp /etc/shells .
/home/larry/foo# ls -F
shells termcap
/home/larry/foo# cp shells bells
/home/larry/foo# ls -F
bells shells termcap
/home/larry/foo#
The cp command copies the files listed on the command line to
the file or directory given as the last argument. Notice how we use
the directory "." to refer to the current directory.
4.3.5 Moving files
A new command named mv moves files, instead of copying them.
The syntax is very straightforward.
/home/larry/foo# mv termcap sells
/home/larry/foo# ls -F
bells sells shells
/home/larry/foo#
Notice how termcap no longer exists, but in its place is the file
sells. This can be used to rename files, as we have just done, but
also to move a file to a completely new directory.
Note: mv and cp will overwrite the destination file (if it already
exists) without asking you. Be careful when you move a file into
another directory: there may already be a file with the same name
in that directory, which you'll overwrite!
4.3.6 Deleting files and directories
You now have an ugly rhyme developing with the use of the ls
command. To delete a file, use the rm command. ("rm" stands for
"remove").
/home/larry/foo# rm bells sells
/home/larry/foo# ls -F
shells
/home/larry/foo#
We're left with nothing but shells, but we won't complain. Note
that rm by default won't prompt you before deleting a file_so be
careful.
A related command to rm is rmdir. This command deletes
a directory, but only if the directory is empty. If the directory
contains any files or subdirectories, rmdir will complain.
4.3.7 Looking at files
The commands more and cat are used for viewing the contents
of files. more displays a file, one screenful at a time, while cat
displays the whole file at once.
To look at the file shells, we can use the command
/home/larry/foo# more shells
In case you're interested what shells contains, it's a list of
valid shell programs on your system. On most systems, this in-
cludes /bin/sh, /bin/bash, and /bin/csh. We'll talk about these
different types of shells later.
While using more, press [Space] to display the next page of
text, and [b] to display the previous page. There are other com-
mands available in more as well, these are just the basics. Pressing
[q] will quit more.
Quit more and try cat /etc/termcap. The text will probably
fly by much too quickly for you to read it. The name "cat" actually
stands for "concatenate", which is the real use of the program. The
cat command can be used to concatenate the contents of several
files and save the result to another file. This will be discussed later.
4.3.8 Getting online help
Almost every UNIX system, Linux included, provides a facility
known as "manual pages", or "man pages" for short. These man
pages contain online documentation for all of the various system
commands, resources, configuration files, and so on.
The command used to access man pages is man. For example,
if you're interested in finding out about the other options of the ls
command, you can type
/home/larry# man ls
and the man page for ls will be displayed.
Unfortunately, most of the man pages out there are written
for those who already have some idea of what the command or
resource does. For this reason, man pages usually only contain
the hardcore technical details of the command, without a lot of
tutorial. However, man pages can be an invaluable resource for
jogging your memory if you forget the syntax of a command. Man
pages will also tell you a lot about the commands which we won't
tell you in this book.
I suggest that you try man for the commands we've already gone
over, and whenever I introduce a new command. You'll notice
some of these commands won't have man pages. This could be
for several reasons. For one, the man pages haven't been written
yet (the Linux Documentation Project is responsible for man pages
under Linux as well. We are gradually accumulating most of the
man pages available for the system). Secondly, the the command
might be an internal shell command, or an alias (as discussed in
Section 4.2.4), in which case it would not have a man page of its
own. One example is cd, which is a shell internal command. The
shell actually processes the cd_there is no separate program which
contains this command.
4.4 Summary of Basic Commands
This section introduces some of the most useful basic commands
on a UNIX system, including those covered in the last section.
Note that options usually begin with a "-", and in most cases
multiple one-letter options may be combined using a single "-". For
example, instead of using the command ls -l -F, it is adequate
to use ls -lF.
Instead of listing all of the options available for each of these
commands, we'll only talk about those which are useful or impor-
tant at this time. In fact, most of these commands have a large
number of options (most of which you'll never use). You can use
man to see the manual pages for each command, which list all of
the available options.
Also note that many of these commands take a list of files or
directories as arguments, denoted by "<file1> ...<fileN>". For
example, the cp command takes as arguments a list of files to copy,
followed by the destination file or directory. When copying more
than one file, the destination must be a directory.
cd Change the current working directory.
Syntax: cd <directory>
<directory> is the directory to change to. ("."
refers to the current directory, ".." the parent
directory.)
Example: cd ../foo sets the current directory to
../foo.
ls Displays information about the named files and
directories.
Syntax: ls <file1> <file2> ...<fileN>
Where <file1> through <fileN> are the filenames
or directories to list. Options: There are more
options than you want to think about. The most
commonly used are -F (used to display some infor-
mation about the type of the file), and -l (gives
a "long" listing including file size, owner, permis-
sions, and so on. This will be covered in detail
later.)
Example: ls -lF /home/larry will display the
contents of the directory /home/larry.
cp Copies file(s) to another file or directory.
Syntax: cp <file1> <file2> ...<fileN> <destination>
Where <file1> through <fileN> are the files to copy,
and <destination> is the destination file or direc-
tory.
Example: cp ../frog joe copies the file ../frog
to the file or directory joe.
mv Moves file(s) to another file or directory. This
command does the equivalent of a copy followed
by the deletion of the original. This can be used to
rename files, as in the MS-DOS command RENAME.
Syntax: mv <file1> <file2> ...<fileN> <destination>
Where <file1> through <fileN> are the files to move,
and <destination> is the destination file or direc-
tory.
Example: mv ../frog joe moves the file ../frog
to the file or directory joe.
rm Deletes files. Note that when files are deleted
under UNIX, they are unrecoverable (unlike MS-
DOS, where you can usually "undelete" the file).
Syntax: rm <file1> <file2> ...<fileN>
Where <file1> through <fileN> are the filenames to
delete.
Options: -i will prompt for confirmation before
deleting the file.
Example: rm -i /home/larry/joe /home/larry/frog
deletes the files joe and frog in /home/larry.
mkdir Creates new directories.
Syntax: mkdir <dir1> <dir2> ...<dirN>
Where <file1> through <fileN> are the directories
to create.
Example: mkdir /home/larry/test creates the
directory test under /home/larry.
rmdir This command deletes empty directories. When
using rmdir, your current working directory must
not be within the directory to be deleted.
Syntax: rmdir <dir1> <dir2> ...<dirN>
Where <file1> through <fileN> are the directories
to delete.
Example: rmdir /home/larry/papers deletes the
directory /home/larry/papers, if it is empty.
man Displays the manual page for the given command
or resource (that is, any system utility which isn't
a command, such as a library function.) Syntax:
man <command>
Where <command> is the name of the command
or resource to get help on.
Example: man ls gives help on the ls command.
more Displays the contents of the named files, one screen-
ful at a time.
Syntax: more <file1> <file2> ... <fileN>
Where <file1> through <fileN> are the files to dis-
play.
Example: more papers/history-final displays
the file papers/history-final.
cat Officially used to concatenate files, cat is also used
to display the entire contents of a file at once.
Syntax: cat <file1> <file2> ...<fileN>
Where <file1> through <fileN> are the files to dis-
play.
Example: cat letters/from-mdw displays the file
letters/from-mdw.
echo Simply echoes the given arguments.
Syntax: echo <arg1> <arg2> ...<argN>
Where <arg1> through <argN> are the arguments
to echo.
Example: echo "Hello world" displays the string
"Hello world".
grep Display all of the lines in the named file(s) match-
ing the given pattern.
Syntax: grep <pattern> <file1> <file2> ...<fileN>
Where <pattern> is a regular expression pattern,
and <file1> through <fileN> are the files to search.
Example: grep loomer /etc/hosts will display
all lines in the file /etc/hosts which contain the
pattern "loomer".
4.5 Exploring the File System
The file system is the collection of files and the hierarchy of di-
rectories on your system. I promised before to escort you around
the filesystem and the time has come.
First, change to the root directory (cd /), and do an ls -F.
You'll probably see these directories (*Note: You may see others,
and you might not see all of them. Don't worry. Every release
of Linux differs in some respects.): bin, dev, etc, home, install,
lib, mnt, proc, root, tmp, user, usr, and var.
Let's take a look at each of these directories.
bin /bin is short for "binaries", or executables. This
is where many essential system programs reside.
Use the command "ls -F /bin" to list the files
here. If you look down the list you may see a few
commands that you recognize, such as cp, ls, and
mv. These are the actual programs for these com-
mands. When you use the cp command, you're
running the program /bin/cp.
Using ls -F, you'll see that most (if not all) of
the files in /bin have an asterisk ("*") appended
to their filenames. This indicates that the files are
executables, as described in Section 4.3.2.
/dev Next on our stop is /dev. Take a look, again with
ls -F.
The "files" in /dev are known as device drivers_
they are used to access system devices and re-
sources, such as disk drives, modems, memory, and
so on. For example, just as you can read data from
a file, you can read input from the mouse by accessing
/dev/mouse.
The filenames beginning with fd are floppy disk
devices. fd0 is the first floppy disk drive, fd1 the
second. Now, the astute among you will notice
that there are more floppy disk devices then just
the two I've listed above: they represent specific
types of floppy disks. For example, fd1H1440 will
access high-density, 3.5" diskettes in drive 1.
Here is a list of some of the most commonly used
device files. Note that even though you may not
have some of the devices listed below, the chances
are that you'll have entries in /dev for them any-
way.
o /dev/console refers to the system's console_
that is, the monitor connected directly to y-
our system.
o The various /dev/ttyS and /dev/cua devices
are used for accessing serial ports. For exam-
ple, /dev/ttyS0 refers to "COM1" under MS-
DOS. The /dev/cua devices are "callout" de-
vices, which are used in conjunction with a
modem.
o The device names beginning with hd access
hard drives. /dev/hda refers to the whole
first hard disk, while hda1 refers to the first
partition on /dev/hda.
o The device names beginning with sd are SC-
SI devices, such as SCSI hard drives, tape
drives, and so on. If you have a SCSI hard
drive, instead of accessing it through /dev/hda,
you would access /dev/sda.
o The device names beginning with lp access
parallel ports. /dev/lp0 refers to "LPT1" in
the MS-DOS world.
o /dev/null is used as a "black hole"_any da-
ta sent to this device is gone forever. Why
is this useful? Well, if you wanted to sup-
press the output of a command appearing on
your screen, you could send that output to
/dev/null. We'll talk more about this later.
o The device names beginning with /dev/tty
refer to the "virtual consoles" on your system
(accessed via by pressing [alt-F1], [alt-F2],
and so on). /dev/tty1 refers to the first VC,
/dev/tty2 refers to the second, and so on.
o The device names beginning with /dev/pty
are "pseudo-terminals". They are used to
provide a "terminal" to remote login sessions.
For example, if your machine is on a network,
incoming telnet logins would use one of the
/dev/pty devices.
/etc /etc contains just about everything which can be
labeled "et cetera"_many system configuration
files, programs, and utilities. Most of the pro-
grams found in /etc are for use by the system
administrator only. We'll cover these in depth in
Chapter 5.
/home /home contains user's home directories. For ex-
ample, /home/larry is the home directory for the
user "larry". On a newly-installed system, there
may not be any users in this directory.
/lib /lib contains shared library images. These
files contain code which many programs share in
common. Instead of each program containing its
own copy of these shared routines, they are all
stored in one common place, in /lib. This makes
executable files smaller, and saves space on your
system.
/proc /proc is a "virtual filesystem", the files in which
are stored in memory, not on the drive. They refer
to the various processes running on the system,
and allow you to get information about what pro-
grams and processes are running at any given time.
We'll go into more detail in Section 4.10.1.
/tmp Many programs have a need to generate some in-
formation and store it in a temporary file. The
canonical location for these files is in /tmp.
/usr /usr is a very important directory. It contains
a number of subdirectories which in turn contain
some of the most important and useful programs
and configuration files used on the system.
The various directories described above are essen-
tial for the system to operate, but most of the
things found in /usr are optional for the system.
However, it is those optional things which make
the system useful and interesting. Without /usr,
you'd more or less have a boring system, only with
programs like cp and ls. /usr contains most of
the larger software packages and the configuration
files which accompany them.
/usr/X386 /usr/X386 contains The X Window System, if y-
ou installed it. The X Window System is a large,
powerful graphical environment which provides a
large number of graphical utilities and program-
s, displayed in "windows" on your screen. If y-
ou're at all familiar with the Microsoft Windows
or Macintosh environments, X Windows will look
very familiar. The /usr/X386 directory contains
all of the X Windows executables, configuration
files, and support files. This will be covered in
more detail in Section 6.1.
/usr/adm /usr/adm contains various files of interest to the
system administrator, specifically system logs, which
record any errors or problems with the system.
Other files record logins to the system, as well
as failed login attempts. This will be covered in
Chapter 5.
/usr/bin /usr/bin is the real warehouse for software on any
UNIX system. It contains most of the executables
for programs not found in other places, such as
/bin.
/usr/etc Just as /etc contained miscellaneous system pro-
grams and configuration files, /usr/etc contains
even more of these utilities and files. In general,
the files found in /usr/etc are not essential to the
system, unlike those found in /etc, which are.
/usr/include /usr/include contains include files for the C
compiler. These files (most of which end in .h, for
"header") declare data structure names, subrou-
tines, and constants used when writing programs
in C. Those files found in /usr/include/sys are
generally used when programming on the UNIX
system level. If you are familiar with the C pro-
gramming language, here you'll find header files
such as stdio.h, which declares functions such as
printf().
/usr/g++-include
/usr/g++-include contains include files for the
C++ compiler (much like /usr/include).
/usr/lib /usr/lib contains the "stub" and "static" library
equivalents to the files found in /lib. When com-
piling a program, the program is "linked" with the
libraries found in /usr/lib, which then directs the
program to look in /lib when it needs the actu-
al code in the library. In addition, various other
programs store configuration files in /usr/lib.
/usr/local /usr/local is a lot like /usr_it contains vari-
ous programs and files not essential to the system,
but which make the system fun and exciting. In
general, those programs found in /usr/local are
specialized for your system specifically_that is,
/usr/local differs greatly between UNIX system-
s.
Here, you'll find large software packages such as
TEX (a document formatting system) and Emacs
(a large and powerful editor), if you installed them.
/usr/man This directory contains the actual man pages. There
are two subdirectories for every man page "sec-
tion" (use the command man man for details). For
example, /usr/man/man1 contains the source (that
is, the unformatted original) for man pages in sec-
tion 1, and /usr/man/cat1 contains the formatted
man pages for section 1.
/usr/spool /usr/spool contains files which are to be "spooled"
to another program. For example, if your machine
is connected to a network, incoming mail will be
stored in /usr/spool/mail, until you read it or
delete it. Outgoing or incoming news articles may
be found in /usr/spool/news, and so on.
/usr/src /usr/src contains the source code (the uncom-
piled program) for various programs on your sys-
tem. The most important thing here is /usr/src/linux,
which contains the source code for the Linux ker-
nel.
/usr/tmp Another directory used for temporary files, like
/tmp.
4.6 Types of shells
As I have mentioned too many times before, UNIX is a multitask-
ing, multiuser operating system. Multitasking is very useful, and
once you get used to it, you'll use it all of the time. Before long,
you'll be able to run programs in the "background", switch be-
tween multiple tasks, and "pipeline" programs together to achieve
complicated results with a single command.
Many of the features we'll be covering in this section are fea-
tures provided by the shell itself. Be careful not to confuse UNIX
(the actual operating system) with the shell_the shell is just an
interface to the underlying system. The shell provides a great deal
of functionality on top of UNIX itself.
The shell is not only an interpreter for your interactive com-
mands, which you type at the prompt. It is also a powerful pro-
gramming language, which allows you to write shell scripts, to
"batch" several shell commands together in a file. MS-DOS users
will recognize the similarity to "batch files". Use of shell scripts is
a very powerful tool, which will allow you to automate and expand
you usage of UNIX. See Section 4.11.1 for more information.
There are several types of shells in the UNIX world. The two
major types are the "Bourne shell" and the "C shell". The Bourne
shell uses a command syntax like the original shell on early UNIX
systems, such as System III. The name of the Bourne shell on most
UNIX systems is /bin/sh (where sh stands for "shell"). The C
shell (not to be confused with sea shell) uses a different syntax,
somewhat like the programming language C, and on most UNIX
systems is named /bin/csh.
Under Linux, there are several variations of these shells avail-
able. The two most commonly used are the Bourne Again Shell,
or "Bash" (/bin/bash), and Tcsh (/bin/tcsh). Bash is a form of
the Bourne shell with many of the advanced features found in the
C shell. Because Bash supports a superset of the Bourne shell syn-
tax, any shell scripts written in the standard Bourne shell should
work with Bash. For those who prefer to use the C shell syntax,
Linux supports Tcsh, which is an expanded version of the original
C shell.
The type of shell that you decide to use is mostly a religious
issue. Some folks prefer the Bourne shell syntax with the advanced
features of Bash, and some prefer the more structured C shell syn-
tax. As far as normal commands, such as cp and ls, are concerned,
the type of shell you're using doesn't matter_the syntax is the
same. Only when you start to write shell scripts or use some of
the advanced features of the shell do the differences between shell
types begin to matter.
As we're discussing some of the features of the shell, below, we'll
note those differences between Bourne and C shells. However, for
the purposes of this manual, most of those differences are minimal.
(If you're really curious at this point, read the man pages for bash
and tcsh).
4.7 Wildcards
A key feature of most Unix shells is the ability to reference more
than one filename using special characters. These so-called wild-
cards allow you to refer to, say, all filenames which contain the
character "n".
The wildcard "*" refers to any character or string of characters
in a filename. For example, when you use the character "*" in a
filename, the shell replaces it with all possible substitutions from
filenames in the directory which you're referencing.
Here's a quick example. Let's suppose that Larry has the files
frog, joe, and stuff in his current directory.
/home/larry# ls
frog joe stuff
/home/larry#
To access all files with the letter "o" in the filename, we can
use the command
/home/larry# ls *o*
frog joe
/home/larry#
As you can see, the use of the "*" wildcard was replaced with all
substitutions which matched the wildcard from filenames in the
current directory.
The use of "*" by itself simply matches all filenames, because
all characters match the wildcard.
/home/larry# ls *
frog joe stuff
/home/larry#
Here are a few more examples.
/home/larry# ls f*
frog
/home/larry# ls *ff
stuff
/home/larry# ls *f*
frog stuff
/home/larry# ls s*f
stuff
/home/larry#
The process of changing a "*" into filenames is called wild-
card expansion and is done by the shell. This is important: the
individual commands, such as ls, never see the "*" in their list of
parameters. The shell expands the wildcard to include all of the
filenames which match. So, the command
/home/larry# ls *o*
is expanded by the shell to actually be
/home/larry# ls frog joe
One important note about the "*" wildcard. Using this wild-
card will not match filenames which begin with a single period
("."). These files are treated as "hidden" files_while they are not
really hidden, they don't show up on normal ls listings, and aren't
touched by the use of the "*" wildcard.
Here's an example. We already mentioned that each directory
has two special entries in it: "." refers to the current directory,
and ".." refers to the parent directory. However, when you use
ls, these two entries don't show up.
/home/larry# ls
frog joe stuff
/home/larry#
If you use the -a switch with ls, however, you can display filenames
which begin with ".". Observe:
/home/larry# ls -a
. .. .bash_profile .bashrc frog joe stuff
/home/larry#
Now we can see the two special entries, "." and "..", as well as
two other "hidden" files_.bash_profile and .bashrc. These two
files are startup files used by bash when larry logs in. More on
them in Section 4.11.3.
Note that when we use the "*" wildcard, none of the filenames
beginning with "." are displayed.
/home/larry# ls *
frog joe stuff
/home/larry#
This is a safety feature: if the "*" wildcard matched filenames
beginning with ".", it would also match the directory names "."
and "..". This can be dangerous when using certain commands.
Another wildcard is "?". The "?" wildcard will only expand
a single character. Thus, "ls ?" will display all one character
filenames, and "ls termca?" would display "termcap" but not
"termcap.backup". Here's another example:
/home/larry# ls j?e
joe
/home/larry# ls f ??g
frog
/home/larry# ls ????f
stuff
/home/larry#
As you can see, wildcards allow you to specify many files at one
time. In the simple command summary, in Section 4.4, we said
that the cp and mv commands actually can copy or move multiple
files at one time. For example,
/home/larry# cp /etc/s* /home/larry
will copy all filenames in /etc beginning with "s" to the directory
/home/larry. Therefore, the format of the cp command is really
cp <file1> <file2> <file3> ...<fileN> <destination>
where <file1> through <fileN> is a list of filenames to copy, and
<destination> is the destination file or directory to copy them to.
mv has an identical syntax.
Note that if you are copying or moving more than one file, the
<destination> must be a directory. You can only copy or move a
single file to another file.
4.8 UNIX Plumbing
4.8.1 Standard input and output
Many UNIX commands get input from what is known as stan-
dard input and send their output to standard output (often
abbreviated as "stdin" and "stdout"). Your shell sets things up so
that standard input is your keyboard, and standard output is the
screen.
Here's an example using the command cat. Normally, cat
reads data from all of the filenames given on the command line and
sends this data directly to stdout. Therefore, using the command
/home/larry/papers# cat history-final masters-thesis
will display the contents of the file history-final followed by
masters-thesis.
However, if no filenames are given to cat as parameters, it
instead reads data from stdin, and sends it back to stdout. Here's
an example.
/home/larry/papers# cat
Hello there.
Hello there.
Bye.
Bye.
[ctrl-D]
/home/larry/papers#
As you can see, each line that the user types (displayed in italics)
is immediately echoed back by the cat command. When reading
from standard input, commands know that the input is "finished"
when they receive an EOT (end-of-text) signal. In general, this is
generated by pressing [ctrl-D].
Here's another example. The command sort reads in lines of
text (again, from stdin, unless files are given on the command line),
and sends the sorted output to stdout. Try the following.
/home/larry/papers# sort
bananas
carrots
apples
[ctrl-D]
apples
bananas
carrots
/home/larry/papers#
Now we can alphabetize our shopping list... isn't UNIX useful?
4.8.2 Redirecting input and output
Now, let's say that we wanted to send the output of sort to a file,
to save our shopping list elsewhere. The shell allows us to redirect
standard output to a filename, using the ">" symbol. Here's how
it works.
/home/larry/papers# sort > shopping-list
bananas
carrots
apples
[ctrl-D]
/home/larry/papers#
As you can see, the result of the sort command isn't displayed,
instead it's saved to the file shopping-list. Let's look at this file.
/home/larry/papers# cat shopping-list
apples
bananas
carrots
/home/larry/papers#
Now we can sort our shopping list, and save it, too! But let's
suppose that we were storing our unsorted, original shopping list
in the file items. One way of sorting the information and saving it
to a file would be to give sort the name of the file to read, in lieu
of standard input, and redirect standard output as we did above.
As so:
/home/larry/papers# sort items > shopping-list
/home/larry/papers# cat shopping-list
apples
bananas
carrots
/home/larry/papers#
However, there's another way of doing this. Not only can we redi-
rect standard output, but we can redirect standard input as well,
using the "<" symbol.
/home/larry/papers# sort < items
apples
bananas
carrots
/home/larry/papers#
Technically, sort < items is equivalent to sort items, but the
former allows us to demonstrate the point: sort < items behaves
as if the data in the file items was typed to standard input. The
shell handles the redirection. sort wasn't given the name of the
file (items) to read; as far as sort is concerned, it was still read-
ing from standard input as if you had typed the data from your
keyboard.
This introduces the concept of a filter. A filter is a program
which reads data from standard input, processes it in some way, and
sends the processed data to standard output. Using redirection,
standard input and/or standard output can be referenced from
files. sort is a simple filter: it sorts the incoming data and sends
the result to standard output. cat is even simpler: it doesn't do
anything with the incoming data, it simply outputs whatever was
given to it.
4.8.3 Using pipes
We've already demonstrated how to use sort as a filter. However,
these examples assumed that you had data in a file somewhere, or
were willing to type the data to standard input yourself. What
if the data you wanted to sort came from the output of another
command, such as ls? For example, using the -r option with
sort sorts the data in reverse-alphabetical order. If you wanted to
list the files in your current directory in reverse order, one way to
do it would be:
/home/larry/papers# ls
english-list
history-final
masters-thesis
notes
/home/larry/papers# ls > file-list
/home/larry/papers# sort -r file-list
notes
masters-thesis
history-final
english-list
/home/larry/papers#
Here, we saved the output of ls in a file, and then ran sort -r on
that file. But this is unwieldy and causes us to use a temporary
file to save the data from ls.
The solution is to use pipelining. Pipelining is another feature
of the shell which allows you to connect a string of commands in
a "pipe", where the stdout of the first command is sent directly
to the stdin of the second command, and so on. Here, we wish to
send the stdout of ls to the stdin of sort. The "|" symbol is used
to create a pipe:
/home/larry/papers# ls | sort -r
notes
masters-thesis
history-final
english-list
/home/larry/papers#
This command is much shorter, and obviously easier to type.
Another useful example---using the command
/home/larry/papers# ls /usr/bin
is going to display a long list a files, most of which will fly past the
screen too quickly for you to read them. Instead, let's use more to
display the list of files in /usr/bin.
/home/larry/papers# ls /usr/bin | more
Now you can page down the list of files at your own leisure.
But the fun doesn't stop here! We can pipe more than two
commands together. The command head is a filter which displays
the first lines from an input stream (here, input from a pipe). If
we wanted to display the last filename in alphabetical order in the
current directory, we can use:
/home/larry/papers# ls | sort -r | head -1
notes
/home/larry/papers#
where head -1 simply displays the first line of input that it receives
(in this case, the stream of reverse-sorted data from ls).
4.8.4 Non-destructive redirection
Using ">" to redirect output to a file is destructive: in other words,
the command
/home/larry/papers# ls > file-list
overwrites the contents of the file file-list. If, instead, you redi-
rect with the symbol ">>", the output will be appended to the
named file, instead of overwriting it.
/home/larry/papers# ls >> file-list
will append the output of the ls command to file-list.
Just keep in mind that redirection and using pipes are features
provided by the shell_the shell provides this handy syntax using
">" and ">>" and "_". It has nothing to do with the commands
used themselves, but the shell.
4.9 File Permissions
4.9.1 Concepts of file permissions
Because there are multiple users on a UNIX system, in order to
protect individual user's files from tampering by other users, UNIX
provides a mechanism known as file permissions. This mechanis-
m allows files and directories to be "owned" by a particular user.
As an example, because Larry created the files in his home direc-
tory, Larry owns those files, and has access to them.
UNIX also allows files to be shared between users and groups of
users. If Larry so desired, he could cut off access to his files, such
that no other user could access them. However, on most systems
the default is to allow other users to read your files, but not modify
or delete them in any way.
As explained above, every file is owned by a particular user.
However, files are also owned by a particular group, which is a
system-defined group of users. Every user is placed into at least
one group when that user is created. However, the system admin-
istrator may also grant the user access to more than one group.
Groups are usually defined by the type of users which access the
machine. For example, on a university UNIX system, users may be
placed into the groups student, staff, faculty or guest. There
are also a few system-defined groups (such as bin and admin) which
are used by the system itself to control access to resources_very
rarely do actual users belong to these system groups.
Permissions fall into three main divisions: read, write, and ex-
ecute. These permissions may be granted to three classes of users:
the owner of the file, the group to which the file belongs, and to all
users, regardless of group.
Read permission allows a user to read the contents of the file, or
in the case of directories, to list the contents of the directory (using
ls). Write permission allows the user to write to and modify the
file. For directories, write permission allows the user to create new
files or delete files within that directory. Finally, execute permission
allows the user to run the file as a program or shell script (if the file
happens to be a program or shell script, that is). For directories,
having execute permission allows the user to cd into the directory
in question.
4.9.2 Interpreting file permissions
Let's look at an example to demonstrate file permissions. Using
the ls command with the -l option will display a "long" listing of
the file, including file permissions.
/home/larry/foo# /home/larry/foo# ls -l stuff
-rw-r--r-- 1 larry users 505 Mar 13 19:05 stuff
/home/larry/foo#
The first field printed in the listing represents the file permis-
sions. The third field is the owner of the file (larry), and the fourth
field is the group to which the file belongs (users). Obviously, the
last field is the name of the file (stuff), and we'll cover the other
fields later.
This file is owned by larry, and belongs to the group users.
Let's look at the file permissions. The string -rw-r--r-- lists, in
order, the permissions granted to the file's owner, the file's group,
and everybody else.
The first character of the permissions string ("-") represents the
type of file. A "-" just means that this is a regular file (as opposed
to a directory or device driver). The next three letters ("rw-")
represent the permissions granted to the file's owner, larry. The
"r" stands for "read" and the "w" stands for "write". Thus, larry
has read and write permission to the file stuff.
As we mentioned, besides read and write permission, there is
also "execute" permission_represented by an "x". However, there
is a "-" here in place of the "x", so Larry doesn't have execute
permission on this file. This is fine, the file stuff isn't a program
of any kind. Of course, because Larry owns the file, he may grant
himself execute permission for the file if he so desires. This will be
covered shortly.
The next three characters, r--, represent the group's permis-
sions on the file. The group which owns this file is users. Because
only an "r" appears here, any user which belongs to the group
users may read this file.
The last three characters, also r--, represent the permissions
granted to every other user on the system (other than the owner
of the file and those in the group users). Again, because only an
"r" is present, other users may read the file, but not write to it or
execute it.
Here are some other examples of group permissions.
-rwxr-xr-x The owner of the file may read, write, and execute
the file. Users in the file's group, and all other
users, may read and execute the file.
-rw------- The owner of the file may read and write the file.
No other user can access the file.
-rwxrwxrwx All users may read, write, and execute the file.
4.9.3 Dependencies
It is important to note that the permissions granted to a file also
depend on the permissions of the directory in which the file is
located. For example, even if a file is set to -rwxrwxrwx, other users
cannot access the file unless they have read and execute access to
the directory in which the file is located. For example, if Larry
wanted to restrict access to all of his files, he could simply set the
permissions on his home directory /home/larry to -rwx------.
In this way, no other user has access to his directory, and all files
and directories within it. Larry doesn't need to worry about the
individual permissions on each of his files.
In other words, to access a file at all, you must have read and
execute access to all directories along the file's pathname.
Usually, users on a UNIX system are very open with their files.
The usual set of permissions given to files is -rw-r--r--, which
will allow other users to read the file, but not change it in any way.
The usual set of permissions given to directories is -rwxr-xr-x,
which will allow other users to look through your directories, but
not create or delete files within them.
However, many users wish to keep other users out of their files.
Setting the permissions of a file to -rw------- will not allow any
other user to access the file. Likewise, setting the permissions of a
directory to -rwx------ will keep other users out of the directory
in question.
4.9.4 Changing permissions
The command chmod is used to set the permissions on a file. Only
the owner of a file may change the permissions on that file. The
syntax of chmod is:
chmod {a,u,g,o}{+,-}{r,w,x} <filenames>
Briefly, you supply one or more of all, user, group, or other.
Then you specify whether you are adding rights (+) or taking them
away (-). Finally, you specify one or more of read, write, and
execute. Some examples of legal commands are:
chmod a+r stuff
Gives all users read access to the file.
chmod +r stuff
Same as above_if none of a, u, g, or o is specified,
a is assumed.
chmod og-x stuff
Remove execute permission from users other than
the owner.
chmod u+rwx stuff
Allow the owner of the file to read, write, and
execute the file.
chmod o-rwx stuff
Remove read, write, and execute permission from
users other than the owner and users in the file's
group.
4.10 Job Control
4.10.1 Jobs and processes
Job control is a feature provided by many shells (Bash and Tcsh
included) which allows you to control multiple running commands,
or jobs, at once. Before we can delve much further, we need to
talk about processes.
Every time you run a program, you start what is known as a
process_which is just a fancy name for a running program. The
command ps displays a list of currently running processes. Here's
an example:
/home/larry# ps
PID TT STAT TIME COMMAND
24 3 S 0:03 (bash)
161 3 R 0:00 ps
/home/larry#
The PID listed in the first column is the process ID, a unique num-
ber given to every running process. The last column, COMMAND, is
the name of the running command. Here, we're only looking at
the processes which Larry is currently running (*Note: There are
many other processes running on the system as well_"ps -aux"
lists them all.). These are bash (Larry's shell), and the ps com-
mand itself. As you can see, bash is running concurrently with
the ps command. bash executed ps when Larry typed the com-
mand. After ps is finished running (after the table of processes is
displayed), control is returned to the bash process, which displays
the prompt, ready for another command.
A running process is known as a job to the shell. The terms
process and job are interchangeable. However, a process is usually
referred to as a "job" when used in conjunction with job control_
a feature of the shell which allows you to switch between several
independent jobs.
In most cases users are only running a single job at a time_that
being whatever command they last typed to the shell. However,
using job control, you can run several jobs at once, switching be-
tween them as needed. How might this be useful? Let's say that
you're editing a text file and need to suddenly interrupt your edit-
ing and do something else. With job control, you can temporarily
suspend the editor, and back at the shell prompt start to work on
something else. When you're done, you can start the editor back
up, and be back where you started, as if you never left the editor.
This is just one example. There are many practical uses for job
control.
4.10.2 Foreground and background
Jobs can either be in the foreground or in the background.
There can only be one job in the foreground at any one time. The
foreground job is the job which you interact with_it receives in-
put from the keyboard and sends output to your screen. (Unless,
of course, you have redirected input or output, as described in
Section 4.8). On the other hand, jobs in the background do not
receive input from the terminal_in general, they run along quietly
without need for interaction.
Some jobs take a long time to finish, and don't do anything
interesting while they are running. Compiling programs is one
such job, as is compressing a large file. There's no reason why
you should sit around being bored while these jobs complete their
tasks; you can just run them in the background. While the jobs
are running in the background, you are free to run other programs.
Jobs may also be suspended. A suspended job is a job that
is not currently running, but is temporarily stopped. After you
suspend a job, you can tell the job to continue, in the foreground
or the background as needed. Resuming a suspended job will not
change the state of the job in any way_the job will continue to
run where it left off.
Note that suspending a job is not equal to interrupting a job.
When you interrupt a running process (by hitting your interrupt
key, which is usually [ctrl-C]) (*Note: The interrupt key can be set
using the stty command. The default on most systems is [ctrl-C],
but we can't guarantee the same for your system.), it kills
the process, for good. Once the job is killed, there's no hope of
resuming it; you'll have to re-run the command. Also note that
some programs trap the interrupt, so that hitting [ctrl-C] won't
immediately kill the job. This is to allow the program to perform
any necessary cleanup operations before exiting. In fact, some
programs simply don't allow you to kill them with an interrupt
at all.
4.10.3 Backgrounding and killing jobs
Let's begin with a simple example. The command yes is a seem-
ingly useless command which sends an endless stream of y's to
standard output. (This is actually useful. If you piped the output
of yes to another command which asked a series of yes and no
questions, the stream of y's would confirm all of the questions.)
Try it out.
/home/larry# yes
y
y
y
y
y
The y's will continue ad infinitum. You can kill the process by
hitting your interrupt key, which is usually [ctrl-C]. So that we
don't have to put up with the annoying stream of y's, let's redirect
the standard output of yes to /dev/null. As you may remember,
/dev/null acts as a "black hole" for data. Any data sent to it will
disappear. This is a very effective method of quieting an otherwise
verbose program.
/home/larry# yes > /dev/null
Ah, much better. Nothing is printed, but the shell prompt doesn't
come back. This is because yes is still running, and is sending those
inane y's to /dev/null. Again, to kill the job, hit the interrupt
key.
Let's suppose that we wanted the yes command to continue to
run, but wanted to get our shell prompt back to work on other
things. We can put yes into the background, which will allow it to
run, but without need for interaction.
One way to put a process in the background is to append an
"&" character to the end of the command.
/home/larry# yes > /dev/null &
[1] 164
/home/larry#
As you can see, we have our shell prompt back. But what is this
"[1] 164"? And is the yes command really running?
The "[1]" represents the job number for the yes process.
The shell assigns a job number to every running job. Because yes
is the one and only job that we're currently running, it is assigned
job number 1. The "164" is the process ID, or PID, number given
by the system to the job. Either number may be used to refer to
the job, as we'll see later.
You now have the yes process running in the background, con-
tinuously sending a stream of y's to /dev/null. To check on the
status of this process, use the shell internal command jobs.
/home/larry# jobs
[1]+ Running yes >/dev/null &
/home/larry#
Sure enough, there it is. You could also use the ps command as
demonstrated above to check on the status of the job.
To terminate the job, use the command kill. This command
takes either a job number or a process ID number as an argument.
This was job number 1, so using the command
/home/larry# kill %1
will kill the job. When identifying the job with the job number,
you must prefix the number with a percent ("%") character.
Now that we've killed the job, we can use jobs again to check
on it:
/home/larry# jobs
[1]+ Terminated yes >/dev/null
/home/larry#
The job is in fact dead, and if we use the jobs command again
nothing should be printed.
You can also kill the job using the process ID (PID) number,
which is printed along with the job ID when you start the job. In
our example, the process ID is 164, so the command
/home/larry# kill 164
is equivalent to
/home/larry# kill %1
You don't need to use the "%" when referring to a job by its process
ID.
4.10.4 Stopping and restarting jobs
There is another way to put a job into the background. You can
start the job normally (in the foreground), stop the job, and then
restart it in the background. We'll demonstrate this below.
First, start the yes process in the foreground, as you normally
would:
/home/larry# yes > /dev/null
Again, because yes is running in the foreground, you shouldn't get
your shell prompt back.
Now, instead of interrupting the job with [ctrl-C], we'll suspend
the job. Suspending a job doesn't kill it: it only temporarily stops
the job until you restart it. To do this, you hit the suspend key,
which is usually [ctrl-Z].
/home/larry# yes > /dev/null
[ctrl-Z]
[1]+ Stopped yes >/dev/null
/home/larry#
While the job is suspended, it's simply not running. No CPU time
or memory is used for the job. However, you can restart the job,
which will cause the job to run again as if nothing ever happened.
It will continue to run where it left off.
To restart the job in the foreground, use the command fg (for
"foreground").
/home/larry# fg
yes >/dev/null
The shell prints the name of the command again so you're aware
of which job you just put into the foreground. Stop the job again,
with [ctrl-Z]. This time, use the command bg to put the job into
the background. This will cause the command to run just as if you
started the command with "&" as in the last section.
/home/larry# bg
[1]+ yes >/dev/null &
/home/larry#
And we have our prompt back. jobs should report that yes is
indeed running, and we can kill the job with kill as we did before.
How can we stop the job again? Using [ctrl-Z] won't work,
because the job is in the background. The answer is to put the job
in the foreground, with fg, and then stop it. As it turns out you
can use fg on either stopped jobs or jobs in the background.
There is a big difference between a job in the background and
a job which is stopped. A stopped job is not running_it's not
taking up CPU time or memory, and it's not doing any work. A
job in the background is running, and using memory, as well as
completing some task while you do other work. However, a job in
the background may try to display text on to your terminal, which
can be annoying if you're trying to work on something else. For
example, if you used the command
/home/larry# yes &
without redirecting stdout to /dev/null, a stream of y's would
be printed to your screen, without any way of interrupting it (you
can't use [ctrl-C] to interrupt jobs in the background). In order to
stop the endless y's, you'd have to use the kill command (without
being able to see what you're typing).
Another note. The fg and bg commands normally foreground
or background the job which was last stopped (indicated by a "+"
next to the job number when you use the command jobs). If you
are running multiple jobs at once, you can foreground or back-
ground a specific job by giving the job ID as an argument to fg or
bg, as in
/home/larry# fg %2
(to foreground job number 2), or
/home/larry# bg %3
(to background job number 3). You can't use process ID numbers
with fg or bg.
Furthermore, using the job number alone, as in
/home/larry# %2
is equivalent to
/home/larry# fg %2
Just remember that using job control is a feature of the shell.
The commands fg, bg and jobs are internal to the shell. If for
some reason you use a shell which does not support job control,
don't expect to find these commands available.
In addition, there are some aspects of job control which differ
between Bash and Tcsh. In fact, some shells don't provide job
control at all_however, most shells available for Linux support
job control.
4.11 Customizing your Environment
The shell provides many mechanisms to customize your work en-
vironment. As we've mentioned before, the shell is more than a
command interpreter_it is also a powerful programming language.
While writing shell scripts is an extensive subject, we'd like to in-
troduce you to some of the ways that you can simplify your work
on a UNIX system by using these advanced features of the shell.
As we have mentioned before, different shells use different syn-
taxes when executing shell scripts. For example, Tcsh uses a C-like
syntax, while Bourne shells use another type of syntax. In this sec-
tion, we won't be running into many of the differences between the
two, but we will assume that shell scripts are executed using the
Bourne shell syntax.
4.11.1 Shell scripts
Let's say that you use a series of commands often, and would like
to shorten the amount of required typing by grouping all of them
together into a single "command". For example, the commands
/home/larry# cat chapter1 chapter2 chapter3 > book
/home/larry# wc -l book
/home/larry# lp book
would concatenate the files chapter1, chapter2, and chapter3
and place the result in the file book. Then, a count of the number
of lines in book would be displayed, and finally book would be
printed with the lp command.
Instead of typing all of these commands, you could group them
into a shell script. We described shell scripts briefly in Sec-
tion 4.11.1. The shell script used to run all of these commands
would look like
#!/bin/sh
# A shell script to create and print the book
cat chapter1 chapter2 chapter3 > book
wc -l book
lp book
If this script was saved in the file makebook, you could simply use
the command
/home/larry# makebook
to run all of the commands in the script. Shell scripts are just plain
text files; you can create them with an editor such as emacs or vi.
Let's look at this shell script. The first line, "#!/bin/sh",
identifies the file as a shell script, and tells the shell how to execute
the script. It instructs the shell to pass the script to /bin/sh
for execution, where /bin/sh is the shell program itself. Why is
this important? On most UNIX systems, /bin/sh is a Bourne-
type shell, such as Bash. By forcing the shell script to run using
/bin/sh, we are ensuring that the script will run under a Bourne-
syntax shell (instead of, say, a C shell). This will cause your script
to run using the Bourne syntax even if you use Tcsh (or another C
shell) as your login shell.
The second line is a comment. Comments begin with the char-
acter "#" and continue to the end of the line. Comments are ignored
by the shell_they are commonly used to identify the shell script
to the programmer.
The rest of the lines in the script are just commands, as you
would type them to the shell directly. In effect, the shell reads each
line of the script and runs that line as if you had typed it at the
shell prompt.
Permissions are important for shell scripts. If you create a shell
script, you must make sure that you have execute permission on
the script in order to run it (*Note: When you create text files,
the default permissions usually don't include execute permission.).
The command
/home/larry# chmod u+x makebook
can be used to give yourself execute permission on the shell script
makebook.
4.11.2 Shell variables and the environment
The shell allows you to define variables, as most programming
languages do. A variable is just a piece of data which is given the
name.
Note that Tcsh, as well as other C-type shells, use a different
mechanism for setting variables than is described here. This dis-
cussion assumes the use of a Bourne shell, such as Bash (which
you're probably using). See the Tcsh man page for details.
When you assign a value to a variable (using the "=" operator),
you can access the variable by prepending a "$" to the variable
name, as demonstrated below.
/home/larry# foo="hello there"
The variable foo is given the value "hello there". You can now
refer to this value by the variable name, prefixed with a "$" char-
acter. The command
/home/larry# echo $foo
hello there
/home/larry#
produces the same results as
/home/larry# echo "hello there"
hello there
/home/larry#
These variables are internal to the shell. This means that only
the shell can access these variables. This can be useful in shell
scripts; if you need to keep track of a filename, for example, you
can store it in a variable, as above. Using the command set will
display a list of all defined shell variables.
However, the shell allows you to export variables to the en-
vironment. The environment is the set of variables which all
commands that you execute have access to. Once you define a
variable inside the shell, exporting it makes that variable part of
the environment as well. The export command is used to export
a variable to the environment.
Again, here we differ between Bash and Tcsh. If you're us-
ing Tcsh, another syntax is used for setting environment variables
(the setenv command is used). See the Tcsh man page for more
information.
The environment is very important to the UNIX system. It
allows you to configure certain commands just by setting variables
which the commands know about.
Here's a quick example. The environment variable PAGER is
used by the man command. It specifies the command to use to
display man pages one screenful at a time. If you set PAGER to be
the name of a command, it will use that command to display the
man pages, instead of more (which is the default).
Set PAGER to "cat". This will cause output from man to be
displayed to the screen all at once, without breaking it up into
pages.
/home/larry# PAGER="cat"
Now, export PAGER to the environment.
/home/larry# export PAGER
Try the command man ls. The man page should fly past your
screen without pausing for you.
Now, if we set PAGER to "more", the more command will be used
to display the man page.
/home/larry# PAGER="more"
Note that we don't have to use the export command after we
change the value of PAGER. We only need to export a variable once;
any changes made to it thereafter will automatically be propagated
to the environment.
The man pages for a particular command will tell you if the
command uses any environment variables; for example, the man
man page explains that PAGER is used to specify the pager com-
mand. Some commands share environment variables; for example,
many commands use the EDITOR environment variable to specify
the default editor to use when one is needed.
The environment is also used to keep track of important infor-
mation about your login session. An example is the HOME environ-
ment variable, which contains the name of your home directory.
/home/larry/papers# echo $HOME
/home/larry
Another interesting environment variable is PS1, which defines
the main shell prompt. For example,
/home/larry# PS1="Your command, please: "
Your command, please:
To set the prompt back to our usual (which contains the current
working directory followed by a "#" symbol),
Your command, please: PS1="\w# "
/home/larry#
The bash man page describes the syntax used for setting the prompt.
4.11.2.1 The PATH environment variable
When you use the ls command, how does the shell know where
to find the ls executable itself? In fact, ls is found in /bin/ls
on most systems. The shell uses the environment variable PATH to
locate executable files for commands which you type.
For example, your PATH variable may be set to:
/bin:/usr/bin:/usr/local/bin:.
This is a list of directories for the shell to search, each directory
separated by a ":". When you use the command ls, the shell first
looks for /bin/ls, then /usr/bin/ls, and so on.
Note that the PATH has nothing to do with finding regular files.
For example, if you use the command
/home/larry# cp foo bar
The shell does not use PATH to locate the files foo and bar_those
filenames are assumed to be complete. The shell only uses PATH to
locate the cp executable.
This saves you a lot of time; it means that you don't have to
remember where all of the command executables are stored. On
many systems, executables are scattered about in many places,
such as /usr/bin, /bin, or /usr/local/bin. Instead of giving the
command's full pathname (such as /usr/bin/cp), you can sim-
ply set PATH to the list of directories that you want the shell to
automatically search.
Notice that PATH contains ".", which is the current working
directory. This allows you to create a shell script or program and
run it as a command from your current directory, without having to
specify it directly (as in ./makebook). If a directory isn't on your
PATH, then the shell will not search it for commands to run_this
includes the current directory.
4.11.3 Shell initialization scripts
In addition to shell scripts that you create, there are a number of
scripts that the shell itself uses for certain purposes. The most
important of these are your initialization scripts, scripts auto-
matically executed by the shell when you login.
The initialization scripts themselves are simply shell scripts, as
described above. However, they are very useful in setting up your
environment by executing commands automatically when you lo-
gin. For example, if you always use the mail command to check
your mail when you login, you place the command in your initial-
ization script so it will be executed automatically.
Both Bash and Tcsh distinguish between a login shell and
other invocations of the shell. A login shell is a shell invoked at
login time; usually, it's the only shell which you'll use. However, if
you "shell out" of another program, such as vi, you start another
instance of the shell, which isn't your login shell. In addition,
whenever you run a shell script, you automatically start another
instance of the shell to execute the script.
The initialization files used by Bash are: /etc/profile (set up
by the system administrator, executed by all Bash users at login
time), $HOME/.bash_profile (executed by a login Bash session),
and $HOME/.bashrc (executed by all non-login instances of Bash).
Tcsh uses the following initialization scripts: /etc/login.csh
(executed by all Tcsh users at login time), $HOME/.tcshrc (execut-
ed a login time and by all new instances of Tcsh), and $HOME/.login
(executed at login time, following .tcshrc).
To fully understand the function of these files, you'll need to
learn more about the shell itself. Shell programming is a compli-
cated subject, far beyond the scope of this book. See the man
pages for bash and/or tcsh to learn more about customizing your
shell environment.
4.12 So You Want to Strike Out on Your Own?
Hopefully we have provided enough information to give you a ba-
sic idea of how to use the system. Keep in mind that most of the
interesting and important aspects of Linux aren't covered here_
these are the very basics. With this foundation, before long you'll
be up and running complicated applications and fulfilling the po-
tential of your system. If things don't seem exciting at first, don't
despair_there is much to be learned.
One indispensable tool for learning about the system is to read
the man pages. While many of the man pages may appear con-
fusing at first, if you dig beneath the surface there is a wealth of
information contained therein.
We also suggest reading a complete book on using a UNIX sys-
tem. There is much more to UNIX than meets the eye_unfortunately,
most of it is beyond the scope of this book. Some good UNIX books
to look at are listed in Appendix B.
Chapter 5
System Administration
This chapter is an overview to Linux system administration, in-
cluding a number of advanced features which aren't necessarily for
system administrators only. Just as every dog has its day, every
system has its administrator, and running the system is a very im-
portant and sometimes time-consuming job, even if you're the only
user on your system.
We have tried to cover here the most important things about
system administration you need to know when you use Linux, in
sufficient detail to get you comfortably started. In order to keep
it short and sweet, we have only covered the very basics, and have
skipped many an important detail. You should read the Linux Sys-
tem Administrator's Guide if you are serious about running Linux.
It will help you understand better how things work, and how they
hang together. At least skim through it so that you know what it
contains and know what kind of help you can expect from it.
5.1 About Root, Hats, and the Feeling of Power
As you know, UNIX differentiates between different users, so that
what they do to each other and to the system can be regulated
(one wouldn't want anybody to be able to read one's love letters,
for instance). Each user is given an account, which includes a
username, home directory, and so on. In addition to accounts giv-
en to real people, there are special system-defined accounts which
have special privileges. The most important of these is the root
account, for the username root.
5.1.1 The root account
Ordinary users are generally restricted so that they can't do harm
to anybody else on the system, just to themselves. File permissions
on the system are arranged such that normal users aren't allowed
to delete or modify files in directories shared by all users (such as
/bin and /usr/bin. Most users also protect their own files with
the appropriate file permissions so that other users can't access or
modify those files.
There are no such restrictions on root. The user root can read,
modify, or delete any file on the system, change permissions and
ownerships on any file, and run special programs, such as those
which partition the drive or create filesystems. The basic idea is
that the person or persons who run and take care of the system logs
in as root whenever it is necessary to perform tasks that cannot
be executed as a normal user. Because root can do anything, it is
easy to make mistakes that have catastrophic consequences when
logged in using this account.
For example, as a normal user, if you inadvertently attempt to
delete all of the files in /etc, the system will not permit you to do
so. However, when logged in as root, the system won't complain
at all. It is very easy to trash your system when using root. The
best way to prevent accidents is to:
o Sit on your hands before you press [return] on a command
which may cause damage. For example, if you're about to
clean out a directory, before hitting [return], re-read the
entire command and make sure that it is correct.
o Don't get accustomed to using root. The more comfortable
you are in the role of the root user, the more likely you are
to confuse your privileges with those of a normal user. For
example, you might think that you're logged in as larry,
when you're really logged in as root.
o Use a different prompt for the root account. You should
change root's .bashrc or .login file to set the shell promp-
t to something other than your regular user prompt. For
example, many people use the character "$" in prompts for
regular users, and reserve the character "#" for the root user
prompt.
o Only login as root when absolutely necessary. And, as soon
as you're finished with your work as root, log out. The less
you use the root account, the less likely you'll be to do dam-
age on your system.
Of course, there is a breed of UNIX hackers out there who use root
for virtually everything. But every one of them has, at some point,
made a silly mistake as root and trashed the system. The general
rule is, until you're familiar with the lack of restrictions on root,
and are comfortable using the system without such restrictions,
login as root sparingly.
Of course, everyone makes mistakes. Linus Torvalds himself
once accidentally deleted the entire kernel directory tree on his
system. Hours of work were lost forever. Fortunately, however,
because of his knowledge of the filesystem code, he was able to
reboot the system and reconstruct the directory tree by hand on
disk.
Put another way, if you picture using the root account as wear-
ing a special magic hat that gives you lots of power, so that you
can, by waving your hand, destroy entire cities, it is a good idea
to be a bit careful about what you do with your hands. Since it is
easy to move your hand in a destructive way by accident, it is not
a good idea to wear the magic hat when it is not needed, despite
the wonderful feeling.
5.1.2 Abusing the system
Along with the feeling of power comes the tendency to do har-
m. This is one of the grey areas of UNIX system administration,
but everyone goes through it at some point in time. Most users
of UNIX systems never have the ability to wield this power_on
university and business UNIX systems, only the highly-paid and
highly-qualified system administrators ever login is root. In fact,
at many such institutions, the root password is a highly guarded
secret: it is treated as the Holy Grail of the institution. A large
amount of hubbub is made about logging in as root; it is portrayed
as a wise and fearsome power, given only to an exclusive cabal.
This kind of attitude towards the root account is, quite sim-
ply, the kind of thing which breeds malice and contempt. Because
root is so fluffed-up, when some users have their first opportu-
nity to login as root (either on a Linux system or elsewhere),
the tendency is to use root's privileges in a harmful manner. I
have known so-called "system administrators" who read other us-
er's mail, delete user's files without warning, and generally behave
like children when given such a powerful "toy".
Because root has such privilege on the system, it takes a great
deal of maturity and self-control to use the account as it was
intended_to run the system. There is an unspoken code of honor
which exists between the system administrator and the users on
the system. How would you feel if your system administrator was
reading your e-mail or looking over your files? There is still no
strong legal precedent for electronic privacy on time-sharing com-
puter systems. On UNIX systems, the root user has the ability
to forego all security and privacy mechanisms on the system. It is
important that the system administrator develop a trusting rela-
tionship with the users on the system. I can't stress that enough.
5.1.3 Dealing with users
UNIX security is rather lax by design. Security on the system
was an afterthought_the system was originally developed in an
environment where users intruding upon other users was simply
unheard of. Because of this, even with security measures, there is
still the ability for normal users to do harm.
System administrators can take two stances when dealing with
abusive users: they can be either paranoid or trusting. The para-
noid system administrator usually causes more harm than he or she
prevents. One of my favorite sayings is, "Never attribute to malice
anything which can be attributed to stupidity." Put another way,
most users don't have the ability or knowledge to do real harm on
the system. 90% of the time, when a user is causing trouble on
the system (by, for instance, filling up the user partition with large
files, or running multiple instances of a large program), the user is
simply unaware that what he or she is doing is a problem. I have
come down on users who were causing a great deal of trouble, but
they were simply acting out of ignorance_not malice.
When you deal with users who are causing potential trouble,
don't be accusative. The old rule of "innocent until proven guilty"
still holds. It is best to simply talk to the user, and question
about the trouble, instead of causing a confrontation. The last
thing you want to do is be on the user's bad side. This will raise
a lot of suspicion about you_the system administrator_running
the system correctly. If a user believes that you distrust or dislike
them, they might accuse you of deleting files or breaching privacy
on the system. This is certainly not the kind of position that you
want to be in.
If you do find that a user has been attempting to "crack" the
system, or was intentionally doing harm to the system, don't return
the malicious behavior with malice of your own. Instead, simply
provide a warning_but be flexible. In many cases, you may catch
a user "in the act" of doing harm to the system_give them a
warning. Tell them not to let it happen again. However, if you
do catch them causing harm again, be absolutely sure that it is
intentional. I can't even begin to describe the number of cases
where it appeared as though a user was causing trouble, when in
fact it was either an accident or a fault of my own.
5.1.4 Setting the rules
The best way to run a system is not with an iron fist. That may
be how you run the military, but UNIX was not designed for such
discipline. It makes sense to lay down a simple and flexible set of
guidelines for users_but remember, the fewer rules you have, the
less chance there is of breaking them. Even if your rules for using
the system are perfectly reasonable and clear, users will always at
times break these rules without intending to. This is especially true
in the case of new UNIX users, who are just learning the ropes
of the system. It's not patently obvious, for example, that you
shouldn't download a gigabyte of files and mail them to everyone
on the system. Users need help understanding the rules, and why
they are there.
If you do specify usage guidelines for your system, make sure
that the reason behind a particular guideline is made clear. If you
don't, then users will find all sorts of creative ways to get around
the rule, and not know that they are in fact breaking it.
5.1.5 What it all means
We can't tell you how to run your system to the last detail. Most
of the philosophy depends on how you're using the system. If you
have many users, things are much different than if you only have
a few users, or if you're the only user on the system. However, it's
always a good idea_in any situation_to understand what being
the system administrator really means.
Being the system administrator doesn't make you a UNIX wiz-
ard. There are many system admins out there who know very
little about UNIX. Likewise, there are many "normal" users out
there who know more about UNIX than any system administrator
could. Also, being the system administrator does not allow you to
use malice against your users. Just because the system gives you
the privilege to mess with user files does not mean that you have
any right to do so.
Lastly, being the system administrator is really not a big deal.
It doesn't matter if your system is a little 386 or a Cray supercom-
puter. Running the system is the same, regardless. Knowing the
root password isn't going to get you money, fame, or girls. It will
allow you to maintain the system, and keep it running. That's it.
5.2 Booting the System
There are several ways to boot the system, either from floppy or
from the hard drive.
5.2.1 Using a boot floppy
Many people boot Linux using a "boot floppy" which contains a
copy of the Linux kernel. This kernel has the Linux root partition
coded into it, so it will know where to look on the hard drive for
the root filesystem. (The rdev command can be used to set the
root partition in the kernel image; see below.) This is the type of
floppy created by SLS during installation, for example.
To create your own boot floppy, first locate the kernel image
on your hard disk. It should be in the file /Image or /etc/Image.
Some installations use the file /vmlinux for the kernel.
You may instead have a compressed kernel. A compressed k-
ernel uncompresses itself into memory at boot time, and takes up
much less space on the hard drive. If you have a compressed kernel,
it may be found in the file /zImage or /etc/zImage.
Once you know where the kernel is, set the root device in the
kernel image to the name of your Linux root partition with the
rdev command. The format of the command is
rdev <kernel-name> <root-device>
where <kernel-name> is the name of the kernel image, and <root-
device> is the name of the Linux root partition. For example, to
set the root device in the kernel /etc/Image to /dev/hda2, use the
command
# rdev /etc/Image /dev/hda2
rdev can set other options in the kernel as well, such as the
default SVGA mode to use at boot time. Just use "rdev" with no
arguments to get a help message.
After setting the root device, you can simply copy the kernel
image to the floppy. Whenever copying data a floppy, it's a good
idea to MS-DOS format the floppy first. This lays down the sector
and track information on the floppy, so it can be detected as either
high or low density.
For example, to copy the kernel in the file /etc/Image to the
floppy in /etc/fd0, use the command
# cp /etc/Image /dev/fd0
This floppy should now boot Linux.
5.2.2 Using LILO
Another method of booting is to use LILO, a program which resides
in the boot sector of your hard disk. This program is executed when
the system is booted from the hard disk, and can automatically
boot up Linux from a kernel image stored on the hard drive itself.
LILO can also be used as a first-stage boot loader for several
operating systems, allowing you to select at boot time which
operating system (such as Linux or MS-DOS) to boot. When you
boot using LILO, the default operating system is booted unless you
press [ctrl], [alt], or [shift] during the bootup sequence. If you
press any of these keys, you will be provided with a boot prompt,
at which you type the name of the operating system to boot (such
as "linux" or "msdos"). If you press [tab] at the boot prompt, a
listing of available operating systems will be provided.
LILO is located in the directory /etc/lilo (if you have it).
The easy way to install LILO is to edit the configuration file,
/etc/lilo/config, and then run the command
# /etc/lilo/lilo
The LILO configuration file contains a "stanza" for each oper-
ating system that you want to boot. The best way to demonstrate
this is with an example LILO config file. The below setup is for
a system which has a Linux root partition on /dev/hda1, and an
MS-DOS partition on /dev/hda2.
# Tell LILO to modify the boot record on /dev/hda (the first
# non-SCSI hard drive). If you boot from a drive other than /dev/hda,
# change the following line.
boot = /dev/hda
# Name of the boot loader. No reason to modify this unless you're doing
# some serious hacking on LILO.
install = /etc/lilo/boot.b
# Have LILO perform some optimization.
compact
# Stanza for Linux root partition on /dev/hda1.
image = /etc/Image # Location of kernel
label = linux # Name of OS (for the LILO boot menu)
root = /dev/hda1 # Location of root partition
vga = ask # Tell kernel to ask for SVGA modes at boot time
# Stanza for MSDOS partition on /dev/hda2.
other = /dev/hda2 # Location of partition
table = /dev/hda # Location of partition table for /dev/hda2
label = msdos # Name of OS (for boot menu)
The first operating system stanza in the config file will be the
default OS for LILO to boot. You can select another OS to boot
at the LILO boot prompt, as discussed above.
The program /etc/lilo/QuickInst will ask you questions about
your setup and generate a LILO config file for you.
Remember that every time you update the kernel image on disk,
you should rerun /etc/lilo/lilo in order for the changes to be
reflected on the boot sector of your drive.
Also note that if you use the "root =" line, above, there's no
reason to use rdev to set the root partition in the kernel image.
LILO sets it for you at boot time.
The Linux FAQ (see Appendix B) provides more information
on LILO, including how to use LILO to boot with OS/2's Boot
Manager.
5.3 Shutting Down
Shutting down a Linux system is a bit tricky. Remember that
you should never just turn off the power or hit the reset switch
while the system is running. The kernel keeps track of disk I/O
in memory buffers. If you reboot the system without giving the
kernel the chance to write its buffers to disk, you can corrupt your
filesystems.
Other precautions are taken at shutdown time as well. All pro-
cesses are sent a signal, which allows them to die gracefully (writ-
ing and closing all files, and so on). Filesystems are unmounted for
safety. If you wish, the system can also alert users that the system
is going down and give them a change to log off.
The easiest way to shutdown is with the shutdown command.
The format of the command is
shutdown <time> <warning-message>
The <time> argument is the time to shutdown the system (in the
format hh:mm:ss), and <warning-message> is a message displayed
on all user's terminals before shutdown. Alternately, you can spec-
ify the <time> as "now", to shutdown immediately. The -r option
may be given to shutdown to reboot the system after shutting
down.
For example, to shutdown the system at 8:00pm, use the com-
mand
# shutdown -r 20:00
The command halt may be used to force an immediate shut-
down, without any warning messages or grace period. halt is useful
if you're the only one using the system, and want to shut down the
system and turn it off.
Don't turn off the power or reboot the system until you see the
message:
The system is halted
It is very important that you shutdown the system "cleanly" using
the shutdown or halt commands. On some systems, pressing [ctrl-
alt-del] will be trapped and cause a shutdown; on other systems,
however, using the "Vulcan nerve pinch" will reboot the system
immediately and may cause disaster.
5.4 Managing Users
Whether or not you have many users on your system, it's important
to understand the aspects of user management under Linux. Even
if you're the only user, you should presumably have a separate
account for yourself (an account other than root to do most of
your work).
Each person using the system should have his or her own ac-
count. It is seldom a good idea to have several people share the
same account. Not only is security an issue, but accounts are used
to uniquely identify users to the system. You need to be able to
keep track of who is doing what.
5.4.1 User management concepts
The system keeps track of a number of pieces of information about
each user. They are summarized below.
username The username is the unique identifier given to ev-
ery user on the system. Examples of usernames
are larry, karl, and mdw. Letters and digits may
be used, as well as the characters "_" (underscore)
and "." (period). Usernames are usually limited
to 8 characters in length.
user ID The user ID, or UID, is a unique number given
to every user on the system. The system usually
keeps track of information by UID, not username.
group ID The group ID, or GID, is the ID of the user's de-
fault group. In Section 4.9 we discussed group per-
missions; each user belongs to one or more groups
defined by the system administrator. More about
this below.
password The system also stores the user's encrypted pass-
word. The passwd command is used to set and
change user passwords.
full name The user's "real name" or "full name" is stored
along with the username. For example, the user
schmoj may have the name "Joe Schmo" in real
life.
home directory
The home directory is the directory in which the
user is initially placed at login time. Every user
should have his or her own home directory, usually
found under /home.
login shell The user's login shell is the shell which is started
for the user at login time. Examples are /bin/bash
and /bin/tcsh.
The file /etc/passwd contains this information about users.
Each line in the file contains information about a single user; The
format of each line is
username:encrypted password:UID:GID:full name:home directory:login shell
An example might be:
kiwi:Xv8Q981g71oKK:102:100:Laura Poole:/home/kiwi:/bin/bash
As we can see, the first field, "kiwi", is the username.
The next field, "Xv8Q981g71oKK", is the encrypted password.
passwords are not stored on the system in any human-readable
format. The password is encrypted using itself as the secret key.
In other words, you need to know the password to decrypt it. This
form of encryption is fairly secure.
Some systems use "shadow password" in which password infor-
mation is relegated to the file /etc/shadow. Because /etc/passwd
is world-readable, /etc/shadow provides some degree of extra se-
curity because it is not. Shadow password provides some other
features such as password expiration and so on; we will not go into
these features here.
The third field, "102", is the UID. This must be unique for
each user. The fourth field, "100", is the GID. This user belongs
to the group numbered 100. Group information, like user informa-
tion, is stored in the file /etc/group. See Section 5.4.5 for more
information.
The fifth field is the user's full name, "Laura Poole". The last
two fields are the user's home directory (/home/kiwi) and login
shell (/bin/bash), respectively. It is not required that the user's
home directory be given the same name as the username. It does
help identify the directory, however.
5.4.2 Adding users
When adding a user, there are several steps to be taken. First, the
user must be given an entry in /etc/passwd, with a unique user-
name and UID. The GID, fullname, and other information must
be specified. The user's home directory must be created, and the
permissions on the directory set so that the user owns the direc-
tory. Shell initialization files must be provided in the new home
directory and other system-wide configuration must be done (for
example, setting up a spool for incoming e-mail for the new user).
While it is not difficult to add users by hand (I do), when you
are running a system with many users it is easy to forget some-
thing. The easiest way to add users is to use an interactive program
which asks you for the required information and updates all of the
system files automatically. The name of this program is useradd
or adduser, depending on what software was installed. The man
pages for these commands should be fairly self-explanatory.
5.4.3 Deleting users
Similarly, deleting users can be accomplished with the commands
userdel or deluser depending on what software was installed on
the system.
If you'd like to temporarily "disable" a user from logging into
the system (without deleting the user's account), you can simply
add an asterisk ("*") to the first character of the password field in
/etc/passwd. For example, changing kiwi's /etc/passwd entry
to
kiwi:*Xv8Q981g71oKK:102:100:Laura Poole:/home/kiwi:/bin/bash
will restrict kiwi from logging in.
5.4.4 Setting user attributes
After you have created a user, you may need to change attributes
for that user, such as home directory or password. The easiest way
to do this is to change the values directly in /etc/passwd. To set
a user's password, use the passwd command. For example,
# passwd larry
will change larry's password. Only root may change other user's
password in this manner. Users can change their own passwords
with passwd as well.
On some systems, the commands chfn and chsh will be avail-
able to allow users to set their own fullname and login shell at-
tributes. If not, they will have to ask the system administrator to
change these attributes for them.
5.4.5 Groups
As we have mentioned, each user belongs to one or more groups.
The only real importance of group relationships pertains to file
permissions, as you'll recall from Section 4.9, each file has a "group
ownership" and a set of group permissions which defines how users
in that group may access the file.
There are several system-defined groups such as bin, mail, and
sys. Users should not belong to any of these groups; they are
used for system file permissions. Instead, users should belong to
an individual group such as users. If you want to be cute, you
can maintain several groups of users such as student, staff, and
faculty.
The file /etc/group contains information about groups. The
format of each line is
group name:password:GID:other members
Some example groups might be:
root::0:
users::100:mdw,larry
guest::200:
other::250:kiwi
The first group, root, is a special system group reserved for the
root account. The next group, users, is for regular users. It
has a GID of 100. The users mdw and larry are given access to
this group. Remember that in /etc/passwd each user was given a
default GID. However, users may belong to more than one group,
by adding their usernames to other group lines in /etc/group. The
groups command lists what groups you are given access to.
The third group, guest, is for guest users, and other is for
"other" users. The user kiwi is given access to this group as well.
As you can see, the "password" field of /etc/group is rarely
used. It is sometimes used to set a password on group access. This
is seldom necessary.
The commands addgroup or groupadd may be used to add
groups to your system. Usually, it's easier just to add entries in
/etc/group yourself, as no other configuration needs to be done
to add a group. To delete a group, simply delete its entry in
/etc/group.
5.5 Archiving and Compressing Files
Before we can talk about backups, we need to introduce the tools
used to archive software on UNIX systems.
5.5.1 Using tar
The tar command is most often used to archive software.
The format of the tar command is
tar <options> <file1> <file2> ...<fileN>
where <options> is the list of commands and options for tar, and
<file1> through <fileN> is the list of files to add or extract from the
archive.
For example, the command
# tar cvf backup.tar /etc
would pack all of the files in /etc into the tar archive backup.tar.
The first argument to tar_"cvf"_is the tar "command". "c"
tells tar to create a new archive file. The "v" option forces tar
into verbose mode_printing each filename as it is archived. The
"f" option tells tar that the next argument_backup.tar_is the
name of the archive to create. The rest of the arguments to tar
are the file and directory names to add to the archive.
The command
# tar xvf backup.tar
will extract the tar file backup.tar in the current directory. This
can sometimes be dangerous_when extracting files from a tar file,
old files are overwritten.
Furthermore, before extracting tar files it is important to know
where the files should be unpacked. For example, let's say you
archived the following files: /etc/hosts, /etc/group, and /etc/passwd.
If you use the command
# tar cvf backup.tar /etc/hosts /etc/group /etc/passwd
the directory name /etc/ is added to the beginning of each file-
name. In order to extract the files to the correct location, you
would need to use the following commands:
# cd /
# tar xvf backup.tar
because files are extracted with the pathname saved in the archive
file.
If, however, you archived the files with the command
# cd /etc
# tar cvf hosts group passwd
the directory name is not saved in the archive file. Therefore, you
would need to "cd /etc" before extracting the files. As you can
see, how the tar file is created makes a large difference in where
you extract it. The command
# tar tvf backup.tar
may be used to display an "index" of the tar file before unpacking
it. In this way you can see what directory the filenames in the
archive are stored relative to, and can extract the archive from the
correct location.
5.5.2 gzip and compress
Unlike archiving programs for MS-DOS, tar does not automatical-
ly compress files as it archives them. Therefore, if you are archiving
two 1-megabyte files, the resulting tar file will be two megabytes
in size. The gzip command may be used to compress a file (the
file to compress need not be a tar file). The command
# gzip -9 backup.tar
will compress backup.tar and leave you with backup.tar.gz, the
compressed version of the file. The -9 switch tells gzip to use the
highest compression factor.
The gunzip command may be used to uncompress a gzipped
file. Equivalently, you may use "gzip -d".
gzip is a relatively new tool in the UNIX community. For many
years, the compress command was used instead. However, because
of several factors (*Note: These factors include a software patent
dispute against the compress algorithm and the fact that gzip is
much more efficient than compress.), compress is being phased
out. However, you will still need to use compress every once in a
while.
compressed files end in the extension .Z. For example, backup.tar.Z
is the compressed version of backup.tar, while backup.tar.gz is
the gzipped version (*Note: To add further confusion, for some
time the extension .z (lowercase "z") was used for gzipped files.
The official gzip extension is now .gz.). The uncompress com-
mand is used to expand a compressed file; gunzip knows how to
handle compressed files as well.
5.5.3 Putting them together
Therefore, to archive a group of files and compress the result, you
can use the commands:
# tar cvf backup.tar /etc
# gzip -9 backup.tar
The result will be backup.tar.gz. To unpack this file, use the
reverse set of commands:
# gunzip backup.tar.gz
# tar xvf backup.tar
Of course always make sure that you are in the correct directory
before unpacking a tar file.
You can use some UNIX cleverness to do all of this on one
command line, as in the following:
# tar cvf - /etc | gzip -9c > backup.tar.gz
Here, we are sending the tar file to "-", which stands for tar's
standard output. This is piped to gzip, which compresses the
incoming tar file, and the result is saved in backup.tar.gz.
The -c option to gzip tells gzip to send its output to stdout,
which is redirected to backup.tar.gz.
A single command used to unpack this archive would be:
# gunzip -c backup.tar.gz | tar cvf -
Again, gunzip uncompresses the contents of backup.tar.gz and
sends the resulting tar file to stdout. This is piped to tar, which
reads "-", this time referring to tar's standard input.
Happily, the tar command also includes the -z option to auto-
matically compress/uncompress files on the fly. However, it does
this as per the compress algorithm_it does not use gzip.
For example, the command
# tar cvfz backup.tar.Z /etc
is equivalent to
# tar cvf backup.tar /etc
# compress backup.tar
Just as the command
# tar xvfz backup.tar.Z
may be used instead of
# uncompress backup.tar.Z
# tar xvf backup.tar
Refer to the man pages for tar and gzip for more information.
5.6 Using Floppies and Making Backups
Floppies are usually used as backup media. If you don't have a tape
drive connected to your system, floppy disks can be used (although
they are slower and somewhat less reliable).
You may also use floppies to hold individual filesystems_in this
way, you can mount the floppy to access the data on it.
5.6.1 Using floppies for backups
The easiest way to make a backup using floppies is with tar. The
command
# tar cvfzM /dev/fd0 /
will make a complete backup of your system using the floppy drive
/dev/fd0. The "M" option to tar allows the backup to be a mul-
tivolume backup; that is, when one floppy is full, tar will prompt
for the next. The command
# tar xvfzM /dev/fd0
can be used to restore the complete backup. This method can also
be used if you have a tape drive (/dev/rmt0) connected to your
system.
Note that using the method, you must settle for the compress
algorithm; tar doesn't use gzip with the "z" option. Several other
programs exist for making multiple-volume backups; the backflops
program on tsx-11.mit.edu may come in handy.
Making a complete backup of the system can be time- and
resource-consuming. Most system administrators use a incremental
backup policy, in which every month a complete backup is taken,
and every week only those files which have been modified in the last
week are backed up. In this case, if you trash your system in the
middle of the month, you can simply restore the last full monthly
backup, and then restore the last weekly backups as needed.
The find command can be useful in locating files which have
changed since a certain date. Several scripts for managing incre-
mental backups can be found on sunsite.unc.edu.
5.6.2 Using floppies as filesystems
You can create a filesystem on a floppy just as you would on a hard
drive partition. For example,
# mke2fs /dev/fd0 1440
creates a filesystem on the floppy in /dev/fd0. The size of the
filesystem must correspond to the size of the floppy. High-density
3.5" disks are 1.44 megabytes, or 1440 blocks, in size. High-density
5.25" disks are 1200 blocks.
In order to access the floppy, you must mount the filesystem
contained on it. The command
# mount -t ext2 /dev/fd0 /mnt
will mount the floppy in /dev/fd0 on the directory /mnt. Now,
all of the files on the floppy will appear under /mnt on your drive.
The "-t ext2" specifies an ext2fs filesystem type. If you created
another type of filesystem on the floppy, you'll need to specify its
type to the mount command.
The "mount point" (the directory where you're mounting the
filesystem) needs to exist when you use the mount command. If it
doesn't exist, simply create it with mkdir.
Note that any I/O to the floppy is buffered just as hard disk
I/O is. If you change data on the floppy, you may not see the drive
light come on until the kernel flushes its I/O buffers. It's important
that you not remove a floppy before you unmount it; this can be
done with the command
# umount /dev/fd0
Do not simply switch floppies as you would on an MS-DOS system;
whenever you change floppies, umount the first one and mount the
next.
5.7 Upgrading and Installing New Software
Another duty of the system administrator is upgrading and in-
stalling new software.
The Linux community is very dynamic. New kernel releases
come out every few weeks, and other software is updated almost
as often. Because of this, new Linux users often feel the need
to upgrade their systems constantly to keep up the the rapidly
changing pace. Not only is this unnecessary, it's a waste of time:
to keep up with all of the changes in the Linux world, you would be
spending all of your time upgrading and none of your time using
the system.
So, when should you upgrade? Some people feel that you should
upgrade when a new distribution release is made_for example,
when SLS comes out with a new version. Many Linux users com-
pletely reinstall their system with the newest SLS release every
time. This, also, is a waste of time. In general, changes to SLS
releases are small. Downloading and reinstalling 30 disks when
only 10% of the software has been actually modified is, of course,
pointless.
The best way to upgrade your system is to do it by hand: only
upgrade those software packages which you know that you should
upgrade. This scares a lot of people: they want to know what to
upgrade, and how, and what will break if they don't upgrade. In
order to be successful with Linux, it's important to overcome your
fears of "doing it yourself"_ which is what Linux is all about. In
fact, once you have your system working and all software correctly
configured, reinstalling with the newest SLS release will no doubt
wipe all of your configuration and things will be broken again, just
as they were when you first installed your system. Setting yourself
back in this manner is unnecessary_all that is needed is some
know-how about upgrading your system, and how to do it right.
You'll find that when you upgrade one component of your sys-
tem that other things should not break. For example, most of the
software on my system is left over from an ancient 0.96 MCC In-
terim installation. Yet, I run the newest version of the kernel and
libraries with this software with no problem. For the most part,
senselessly upgrading to "keep up with the trend" is not important
at all. This isn't MS-DOS or Microsoft Windows. There is no im-
portant reason to run the newest version of all of the software. If
you find that you would like or need features in a new version, then
upgrade. If not, then don't. In other words, only upgrade what
you have to, and when you have to. Don't just upgrade for the
sake of upgrading. That will waste a lot of time and effort trying
to keep up.
The most important software to upgrade on your system is the
kernel, the libraries, and the gcc compiler. These are the three
essential parts of your system, and in some cases they all depend
on each other for everything to work successfully. Most of the other
software on your system does not need to be upgraded periodically.
5.7.1 Upgrading the kernel
Upgrading the kernel is simply a matter of getting the sources and
compiling them yourself. You must compile the kernel yourself in
order to enable or disable certain features, as well as to ensure that
the kernel will be optimized to run on your machine. The process
is quite painless.
The kernel sources may be retrieved from any of the Linux FTP
sites (see Section C for a list). On sunsite.unc.edu, for instance,
the kernel sources are found in /pub/Linux/kernel. Kernel ver-
sions are numbered using a version number and a patchlevel. For
example, kernel version 0.99 patchlevel 11 is usually written as
0.99.pl11, or just 0.99.11.
The kernel sources are released as a gzipped tar file (*Note:
Often, a patch file is also released for the current kernel version
which allows you to patch your current kernel sources from the last
patchlevel to the current one (using the program patch). In most
cases, however, it's usually easier to install the entire new version of
the kernel sources). For example, the file containing the 0.99.pl11
kernel sources is linux-0.99.11.tar.gz.
Unpack this tar file from the directory /usr/src; it creates
the directory /usr/src/linux which contains the kernel sources.
You should delete or rename your existing /usr/src/linux before
unpacking the new version.
Once the sources are unpacked, you need to make sure that two
symbolic links in /usr/include are correct. To create these links,
use the commands
# ln -sf /usr/src/linux/include/linux /usr/include/linux
# ln -sf /usr/src/linux/include/asm /usr/include/asm
Once you have created these links once, there is no reason to create
them again when you install the next version of the kernel sources.
(See Section 5.9.3 for more about symbolic links.)
Note that in order to compile the kernel, you must have the
gcc and g++ C and C++ compilers installed on your system. You
may need to have the most recent versions of these compilers: see
Section 5.7.3, below, for more information.
To compile the kernel, first cd to /usr/src/linux. Run the
command make config. This command will prompt you for a
number of configuration options, such as what filesystem types you
wish to include in the new kernel.
Next, edit /usr/src/linux/Makefile. Be sure that the defini-
tion for ROOT_DEV is correct_it defines the device uses as the root
filesystem at boot time. The usual definition is
ROOT_DEV = CURRENT
Unless you are changing your root filesystem device, there is no
reason to change this.
Next, run the command make dep to fix all of the source de-
pendencies. This is a very important step.
Finally, you're ready to compile the kernel. The command make
Image will compile the kernel and leave the new kernel image in
the file /usr/src/linux/Image. Alternately, the command make
zImage will compile a compressed kernel image, which uncompress-
es itself at boot time and uses less drive space.
Once you have the kernel compiled, you need to either copy it to
a boot floppy (with a command such as "cp Image /dev/fd0") or
install it using LILO to boot from your hard drive. See Section 5.2.2
for more information.
5.7.2 Upgrading the libraries
As mentioned before, most of the software on the system is com-
piled to use shared libraries, which contain common subroutines
shared among different programs.
If you see the message
Incompatible library version
when attempting to run a program, then you need to upgrade to
the version of the libraries which the program requires. Libraries
are back-compatible; that is, a program compiled to use an older
version of the libraries should work with the new version of the
libraries installed. However, the reverse is not true.
The newest version of the libraries can be found on the Linux
FTP sites. On sunsite.unc.edu, they are located in /pub/Linux/GCC.
The "release" files there should explain what files you need to down-
load and how to install them. Briefly, you should get the files
image-version.tar.gz and inc-version.tar.gz where version is
the version of the libraries to install, such as 4.4.1. These are
gzipped tar files; the image file contains the library images to in-
stall in /lib and /usr/lib. The inc file contains include files to
install in /usr/include
The release-version.tar.gz should explain the installation
procedure in detail (the exact instructions vary for each release). In
general you need to install the library .a and .sa files in /usr/lib.
These are the libraries used at compilation time.
In addition, the shared library image files, libc.so.version are
installed in /lib. These are the shared library images loaded at
runtime by programs using the libraries. Each library has a sym-
bolic link using the major version number of the library in /lib.
For example, the libc library version 4.4.1 has a major version
number of 4. The file containing the library is libc.so.4.4.1. A
symbolic link of the name libc.so.4 is in also /lib pointing to
this file. You need to change this symbolic link when upgrading
the libraries. For example, when upgrading from libc.so.4.4 to
libc.so.4.4.1, you need to change the symbolic link to point to
the new version.
It is very important that you change the symbolic link in one
step, as given below. If you somehow delete the symbolic link
libc.so.4, then programs which depend on the link (including
basic utilities like ls and cat) will stop working. Use the following
command to update the symbolic link libc.so.4 to point to the
file libc.so.4.4.1:
# ln -sf /lib/libc.so.4.4.1 /lib/libc.so.4
You also need to change the symbolic link libm.so.version in the
same manner. If you are upgrading to a different version of the
libraries substitute to appropriate filenames above. The library
release notice should explain the details. (See Section 5.9.3 for
more information about symbolic links.)
5.7.3 Upgrading gcc
The gcc C and C++ compiler is used to compile software on your
system, most importantly the kernel. The newest version of gcc is
found on the Linux FTP sites. On sunsite.unc.edu, it is found
in the directory /pub/Linux/GCC (along with the libraries). There
should be a release file for the gcc distribution detailing what
files you need to download and how to install them.
5.7.4 Upgrading other software
Upgrading other software is usually just a matter of downloading
the appropriate files and installing them. Most software for Linux is
distributed at gzipped tar files, including either sources or binaries
or both. If binaries are not included in the release, you may need
to compile them yourself; usually, this means typing make in the
directory where the sources are held.
Reading the USENET newsgroup comp.os.linux.announce
for announcements of new software releases is the easiest way to
find out about new software. Whenever you are looking for soft-
ware on an FTP site, downloading the ls-lR index file from the
FTP site and using grep to find the files in question is the easiest
way to locate software. If you have archie available to you, it
can be of assistance as well (*Note: If you don't have archie, you
can telnet to an archie server such as archie.rutgers.edu, login
as "archie" and use the command "help"). See Appendix B for
more details.
One handy source of Linux software is the SLS distribution
disk images. Each disk contains a number of .tgz files which are
simply gzipped tar files. Instead of downloading the disks, you can
download the desired .tgz files from the SLS directories on the
FTP site and install them directly.
Again, it's usually not a good idea to upgrade by reinstalling
with the newest version of SLS, or another distribution. SLS in
particular was not designed to be upgradeable. If you reinstall in
this way, you will no doubt wreck your current installation, in-
cluding user directories and all of your customized configuration.
The best way to upgrade software is piecewise; that is, if there is
a program that you use often that has a new version, upgrade it.
Otherwise, don't bother. Rule of thumb: If it ain't broke, don't fix
it. If you current software works, there's no reason to upgrade.
5.8 Managing Filesystems
Another task of the system administrator is taking care of filesys-
tems. Most of this job entails periodically checking the filesystems
for damage or corrupted files; many systems automatically check
the filesystems at boot time.
5.8.1 Mounting filesystems
First, a few concepts about filesystems. Before a filesystem is ac-
cessible to the system, it must be mounted on some directory. For
example, if you have a filesystem on a floppy, you must mount it
under some directory, say /mnt, in order to access the files on it (see
Section 5.6.2). After mounting the filesystem on that directory, all
of the files in the filesystem appear in that directory. In the case of
the floppy, the files on the floppy will appear in the directory /mnt.
After unmounting the floppy, the directory /mnt will be empty.
The same is true of filesystems on the hard drive. The sys-
tem automatically mounts filesystems on your hard drive for you
at bootup time. The so-called "root filesystem" is mounted on the
directory /. If you have a separate filesystem for /usr, for exam-
ple (see Section A.3), it is mounted on /usr. If you only have
a root filesystem, all files (including those in /usr) exist on that
filesystem.
The command mount is used to mount a filesystem. The com-
mand
mount -av
is executed from the file /etc/rc (which is the system initialization
file executed at boot time; see Section 5.9.1). The mount -av com-
mand obtains information on filesystems and mount points from
the file /etc/fstab. An example fstab file appears below.
# device directory type options
/dev/hda2 / ext2 defaults
/dev/hda3 /usr ext2 defaults
/dev/hda4 none swap sw
/proc /proc proc none
The first field is the device_the name of the partition to mount.
The second field is the mount point. The third field is the filesys-
tem type_such as ext2 (for ext2fs) or minix (for Minix filesys-
tems). The last field contains mount options_usually, this is set
to "default".
As you can see, swap partitions are included in /etc/fstab as
well. They have a mount directory of none, and type swap. The
swapon -a command, executed from /etc/rc as well, is used to
enable swapping on all swap devices listed in /etc/fstab.
The fstab file contains one special entry_for the /proc filesys-
tem. As mentioned in Section 4.10.1, the /proc filesystem is used
to store information about system processes, available memory, and
so on. If /proc is not mounted, commands such as /ps will not
work.
The mount -av command actually mounts all filesystems other
than the root filesystem (in the table above, /dev/hda2). The root
filesystem is automatically mounted at boot time by the kernel.
Instead of using mount -av, you can mount a filesystem by
hand. The command
# mount -t ext2 /dev/hda3 /usr
is equivalent to mounting the filesystem with the entry /dev/hda3
in the fstab example file above.
In general, you should never have to mount or unmount filesys-
tems by hand. The mount -av command in /etc/rc takes care
of mounting the filesystems at boot time. Filesystems are auto-
matically unmounted by the shutdown or halt commands before
bringing the system down.
5.8.2 Checking filesystems
It is usually a good idea to check your filesystems for damage or cor-
rupt files every now and then. Some systems automatically check
their filesystems at boot time (with the appropriate commands in
/etc/rc).
The command used to check a filesystem depends on the type
of the filesystem in question. For ext2fs filesystems (the most com-
monly used type), this command is e2fsck. For example, the com-
mand
# e2fsck -av /dev/hda2
will check the ext2fs filesystem on /dev/hda2 and automatically
correct any errors.
It is usually a good idea to unmount a filesystem before checking
it. For example, the command
# umount /dev/hda2
will unmount the filesystem on /dev/hda2, after which you can
check it. The one exception is that you cannot unmount the root
filesystem. In order to check the root filesystem when it's un-
mounted, you should use a maintenance boot/root diskette (see
Section 5.10.1). You also cannot unmount a filesystem if any of
the files in it are "busy"_that is, being used by a running process.
For example, you cannot unmount a filesystem if any user's current
working directory is on that filesystem. You will receive a "Device
busy" error if you attempt to unmount a filesystem which is in use.
Other filesystem types use different forms of the e2fsck com-
mand, such as efsck and xfsck. On some systems, you can simply
use the command fsck, which will determine the filesystem type
and execute the appropriate command.
It is important that you reboot your system immediately after
checking a filesystem is any corrections were made to that filesys-
tem. For example, if e2fsck reports that it corrected any errors
with the filesystem, you should immediately shutdown -r in order
to reboot the system. This is to allow the system to re-sync its
information about the filesystem when e2fsck modifies it.
Of course, the /proc filesystem never needs to be checked in
this manner. /proc is a memory filesystem, managed directly by
the kernel.
5.9 Miscellaneous Tasks
Believe it or not, there are a number of housekeeping tasks for the
system administrator which don't fall into any major category.
5.9.1 System startup files
When the system boots, a number of scripts are executed automat-
ically by the system before any user logs in. Here is a description
of what happens.
At bootup time, the kernel spawns the process /etc/init. init
is a program which reads its configuration file, /etc/inittab, and
spawns other processes based on the contents of this file. One of
the important processes started from inittab is the /etc/getty
process started on each virtual console. The getty process grabs
the VC for use, and starts a login process on the VC. This allows
you to login on each VC; if /etc/inittab does not contain a getty
process for a certain VC, you will not be able to login on that VC.
Another process executed from /etc/inittab is /etc/rc, the
main system initialization file. This file is a simple shell script
which executes any initialization commands needed at boot time,
such as mounting the filesystems (see Section 5.8 and initializing
swap space.
Your system may execute other initialization scripts as well,
such as /etc/rc.local. /etc/rc.local usually contains initial-
ization commands specific to your own system, such as setting the
hostname (see the next section). rc.local may be started from
/etc/rc or from /etc/inittab directly.
5.9.2 Setting the hostname
In a networked environment, the hostname is used to uniquely i-
dentify a particular machine, while in a standalone environment
the hostname just gives the system personality and charm. It's
like naming a pet: you can always address to your dog as "The
dog," but it's much more interesting to assign the dog a name such
as Spot or Woofie.
Setting the system's hostname is a simple matter of using the
hostname command. If you are on a network, your hostname
should be the full hostname of your machine, such as goober.norelco.com.
If you are not on a network of any kind, you can choose an arbitrary
host and domainname, such as loomer.vpizza.com, shoop.nowhere.edu,
or floof.org.
When setting the hostname, the hostname must appear in the
file /etc/hosts, which assigns an IP address to each host. Even
if your machine is not on a network, you should include your own
hostname in /etc/hosts.
For example, if you are not on a TCP/IP network, and y-
our hostname is floof.org, simply include the following line in
/etc/hosts:
127.0.0.1 floof.org localhost
This assigns your hostname, floof.org, to the loopback address
127.0.0.1 (used if you're not on a network). The localhost alias
is also assigned to this address.
If you are on a TCP/IP network, however, your real IP ad-
dress and hostname should appear in /etc/hosts. For example,
if your hostname is goober.norelco.com, and your IP address is
128.253.154.32, add the following line to /etc/hosts:
128.253.154.32 goober.norelco.com
If your hostname does not appear in /etc/hosts, you will not
be able to set it.
To set your hostname, simply use the hostname command. For
example, the command
# hostname -S goober.norelco.com
sets the hostname to goober.norelco.com. In most cases, the
hostname command is executed from one of the system startup
files, such as /etc/rc or /etc/rc.local. Edit these two files and
change the hostname command found there to set your own host-
name; upon rebooting the system the hostname will be set to the
new value.
5.9.3 Managing file links
Links allow you to give a single file multiple names. Files are actu-
ally identified to the system by their inode number, which is just
the unique filesystem identifier for the file (*Note: The command
ls -i will display file inode numbers.). A directory is actually a
listing of inode numbers with their corresponding filenames. Each
filename in a directory is a link to a particular inode.
5.9.3.1 Hard links
The ln command is used to create multiple links for one file. For
example, let's say that you have the file foo in a directory. Using
ls -i, we can look at the inode number for this file.
# ls -i foo
22192 foo
#
Here, the file foo has an inode number of 22192 in the filesystem.
We can create another link to foo, named bar:
# ln foo bar
With ls -i, we see that the two files have the same inode.
# ls -i foo bar
22192 bar 22192 foo
#
Now, accessing either foo or bar will access the same file. If you
make changes to foo, those changes will be made to bar as well.
For all purposes, foo and bar are the same file.
These links are known as hard links because they directly create
a link to an inode.
When you delete a file with rm, you are actually only deleting
one link to a file. If you use the command
# rm foo
then only the link named foo is deleted; bar will still exist. A file
is only actually deleted on the system when it has no links to it.
Usually, files have only one link, so using the rm command deletes
the file. However, if a file has multiple links to it, using rm will only
delete a single link; in order to delete the file, you must delete all
links to the file.
The command ls -l will display the number of links to a file
(among other information).
# ls -l foo bar
-rw-r--r-- 2 root root 12 Aug 5 16:51 bar
-rw-r--r-- 2 root root 12 Aug 5 16:50 foo
#
The second column in the listing, "2", specifies the number of links
to the file.
5.9.3.2 Symbolic links
Symbolic links are another type of link, which work differently than
hard links (as described above). A symbolic link allows you to give
a file another name, but it doesn't link the file by inode.
The command ln -s will create a symbolic link to a file. For
example, if we use the command
# ln -s foo bar
we will create the symbolic link bar pointing to the file foo. If
we use ls -i, we will see that the two files have different inodes,
indeed.
# ls -i foo bar
22195 bar 22192 foo
#
However, using ls -l, we see that the file bar is a symlink pointing
to foo.
# ls -l foo bar
lrwxrwxrwx 1 root root 3 Aug 5 16:51 bar -> foo
-rw-r--r-- 1 root root 12 Aug 5 16:50 foo
#
Functionally, hard links and symbolic links are similar, but
there are some differences. For one thing, you can create a symbol-
ic link to a file which doesn't exist; the same is not true for hard
links. Symbolic links are processed by the kernel differently than
hard links are, which is just a technical difference but sometimes
an important one. Symbolic links are helpful because they identify
what file they point to; with hard links, there is no easy way to
determine which files are linked to the same inode.
Links are used in many places on the Linux system. Symbolic
links are especially important to the shared library images in /lib.
See Section 5.7.2 for more information.
5.10 What To Do In An Emergency
On some occasions, the system administrator will be faced with
the unique problem of recovering from a complete disaster, such
as forgetting the root password or trashing filesystems. The best
advice is, don't panic. Everyone makes stupid mistakes_that's the
best way to learn about system administration: the hard way.
Linux is not an unstable version of UNIX. In fact, I have had
fewer problems with system hangs and panics than with commercial
versions of UNIX on many platforms. Linux also benefits from a
strong complement of wizards who can help you get out of a bind.
The first thing you should do when investigating any problem
is to attempt to fix it yourself. Poke around, see how things work.
Too much of the time, a system administrator will post a desperate
plea for help before looking into the problem at all. Most of the
time, you'll find that fixing problems yourself is actually very easy.
It is the path to guruhood.
There are very few cases where reinstalling the system from
scratch is necessary. Many new users accidentally delete some es-
sential system file, and immediately reach for the installation disks.
This is not a good idea. Before taking such drastic measures, inves-
tigate the problem and ask others to help fix things up. In almost
all cases, you can recover your system from a maintenance diskette.
5.10.1 Recovering using a maintenance diskette
One indispensable tool for the system administrator is the so called
"boot/root disk"_a floppy which can be booted for a complete
Linux system, independent of your hard drive. Boot/root disks
are actually very simple_you create a root filesystem on the flop-
py, place all of the necessary utilities on it, and install LILO and a
bootable kernel on the floppy. Another technique is to use one flop-
py for the kernel and another for the root filesystem. In any case,
the result is the same: you are running a Linux system completely
from floppy.
The canonical example of a boot/root disk is the SLS a1 disk
(*Note: See Section 2.2 for information on downloading the SLS
release. For this procedure, you don't need to download the entire
SLS release_only the a1 disk). This disk contains a bootable k-
ernel and a root filesystem, all on floppy. Usually, it's used only
when installing SLS, but it comes in very handy when doing system
maintenance.
The H.J Lu boot/root disk, available from /pub/Linux/GCC on
sunsite.unc.edu, is another example of such a maintenance disk.
Or, if you're ambitious, you can create your own boot/root disk.
In most cases, however, using a pre-made boot/root disk is much
easier and will probably be more complete.
Using a boot/root disk is very simple. Just boot the disk on
your system, and login as root (usually no password). In order to
access the files on your hard drive, you will need to mount your
filesystems by hand. For example, the command
# mount -t ext2 /dev/hda2 /mnt
will mount an ext2fs filesystem on /dev/hda2 under /mnt. Re-
member that / is now on the boot/root disk itself; you need to
mount your hard drive filesystems under some directory in order
to access the files. Therefore, /etc/passwd on your hard drive is
now /mnt/etc/passwd if you mount your root filesystem on /mnt.
5.10.2 Fixing the root password
If you forget your root password, no problem. Just boot the
boot/root disk, mount your root filesystem on /mnt, and blank
out the password field for root in /mnt/etc/password, as so:
root::0:0:root:/:/bin/sh
Now root has no password; when you reboot from the hard drive
you should be able to login as root and reset the password using
passwd.
Aren't you glad you learned how to use vi? On your boot/root
disk, other editors such as Emacs probably aren't available, but vi
should be.
5.10.3 Fixing trashed filesystems
If you somehow trash your filesystems, you can run e2fsck (if you
use the ext2fs filesystem type, that is) to correct any damaged data
on the filesystems from floppy. Other filesystem types use different
forms of the e2fsck command; see Section 5.8 for details.
When checking your filesystems from floppy, it's best for the
filesystems to not be mounted.
5.10.4 Recovering lost files
If you accidentally deleted important files on your system, there's
no way to "undelete" them. However, you can copy the relevant
files from the floppy to your hard drive. For example, if you deleted
/bin/login on your system (which allows you to login), simply
boot the boot/root floppy, mount the root filesystem on /mnt, and
use the command
# cp -a /bin/login /mnt/bin/login
The -a option tells cp to preserve the permissions on the file(s)
being copied.
Of course, if the files you deleted weren't essential system files
which have counterparts on the boot/root floppy, you're out of
luck. If you made backups, you can always restore from them.
5.10.5 Fixing trashed libraries
If you accidentally trashed your libraries or symbolic links in /lib,
more than likely commands which depended on those libraries will
no longer run (see Section 5.7.2). The easiest solution is to boot
your boot/root floppy, mount your root filesystem, and fix the li-
braries in /mnt/lib.
Chapter 6
Advanced Features
This chapter will introduce you to some of the more interesting
features of Linux. This assumes that you have at least basic U-
NIX experience, and understand the information contained in the
previous chapters.
The most important aspect of Linux that distinguishes it from
other implementations of UNIX is its open design and philosophy.
Linux was not developed by a small team of programmers headed
by a marketing committee with a single goal in mind. It was de-
veloped by an ever-increasing group of hackers, putting what they
wanted into a homebrew UNIX system. The types of software and
diversity of design in the Linux world is large. Some people dislike
this lack of uniformity and conformity_however, some call it one
of the strongest qualities of Linux.
6.1 The X Window System
The X Window System is a large and powerful (and somewhat
complex) graphics environment for UNIX systems. The original
X Windows code was developed at MIT; commercial vendors have
since made X the industry standard for UNIX platforms. Virtually
every workstation in the world runs some variant of X Windows.
A free port of the MIT X Windows version 11, release 5 (X11R5)
for 80386/80486 UNIX systems has been developed by a team of
programmers headed by David Wexelblat (*Note: David may be
reached on the Internet at dwex@mtgzfs3.att.com.). The release,
known as XFree86, is available for System V/386, 386BSD, and
other i386 UNIX implementations, including Linux. It includes all
of the required binaries, support files, libraries, and tools.
Configuring and using the X Window System is far beyond the
scope of this book. You are encouraged to read The X Window
System User's Guide, by Valerie Quercia and Tim O'Reilly. See
Appendix B for information on this book. In this section, we'll
give a general overview of installing and configuring X Windows for
Linux, but it is far from complete. The man pages and README
files included with the Linux X Windows distribution should be
very helpful. Also, the Linux FAQ contains information on setting
up X Windows.
6.1.1 Hardware requirements
XFree86 supports a wide range of video controllers and monitors.
As of XFree86-1.3, the following SVGA chipsets are supported
(*Note: This information is taken from the XFree86-1.3 README
file by David Dawes.)
Tseng ET3000, ET4000; Western Digital/Paradise PVGA1; West-
ern Digital WD90C00, WD90C10, WD90C11, WD90C30, WD90C31;
Genoa GVGA; Trident TVGA8800CS, TVGA8900B, TVGA8900C,
TVGA8900CL, TVGA9000; ATI 28800-4, 28800-5, 28800-a; NCR
77C22, 77C22E; Cirrus Logic GLGD5420, CLGD5422, CLGD5424,
CLGD5426; and Compaq AVGA.
All of the above are supported in both 256 color and monochrome
modes, with the exception of the ATI and Cirrus chipsets, which
are only supported in 256 color mode.
The monochrome server also supports generic VGA cards, using
64k of video memory in a single bank, and the Hercules card. On
the Compaq AVGA, only 64k of video memory is supported for the
monochrome server, and the GVGA has not been tested with more
than 64k.
Note that the Diamond SpeedStar 24 (and possibly recent Speed-
Star+) boards are not supported, even though they use the ET4000.
The reason for this is that Diamond has changed the mechanism
used to select pixel clock frequencies, and will only release program-
ming information under non-disclosure. Supporting this board
would restrict distribution of the sources for XFree86.
A mention must be made of accelerated chipsets. At this point,
XFree86 does not support any accelerated chipsets. These include
the S3 86Cxxx, the ATI Mach8 and Mach32, the IBM 8514/A,
the new Western Digital chipset (on the Diamond SpeedStar 24X),
the new Cirrus and Tseng chipsets, and TIGA (TI 340x0). Some
of these will be supported in XFree86 2.0. However, there is a
separate server, XS3, available for S3 chipset boards (such as the
Orchid Fahrenheit).
Local bus cards are supported as well. The suggested setup for
XFree86 under Linux is a 486 machine with at least 8 megabytes
of RAM, and an ET4000 VESA local bus video card. This is the
"generic" setup which is known to work and is quite fast. Of course,
you must also have a VESA local bus motherboard in order to use
the local bus video card. I have run XFree86 on a 486/50 MHz
machine with 8 megs of RAM, and it's as fast or faster than many
color workstations running proprietary versions of UNIX and X.
6.1.2 Installing XFree86
The Linux binary distribution of XFree86 can be found on a num-
ber of Linux FTP sites. On sunsite.unc.edu, it is found in the
directory /pub/Linux/X11/Xfree86-1.3. (As of the time of this
writing, the current version is 1.3; newer versions are released peri-
odically). The binary distribution consists of a number of gzipped
tar files, all of which unpack from /. Installation is very simple;
just unpack these tar files and everything should go into the right
place.
Package Name Description
------------------------- --------------------------------------------------
xf86-1.3-bin.tar.gz Essential binaries and setup files; required.
xf86-1.3-kit.tar.gz X Server link kit. Only needed to hack the
X Server.
xf86-1.3-man.tar.gz Man pages.
xf86-1.3-pex.tar.gz PEX utilities, for the PEX programming environment.
xf86-1.3-prg.tar.gz X11 include files and libraries. Needed to write
X programs.
xf86-1.3-xfn.tar.gz Extra fonts.
After installing the software, you need to link the shared li-
braries from /usr/X386/lib to /lib. One way to do this is with
the command:
# ln -s /usr/X386/lib/lib*.so.? /lib
You may wish to physically copy the files instead.
If you installed XFree86 with from a standard Linux distribu-
tion such as SLS or TAMU, then all of the files should already be
in the right place.
If you wish to use the SVGA color server, the file /usr/bin/X11/X
should be linked to /usr/bin/X11/XF86_SVGA. If you wish to use
the monochrome server instead, relink this file to XF86_MONO with
the command
# ln -sf /usr/bin/X11/XF86_MONO /usr/bin/X11/X
The XS3 server for S3-based SVGA cards is on sunsite.unc.edu
in the directory /pub/Linux/X11/X-servers/s3. XS3 has its own
instructions for setup and configuration; see the README files there
for more details.
6.1.3 Configuring XFree86
Setting up XFree86 is not difficult in most cases. Only when you
have non-standard hardware will XFree86 configuration give you
any problems. However, XFree86 configuration is beyond the scope
of this document; here, we'll give you a brief overview of how it
works.
The main XFree86 configuration file is /usr/lib/X11/Xconfig.
This file contains information on your mouse, video card param-
eters, and so on. The file Xconfig.sample is provided with the
XFree86 distribution as an example. The XFree86 man page ex-
plains the format of this file in detail.
In general, here's how it works. Your video card is capable of
driving a number of "dot clocks" which are simply clock frequencies
for your card. In turn, each dot clock has a resolution mode associ-
ated with it, such as 640x480 or 1024x768. (You are not restrained
to using "standard" resolutions, as we will see). In the Xconfig file
there exists stanzas for configuring your mouse, keyboard, and so
on. There also exists stanzas for each server: vga256 for the color
SVGA server, and vga2 for the monochrome server.
Under each server stanza are lines to set the virtual resolution,
chipset type, and so on for you video card. There is also a Modes
line which specifies which modes are available on your card. Modes
are usually named after their resolution. For example,
Modes "640x480" "800x600" "1024x768"
Each mode on this line is an index into the modeDB stanza at the end
of the Xconfig file. It is this section of the file which determines
the actual video parameters for each mode.
There is also an optional Clocks line which you can use to
set the available dot clocks for your card. By default, XFree86 will
determine the clocks at startup time; however, because clock timing
can be thrown off by other programs running on your system, it
may be easier to set the clocks in the Xconfig file.
The modeDB section of the Xconfig file is the important part.
Each video card and monitor has its own set of timing and sync fre-
quencies for different resolutions. The file /usr/lib/X11/etc/modeDB.txt
contains a database of some known monitor and video card timing
numbers. Many card and monitors use the VESA standard timings
included in the sample Xconfig file.
There are various other documents in /usr/lib/X11/etc which
you should read. The file VideoModes.txt is a tutorial on hack-
ing your own monitor frequency timings if you simply can't get
any of the numbers in modeDB.txt to work. There is also a col-
lection of sample Xconfig files on sunsite.unc.edu in the file
/pub/Linux/X11/Xconfig.tgz. Also see the XFree86 man pages
for more information.
6.1.4 Starting up X
After configuring the XConfig file, you can start the server with the
startx command. There are a few things to take into consideration
first, however.
Make sure that the directory /usr/bin/X11 is on your path.
This directory contains all of the X binaries and the server itself.
Secondly, the X server requires a free VC to enable VC switch-
ing (*Note: While running X, you can switch back to your text
VC's using the keys [ctrl-alt-F1] through [ctrl-alt-F12]. To re-
turn to X, simply switch to the VC reserved for XFree86.). In
other words, you must have one of your VC's available, with no
login process running on it. The easiest way to ensure this is to
edit /etc/inittab and delete one of the getty lines which starts
up a login process on each VC. In my inittab, for example, I run
getty on /dev/tty1 through /dev/tty7 (that is, VC's 1 through 7),
but not on /dev/tty8.
When running startx, the file $HOME/.xinitrc is read. This
file is a shell script which contains commands to run after the X
server is started. If this file doesn't exist, the file /usr/lib/X11/xinit/xini*
*trc
is used as a system-wide default instead. You can use this default
file as a sample .xinitrc file.
Using X Windows is a large topic, and we won't try to cover it
here. Read The X Window System User's Guide, or another book
on using X, for details. See Appendix B information on this book.
6.1.5 Exiting X
Usually, the last client started in .xinitrc is the one used to shut-
down X cleanly. For example, if the last command in .xinitrc
is
exec twm
then killing the twm process will result in X shutting down.
However, if you need to immediately kill the X server for some
reason, you can use the key combination [ctrl-alt-backspace].
6.1.6 Accessing MS-DOS Files
If, for some twisted and bizarre reason, you would have need to
access files from MS-DOS, it's quite easily done under Linux.
The usual way to access MS-DOS files is to mount an MS-DOS
partition or floppy under Linux, allowing you to access the files
directly through the filesystem. For example, if you have an MS-
DOS floppy in /dev/fd0, the command
# mount -t msdos /dev/fd0 /mnt
will mount it under /mnt. See Section 5.6.2 for more information
on mounting floppies.
You can also mount an MS-DOS partition of your hard drive
for access under Linux. If you have an MS-DOS partition on
/dev/hda1, the command
# mount -t msdos /dev/hda1 /mnt
will mount it. Be sure to umount the partition when you're done us-
ing it. You can have your MS-DOS partitions automatically mount-
ed at boot time if you include entries for them in /etc/fstab;
see Section 5.8 for details. For example, the following line in
/etc/fstab will mount an MS-DOS partition on /dev/hda1 on
the directory /dos.
/dev/hda1 /dos msdos defaults
The Mtools software may also be used to access MS-DOS files.
For example, the commands mcd, mdir, and mcopy all behave as
their MS-DOS counterparts. If you installed Mtools, there should
be man pages available for these commands.
Accessing MS-DOS files is one thing; running MS-DOS pro-
grams from Linux is another. There is an MS-DOS Emulator under
development for Linux; it is widely available, and even distributed
with SLS. It can be retrieved from a number of locations, including
the various Linux FTP sites (see Appendix C for details). The MS-
DOS Emulator is reportedly powerful enough to run a number of
applications, including Wordperfect, from Linux. However, Linux
and MS-DOS are vastly different operating systems. The power of
any MS-DOS emulator under UNIX is somewhat limited.
In addition, work is underway on a Microsoft Windows emulator
to run under X Windows. Watch the newsgroups and FTP sites
for more information.
6.2 Networking with TCP/IP
Linux supports a full implementation of the TCP/IP (Transport
Control Protocol/Internet Protocol) networking protocols. TCP/IP
has become the most successful mechanism for networking comput-
ers worldwide. With Linux and an Ethernet card, you can network
your machine to a local area network, or (with the proper network
connections), to the Internet_the worldwide TCP/IP network.
Hooking up a small LAN of UNIX machines is easy. It simply
requires an Ethernet controller in each machine and the appropri-
ate Ethernet cables and other hardware. Or, if your business or
university provides access to the Internet, you can easily add your
Linux machine to this network.
Linux TCP/IP also supports SLIP_Serial Line Internet Proto-
col. SLIP allows you to have dialup Internet access using a modem.
If your business or university provides SLIP access, you can dial in
to the SLIP server and put your machine on the Internet over the
phone line. Alternately, if your Linux machine also has Ethernet
access to the Internet, you can set up your Linux box as a SLIP
server.
For complete information on setting up TCP/IP under Lin-
ux, we encourage you to read the Linux NET-2-FAQ, available via
anonymous FTP from sunsite.unc.edu. The NET-2-FAQ is a
complete guide to configuring TCP/IP, including Ethernet and SLIP
connections, under Linux. The more complete Linux Network
Administration Guide, from the Linux Documentation Project,
should also be available. Also of interest is the book TCP/IP Net-
work Administration, by Craig Hunt. It contains complete infor-
mation on using and configuring TCP/IP on UNIX systems. See
Appendix B for more information.
6.2.1 Hardware Requirements
You can use Linux TCP/IP without any networking hardware at
all_configuring "loopback" mode allows you to talk to yourself.
This is necessary for some applications and games which use the
"loopback" network device.
However, if you want to use Linux with an Ethernet TCP/IP
network, you need one of the following Ethernet cards: 3com 3c503,
3c503/16; Novell NE1000, NE2000; Western Digital WD8003, WD8013;
Hewlett Packard HP27245, HP27247, HP27250. The following
clones are reported to work: WD-80x3 clones: LANNET LEC-
45; NE2000 clones: Alta Combo, Artisoft LANtastic AE-2, Asante
Etherpak 2001/2003, D-Link Ethernet II, LTC E-NET/16 P/N
8300-200-002, Network Solutions HE-203, SVEC 4 Dimension Eth-
ernet, 4-Dimension FD0490 EtherBoard 16, and D-Link DE-600.
Linux also supports SLIP, which allows you to use a modem to
access the Internet over the phone line. In this case, you'll need a
modem compatible with your SLIP server_most servers require a
14.4bps V.32bis modem, such as the US Robotics Sportster, or the
Infotel 144DF Internal.
6.3 Networking with UUCP
UUCP (UNIX-to-UNIX Copy) is an older mechanism used to trans-
fer information between UNIX systems. Using UUCP, UNIX sys-
tems dial each other up (using a modem) and transfer mail mes-
sages, news articles, files, and so on. If you don't have TCP/IP or
SLIP access, you can use UUCP to communicate with the world.
Most of the mail and news software (see Sections 6.4 and 6.5) can
be configured to use UUCP to transfer information to other ma-
chines. In fact, if there is an Internet site nearby, you can arrange
to have Internet mail sent to your Linux machine via UUCP from
that site.
The Linux Network Administrator's Guide contains complete
information on configuring and using UUCP under Linux. Also,
the Linux UUCP-MAIL-NEWS FAQ, available via anonymous FT-
P from sunsite.unc.edu, should be of help. Another source of in-
formation on UUCP is the book Managing UUCP and USENET,
by Tim O'Reilly and Grace Todino. See Appendix B for more
information.
6.4 Electronic Mail
Like most UNIX systems, Linux provides a number of software
packages for using electronic mail. E-mail on your system can ei-
ther be local (that is, you only mail other users on your system), or
networked (that is, you mail, using either TCP/IP or UUCP, users
on other machines on a network). E-mail software usually consists
of two parts: a mailer and a transport. The mailer is the user-
level software which is used to actually compose and read e-mail
messages. Popular mailers include elm and mailx. The transport
is the low-level software which actually takes are of delivering the
mail, either locally or remotely. The user never sees the trans-
port software; they only interact with the mailer. However, as the
system administrator, it is important to understand the concepts
behind the transport software and how to configure it.
The most popular transport software for Linux is Smail. This
software is easy to configure, and is able to send both local and
remote TCP/IP e-mail. The more powerful sendmail transport is
used on most UNIX systems, however, because of its complicated
setup mechanism, most Linux systems don't use it.
The Linux UUCP-MAIL-NEWS FAQ gives more information
on the available mail software for Linux and how to configure it
on your system. If you plan to send mail remotely, you'll need
to understand either TCP/IP or UUCP, depending on how your
machine is networked (see Sections 6.2 and 6.3). The UUCP and
TCP/IP documents listed in Appendix B should be of help there.
Most of the Linux mail software can be retrieved via anonymous
FTP from sunsite.unc.edu in the directory /pub/Linux/system/Mail.
6.5 News and USENET
Linux also provides a number of facilities for managing electronic
news. You may choose to set up a local news server on your system,
which will allow users to post "articles" to various "newsgroups"
on the system...a lively form of discussion. However, if you have
access to a TCP/IP or UUCP network, then you will be able to
participate in USENET_a worldwide network news service.
There are two parts to the news software_the server and the
client. The news server is the software which controls the news-
groups and handles delivering articles to other machines (if you
are on a network). The news client, or newsreader, is the software
which connects to the server to allow users to read and post news.
There are several forms of news servers available for Linux.
They all follow the same basic protocols and design. The two pri-
mary versions are "C News" and "INN". There are many types of
newsreaders, as well, such as rn and tin. The choice of newsread-
er is more or less a matter of taste; all newsreaders should work
equally well with different versions of the server software. That
is, the newsreader is independent of the server software, and vice
versa.
If you only want to run news locally (that is, not as part of
USENET), then you will need to run a server on your system, as
well as install a newsreader for the users. The news server will
store the articles in a directory such as /usr/spool/news, and
the newsreader will be compiled to look in this directory for news
articles.
However, if you wish to run news over the network, there are
several options open to you. TCP/IP network-based news uses a
protocol known as NNTP (Network News Transmission Protocol).
NNTP allows a newsreader to read news over the network, on a
remote machine. NNTP also allows news servers to send articles
to each other over the network_this is the software upon which
USENET is based. Most businesses and universities have one or
more NNTP servers set up to handle all of the USENET news for
that site. Every other machine at the site runs an NNTP-based
newsreader to read and post news over the network via the NNTP
server. This means that only the NNTP server actually stores the
news articles on disk.
Here are some possible scenarios for news configuration.
o You run news locally. That is, you have no network connec-
tion, or no desire to run news over the network. In this case,
you need to run C News or INN on your machine, and install
a newsreader to read the news locally.
o You have access to a TCP/IP network and an NNTP server.
If your organization has an NNTP news server set up, you
can read and post news from your Linux machine by simply
installing an NNTP-based newsreader. (Most newsreaders
available can be configured to run locally or use NNTP). In
this case, you do not need to install a news server or store
news articles on your system. The newsreader will take care
of reading and posting news over the network. Of course, you
will need to have TCP/IP configured and have access to the
network (see Section 6.2).
o You have access to a TCP/IP network but have no NNT-
P server. In this case, you can run an NNTP news server
on your Linux system. You can install either a local or an
NNTP-based newsreader, and the server will store news arti-
cles on your system. In addition, you can configure the server
to communicate with other NNTP news servers to transfer
news articles.
o You want to transfer news using UUCP. If you have UUCP
access (see Section 6.3), you can participate in USENET as
well. You will need to install a (local) news server and a news
reader. In addition, you will need to configure your UUCP
software to periodically transfer news articles to another n-
earby UUCP machine (known as your "news feed"). UUCP
does not use NNTP to transfer news; simply, UUCP provides
its own mechanism for transferring news articles.
The one downside of most news server and newsreader software
is that it must be compiled by hand. Most of the news software
does not use configuration files; instead, configuration options are
determined at compile time.
Most of the "standard" news software (available via anony-
mous FTP from ftp.uu.net in the directory /news) will com-
pile out-of-the box on Linux. Necessary patches can be found on
sunsite.unc.edu in /pub/Linux/system/Mail (which is, inciden-
tally, also where mail software for Linux is found). Other news
binaries for Linux may be found in this directory as well.
For more information, refer to the Linux UUCP-MAIL-NEWS
FAQ from sunsite.unc.edu in /pub/Linux/docs. Also, the LD-
P's Linux Network Administrator's Guide contains complete infor-
mation on configuring news software for Linux. The book Manag-
ing UUCP and Usenet, by Tim O'Reilly and Grace Todino, is an
excellent guide to setting up UUCP and news software. Also of in-
terest is the USENET document "How to become a USENET site,"
available from ftp.uu.net, in the directory /usenet/news.announce.newusers.
Appendix A
Tips, Tricks, and Common Problems
This appendix contains information on some commonly used tricks
and techniques, as well as solutions to common problems.
A.1 Installing SLS From the Hard Drive
Instead of installing SLS from floppy, you can simply keep all of
the distribution files on another partition on your hard drive (say,
your MS-DOS partition), and install from there.
First, you need to create the SLS a1 disk as you would for a
floppy installation. Secondly, all of the other SLS files need to go
in a directory named install at the top level of the partition. For
example, if you plan to install from an MS-DOS partition on drive
C:, the directory names will be C:"install"a2, C:"install"a3,
and so on. Each subdirectory of install will contain the files for
the corresponding diskette.
Make sure that install is a top-level directory on the partition.
In other words, the directory C:"SLS"install will not work. It
must be C:"install.
All of the other installation steps (creating partitions and filesys-
tems, and so on) are identical to those found in Chapter 3. When
using the doinstall command, simply choose the menu option to
install from the hard drive. You will be prompted for the parti-
tion name (such as /dev/hda2) and the type of partition (such as
msdos). Everything else should be self-explanatory.
A.2 Installing the SLS CD-ROM
If someone will lend me a CD-ROM drive, I can write this section.
A.3 Using Multiple Filesystems
If you have experience with UNIX system administration, it should
be easy to decide how to use multiple filesystems with Linux. For
example, you can use seperate filesystems for root and /usr space.
There is no inherent benefit to using multiple filesystems for
Linux. However, if you're conscious about keeping everything mount-
ed at once, then you may wish to do so. For example, if you ac-
cidentally trash your root filesystem, then other filesystems, such
as /usr, won't be affected. However, using multiple filesystems
means that you have to plan your space carefully_there is no way
to nondestructively resize filesystems (yet).
You may wish to use multiple swap partitions as well_because
swap partitions are limited to 16 megabytes each. You may use up
to 8 swap partitions on your system.
Using multiple filesystems is easy. First of all, you must have a
seperate partition for each filesystem. If you are creating a number
of filesystems, you may need to use logical partitions in order to
overcome the 4 primary partition limit. While using fdisk, simply
use the "n" command to create a new partition for each Linux
filesystem you want to create.
Before installing the software, simply use the appropriate mke2fs
command for each filesystem that you wish to create.
When installing the software, there may be extra steps involved
in getting the system to recognize all of your filesystems for in-
stallation. For some releases, you may need to mount all of the
filesystems in the appropriate place.
To install the SLS release, all you need to do is use extra argu-
ments on the doinstall command, as so:
doinstall <rootfs> <mount-pt1> <fs1> <mount-pt2> <fs2> ...<mount-ptN> <fsN>
For example, if you have your root filesystem on /dev/hda2, y-
our /usr filesystem on /dev/hda3, and your /tmp filesystem on
/dev/hda4, use the command
# doinstall /dev/hda2 /usr /dev/hda3 /tmp /dev/hda4
See your documentation for details on using multiple filesystems
with the release of Linux that you're installing.
A.4 Using dd Instead of rawrite.exe
If you would rather create your Linux install disks from a UNIX
system, rather than using rawrite.exe on an MS-DOS system,
you can use the following procedure. Note that this procedure
does not specify how to create MS-DOS formatted disks (such as
the SLS a2 through a4 disks). This procedure only replaces the
use of rawrite.exe (for the SLS a1 disk, for example).
The dd command may be used on a UNIX system to replace
the use of rawrite. The format of the command is as follows:
dd if=<input-file> of=<output-file> bs=16k conv=sync
The <input-file> is the name of the file to write to the floppy, such
as "a1.3".
<output-file> is the name of the floppy device to write the file
to. On many systems, this is /dev/rfdn, where n is a number
such as 0 or 1 depending on the unit number of the floppy drive.
However, this varies greatly from system to system. You need to
check with the system administrator of the system in question to
determine the device name of the floppy drive. For example, on
some systems the following will work:
# dd if=a1.3 of=/dev/rfd0 bs=16k conv=sync
Under Linux, the floppy drive device name is either /dev/fd0
(for the first floppy drive), or /dev/fd1 (for the second). You can
use the command
# dd if=a1.3 of=/dev/fd0 bs=16k conv=sync
to "rawrite" a floppy from another Linux system. Or, you simply
use the cp command as so:
# cp a1.3 /dev/fd0
cp may work on other UNIX systems as well.
A.5 Using a swap file
Instead of reserving an individual partition for swap space, you can
use a file. However, to do so you'll need install the Linux software
and get everything going before you create the swap file.
If you have a Linux system installed, you can use the following
commands to create a swap file. Below, we're going to create a
swap file of size 8208 blocks (about 8 megs).
# dd if=/dev/zero of=/swap bs=1024 count=8208
This command creates the swap file itself. Replace the "count="
with the size of the swap file in blocks.
# swapon /swap
Now we are swapping on the file /swap which we have created.
The one major drawback to using a swapfile in this manner is
that all access to the swap file is done through the filesystem. This
means that the blocks which make up the swap file may not be
contiguous. Therefore, performance may not be as great as using
a swap partition, for which blocks are always contiguous and I/O
requests are done directly to the device.
Another drawback in using a swapfile is the chance to cor-
rupt your filesystem data_when using large swap files, there is
the chance that you can corrupt your filesystem if something goes
wrong. Keeping your filesystems and swap partitions seperate will
prevent this from happening.
Using a swap file can be very useful if you have a temporary
need for more swap space. For example, if you're compiling a
large program and would like to speed things up somewhat, you
can temporarily create a swap file and use it in addition to your
regular swap space.
To get rid of a swap file, first use swapoff, as in
# swapoff /swap
And you can safely delete the file.
# rm /swap
Remember that each swap file (or partition) may be a large as
16 megabytes, but you may use up to 8 swap files or partitions on
your system.
Appendix B
Bibliography and Sources of Information
This appendix provides a listing of other valuable sources of infor-
mation about Linux, including recommended UNIX books which
would be of use to the new Linux user.
B.1 The Linux Frequently Asked Questions List
The Linux FAQ is a listing of frequently asked questions and an-
swers about Linux. It is a large document which covers almost
every problem relevant to the Linux community. However, the cur-
rent Linux FAQ is a large, bloated document which is in dire need
of reorganization. Matt Welsh and Ian Jackson are currently work-
ing on a complete rewrite of the Linux FAQ. Hopefully it will be
complete by the time you read this manual!
The Linux FAQ can be retrieved from a number of FTP sites
worldwide. The canonical location is sunsite.unc.edu, in the
file /pub/Linux/docs/FAQ. The directory /pub/Linux/docs/faqs
contains other versions of the FAQ, including texinfo and .dvi
format. You can find a number of other Linux documents in this
directory as well.
The Linux FAQ is also posted monthly to the USENET news-
groups comp.os.linux, comp.os.linux.announce, and news.answers.
If you don't have USENET or FTP access, you can retrieve the
Linux FAQ via the mail server at rtfm.mit.edu. Send mail to the
address
mail-server@rtfm.mit.edu
with the word "help" in the body.
It is also distributed as part of several Linux releases, such as
SLS and the Yggdrasil CD-ROM.
If you simply can't find a copy of the Linux FAQ any other way,
feel free to mail Matt Welsh at mdw@tc.cornell.edu; I can send
it to you directly.
B.2 The Linux Documentation Project Manuals
The Linux Documentation Project is in the process of providing a
number of manuals and books for Linux (including this one!). The
current location for publicly-available LDP manuals is /pub/linux/ALPHA/LDP
on tsx-11.mit.edu. See the file INDEX for a listing of what's avail-
able.
The LDP manuals currently under development are: The Lin-
ux System Administrator's Guide, Linux Network Administrator's
Guide, Linux Kernel Hacker's Guide, Linux User's Guide, and, of
course, Linux Installation and Getting Started. All of these are in
various states of completion.
Keep in mind the manuals in this directory are under development_
that is, there may be parts and sections still to be written, and
everything may not be completely accurate. Once the manuals are
"complete", they will be moved to another location.
B.3 Other Online Documents
There are a number of other online documents of interest to new
Linux users.
B.3.1 The Linux INFO-SHEET
The INFO-SHEET is a short document giving some of the technical
details of Linux, including hardware requirements and other infor-
mation. You can find it on sunsite.unc.edu:/pub/Linux/docs/INFO-SHEET.
It is posted to the various Linux USENET newsgroups as well.
B.3.2 The Linux META-FAQ
The Linux META-FAQ is a collection of Linux sources of informa-
tion (much like this appendix). It serves as a general introduction
to getting Linux information; most of the material therein is cov-
ered in this manual. This file can be found on
sunsite.unc.edu:/pub/Linux/docs/META-FAQ.
B.3.3 The Linux Hardware Compatibility List
The Hardware Compatibility List lists some of the hardware which
is known to work with Linux. However, much of the hardware is not
on this list; for example, all IDE drives should work with Linux, so
all makes and models are not listed there. The Hardware Compati-
bility List is in the file sunsite.unc.edu:/pub/Linux/docs/HARDWARE.
B.3.4 The Linux Software Map
The Linux Software Map is a listing of some of the available soft-
ware for Linux, where to get it, and who maintains it. However, the
LSM is far from complete; most of the people who distribute soft-
ware for Linux haven't added entries to it (also, the LDM project
is relatively new). Therefore, keep in mind that there is much more
software available for Linux than is actually listed in the LSM.
The current version of the LSM can be found on sunsite.unc.edu
in the file /pub/Linux/docs/LSM.z. This is a gzipped file; you
must use the gzip utility to uncompress it.
B.3.5 The Linux NET-2-FAQ
The Linux NET-2-FAQ is a guide to setup and configuring TCP/IP
networking software under Linux (see Section 6.2). The most recent
version can be found on sunsite.unc.edu in the file /pub/Linux/docs/NET-2-FAQ.
B.3.6 Others
On sunsite.unc.edu:/pub/Linux/docs are a number of other
documents related to Linux. Most of these aren't of concern to
the new user; all of the introductory and installation material for
Linux is covered in this manual.
B.4 Linux USENET Newsgroups
There are two USENET newsgroups are devoted to Linux. These
are comp.os.linux, for general questions and discussion about Lin-
ux, and comp.os.linux.announce, which is a moderated news-
group for Linux announcements and bug patches. Submissions to
comp.os.linux.announce must be approved by the moderator,
Matt Welsh, before they are posted. When posting to c.o.l.a,
your news software will usually automatically mail the posting to
the moderator for approval. However, if your news software is not
configured correctly, you may have to mail the posting directly to
the address linux-announce@tc.cornell.edu.
Postings in comp.os.linux.announce are archived on sunsite.unc.edu
in the directory /pub/Linux/docs/linux-announce.archive. Traf-
fic to c.o.l.a is also mirrored to the "ANNOUNCE" channel of the
linux-activists mailing list; see the next section for details.
Traffic in comp.os.linux is very high_it is one of the most
popular newsgroups on USENET. It is strongly suggested that y-
ou read the Linux FAQ and read the newsgroup before posting
any questions_more than likely, your question has already been
covered in the newsgroup. You should use a threaded newsread-
er, such as nn or trn, if you want to follow the high volume in
comp.os.linux.
B.5 Linux Mailing Lists
There are a number of mailing lists available for the Linux commu-
nity as well. The most prominent of these is the linux-activists
mailing list. This list is generally for developers and programmer-
s for Linux_there are very few discussions relating to using or
installing Linux. All such user questions about Linux should be
directed to the newsgroup comp.os.linux instead.
The linux-activists mailing list is a multi-channel mailing
list; that is, you join a particular "channel" and receive mail (usu-
ally in digest format) for that channel only. You can join multiple
channels if you wish. For more information on joining this mailing
list, send mail to
linux-announce-request@niksula.hut.fi
with the word "help" in the subject.
B.6 Bibliography
At present, the only books devoted to Linux are those distributed
by the Linux Documentation Project. However, many of the books
available for other versions of UNIX are relevant to Linux as well.
Title: Learning the UNIX Operating System
Author: Grace Todino & John Strang
Publisher: O'Reilly and Associates, 1987
ISBN: 0-937175-16-1, $9.00
A good introductory book on learning the UNIX
operating system. Most of the information should be
applicable to Linux as well. I suggest reading this book
if you're new to UNIX and really want to get started
with using your new system.
Title: Learning the vi Editor
Author: Linda Lamb
Publisher: O'Reilly and Associates, 1990
ISBN: 0-937175-67-6, $21.95
This is a complete book about the vi editor, a pow-
erful text editor found on every UNIX system in the
world. It's often important to know and be able to use
vi, because you won't always have access to a "real"
editor such as Emacs.
Title: Essential System Administration
Author: AEleen Frisch
Publisher: O'Reilly and Associates, 1991
ISBN: 0-937175-80-3, $29.95
From the O'Reilly and Associates Catalog, "Like
any other multi-user system, UNIX requires some care
and feeding. Essential System Administration tells y-
ou how. This book strips away the myth and confu-
sion surrounding this important topic and provides a
compact, manageable introduction to the tasks faced
by anyone responsible for a UNIX system." I couldn't
have said it better myself.
Title: TCP/IP Network Administration
Author: Craig Hunt
Publisher: O'Reilly and Associates, 1990
ISBN: 0-937175-82-X, $24.95
A complete guide to setting up and running a TCP/IP
network. While this book is not Linux-specific, rough-
ly 90% of it is applicable to Linux. Coupled with the
Linux NET-2-FAQ and Linux Network Administrator's
Guide, this is a great book discussing the concepts and
technical details of managing TCP/IP.
Title: Managing UUCP and Usenet
Author: Tim O'Reilly and Grace Todino
Publisher: O'Reilly and Associates, 1991
ISBN: 0-937175-93-5, $24.95
This book covers how to install and configure U-
UCP networking software, including configuration for
USENET news. If you're at all interested in using U-
UCP or accessing USENET news on your system, this
book is a must-read. See Sections 6.3 and 6.5 for more
information on UUCP and USENET for Linux.
Title: Practical UNIX Security
Author: Simson Garfinkel & Gene Spafford
Publisher: O'Reilly and Associates, 1991
ISBN: 0-937175-72-2, $29.95
This is an excellent book on UNIX system security.
It taught me quite a few things that I didn't know, even
with several years of UNIX system administration ex-
perience. As most UNIX books, this book is geared for
large systems, but almost all of the content is relevant
to Linux.
Title: X Window System User's Guide
Author: Valerie Quercia & Tim O'Reilly
Publisher: O'Reilly and Associates, 1993
ISBN: 1-56592-014-7, $34.95
A complete tutorial and reference guide to using the
X Window System. If you installed X windows on your
Linux system, and want to know how to get the most
out of it, you should read this book. Unlike some win-
dowing systems, a lot of the power provided by X is
not obvious as first sight. After using X Windows for
several years I learned some things by reading through
this book.
Title: Using C on the UNIX System
Author: Dave Curry
Publisher: O'Reilly and Associates, 1989
ISBN: 0-937175-23-4, $24.95
This book will introduce you to all of the aspects
of programming on the UNIX system call level. It cov-
ers everything from files to terminal I/O to TCP/IP
sockets. If you want to develop software for Linux, this
book is a must read.
Appendix C
FTP Tutorial and Site List
FTP ("File Transfer Protocol") is the set of programs that are used
for transferring files between systems on the Internet. Most UNIX,
VMS, and MS-DOS systems on the Internet have a program called
ftp which you use to transfer these files, and if you have Internet
access, the best way to download the Linux software is by using ftp.
This appendix covers basic ftp usage_of course, there are many
more functions and uses of ftp than are given here. Chapter 2 tells
you how to use FTP to download the Linux software.
At the end of this appendix there is a listing of FTP sites where
Linux software can be found.
If you're using an MS-DOS, UNIX, or VMS system to download
files from the Internet, then ftp is a command-driven program.
However, there are other implementations of ftp out there, such
as the Macintosh version (called Fetch) which has a nice menu-
driven interface, which is quite self-explanatory. Even if you're not
using the command-driven version of ftp, the information given
here should help.
ftp can be used to both upload (send) or download (receive)
files from other Internet sites. In most situations, you're going to be
downloading software. On the Internet there are a large number of
publicly-available FTP archive sites, machines which allow any-
one to ftp to them and download free software. One such archive
site is sunsite.unc.edu, which has a lot of Sun Microsystems soft-
ware, and acts as one of the main Linux sites. In addition, FTP
archive sites mirror software to each other_that is, software up-
loaded to one site will be automatically copied over to a number of
other sites. So don't be surprised if you see the exact same files on
many different archive sites.
C.1 Starting ftp
Before you start ftp you need a site to connect to. Note that in the
example "screens" printed below I'm only showing the most impor-
tant information, and what you see may differ. Also, commands in
italics represent commands that you type; everything else is screen
output.
To start ftp and connect to a site, give simply use the command
ftp <hostname>
where <hostname> is the name of the site you are connecting to.
For example, to connect to the mythical site shoop.vpizza.com
we can use the command
ftp shoop.vpizza.com
C.2 Logging In
When ftp starts up we should see something like
Connected to shoop.vpizza.com.
220 Shoop.vpizza.com FTPD ready at 15 Dec 1992 08:20:42
EDT
Name (shoop.vpizza.com:mdw):
Here, ftp is asking us to give the username that we want to login
as on shoop.vpizza.com. The default here is mdw, which is my
username on the system I'm using FTP from. Since I don't have
an account on shoop.vpizza.com I can't login as myself. Instead,
to access publicly-available software on an FTP site you login as
anonymous, and give your Internet e-mail address (if you have one)
as the password. So, we would type
Name (shoop.vpizza.com:mdw): anonymous
331-Guest login ok, send e-mail address as password.
Password: mdw@tc.cornell.edu
230- Welcome to shoop.vpizza.com.
230- Virtual Pizza Delivery[tm]: Download pizza in 30 cycles or less
230- or you get it FREE!
ftp>
Of course, in you should give your e-mail address, instead of mine,
and it won't echo to the screen as you're typing it (since it's tech-
nically a "password"). ftp should allow us to login and we'll be
ready to download software.
C.3 Poking Around
Okay, we're in. ftp> is our prompt, and the ftp program is waiting
for commands. There are a few basic commands you need to know
about. First, the commands
ls <file>
and
dir <file>
both give file listings (where <file> is an optional argument specify-
ing a particular filename to list). The difference is that ls usually
gives a short listing and dir gives a longer listing (that is, with
more information on the sizes of the files, dates of modification,
and so on).
The command
cd <directory>
will move to the given directory (just like the cd command on UNIX
or MS-DOS systems). You can use the command
cd ..
to change to the parent directory (*Note: The directory above the
current one.). Note the space between the "cd" and the "..".
The command
help <command>
will give help on the given ftp <command> (such as ls or cd). If no
command is specified, ftp will list all of the available commands.
If we type dir at this point we'll see an initial directory listing
of where we are.
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 1337
dr-xr-xr-x 2 root wheel 512 Aug 13 13:55 bin
drwxr-xr-x 2 root wheel 512 Aug 13 13:58 dev
drwxr-xr-x 2 root wheel 512 Jan 25 17:35 etc
drwxr-xr-x 19 root wheel 1024 Jan 27 21:39 pub
drwxrwx-wx 4 root ftp-admi 1024 Feb 6 22:10 uploads
drwxr-xr-x 3 root wheel 512 Mar 11 1992 usr
226 Transfer complete.
921 bytes received in 0.24 seconds (3.7 Kbytes/s)
ftp>
Each of these entries is a directory, not an individual file which
we can download (specified by the d in the first column of the
listing). On most FTP archive sites, the publicly available software
is under the directory /pub, so let's go there.
ftp> dir
200 PORT command successful.
150 ASCII data connection for /bin/ls (128.84.181.1,4525)
(0 bytes).
total 846
-rw-r--r-- 1 root staff 1433 Jul 12 1988 README
-r--r--r-- 1 65534 65534 56456 Dec 17 1990 ataxx.tar.Z
-rw-r--r-- 1 root other 2013041 Jul 3 1991 gesyps.tar.Z
-rw-r--r-- 1 432 staff 41831 Jan 30 1989 gnexe.arc
-rw-rw-rw- 1 615 staff 50315 Apr 16 1992 linpack.tar.Z
-r--r--r-- 1 root wheel 12168 Dec 25 1990 localtime.o
-rw-r--r-- 1 root staff 7035 Aug 27 1986 manualslist
drwxr-xr-x 2 2195 staff 512 Mar 10 00:48 mdw
-rw-r--r-- 1 root staff 5593 Jul 19 1988 t.out.h
226 ASCII Transfer complete.
2443 bytes received in 0.35 seconds (6.8 Kbytes/s)
ftp>
Here we can see a number of (interesting?) files, one of which
is called README, which we should download (most FTP sites have
a README file in the /pub directory).
C.4 Downloading files
Before downloading files, there are a few things that you need to
take care of.
o Turn on hash mark printing. Hash marks are printed to
the screen as files are being transferred; they let you know
how far along the transfer is, and that your connection hasn't
hung up (so you don't sit for 20 minutes, thinking that you're
still downloading a file). In general, a hash mark appears as
a pound sign (#), and one is printed for every 1024 or 8192
bytes transferred, depending on your system.
To turn on hash mark printing, give the command hash.
ftp> hash
Hash mark printing on (8192 bytes/hash mark).
ftp>
o Determine the type of file which you are download-
ing. As far as FTP is concerned, files come in two flavors:
binary and text. Most of the files which you'll be downloading
are binary files: that is, programs, compressed files, archive
files, and so on. However, many files (such as READMEs and
so on) are text files.
Why does the file type matter? Only because on some sys-
tems (such as MS-DOS systems), certain characters in a text
file, such as carriage returns, need to be converted so that the
file will be readable. While transferring in binary mode, no
conversion is done_the file is simply transferred byte after
byte.
The commands bin and ascii set the transfer mode to bina-
ry and text, respectively. When in doubt, always use binary
mode to transfer files. If you try to transfer a binary file
in text mode, you'll corrupt the file and it will be unusable.
(This is one of the most common mistakes made when using
FTP.) However, you can use text mode for plain text files
(whose filenames often end in .txt).
For our example, we're downloading the file README, which is
most likely a text file, so we use the command
ftp> ascii
200 Type set to A.
ftp>
o Set your local directory. Your local directory is the di-
rectory on your system where you want the downloaded files
to end up. Whereas the cd command changes the remote
directory (on the remote machine which you're FTPing to),
the lcd command changes the local directory.
For example, to set the local directory to /home/db/mdw/tmp,
use the command
ftp> lcd /home/db/mdw/tmp
Local directory now /home/db/mdw/tmp
ftp>
Now you're ready to actually download the file. The command
get <remote-name> <local-name>
is used for this, where <remote-name> is the name of the file on
the remote machine, and <local-name> is the name that you wish
to give the file on your local machine. The <local-name> argu-
ment is optional; by default, the local filename is the same as the
remote one. However, if for example you're downloading the file
foo.txt, and you already have a foo.txt in your local directory,
you'll want to give a different <local-filename> so that the first one
isn't overwritten.
For our example, to download the file README, we simply use
ftp> get README
200 PORT command successful.
150 ASCII data connection for README (128.84.181.1,4527)
(1433 bytes).
#
226 ASCII Transfer complete.
local: README remote: README
1493 bytes received in 0.03 seconds (49 Kbytes/s)
ftp>
C.5 Quitting FTP
To end your FTP session, simply use the command
quit
The command
close
can be used to close the connection with the current remote FTP
site; the open command can then be used to start a session with
another site (without quitting the FTP program altogether).
ftp> close
221 Goodbye.
ftp> quit
C.6 Linux FTP Site List
Table C.1 is a listing of the most well-known FTP archive sites
which carry the Linux software. Keep in mind that many other
sites mirror these, and more than likely you'll run into Linux on a
number of sites not on this list.
tsx-11.mit.edu, sunsite.unc.edu, and nic.funet.fi are the
"home sites" for the Linux software, where most of the new soft-
ware is uploaded. Most of the other sites on the list mirror some
combination of these three. To reduce network traffic, choose a site
which is geographically closest to you.
Site name IP Address Directory
----------------------------------- -------------------- --------------------
tsx-11.mit.edu 18.172.1.2 /pub/linux
sunsite.unc.edu 152.2.22.81 /pub/Linux
nic.funet.fi 128.214.6.100 /pub/OS/Linux
ftp.mcc.ac.uk 130.88.200.7 /pub/linux
fgb1.fgb.mw.tu-muenchen.de 129.187.200.1 /pub/linux
ftp.informatik.tu-muenchen.de 131.159.0.110 /pub/Linux
ftp.dfv.rwth-aachen.de 137.226.4.105 /pub/linux
ftp.informatik.rwth-aachen.de 137.226.112.172 /pub/Linux
ftp.ibp.fr 132.227.60.2 /pub/linux
kirk.bu.oz.au 131.244.1.1 /pub/OS/Linux
ftp.uu.net 137.39.1.9 /systems/unix/linux
wuarchive.wustl.edu 128.252.135.4 /systems/linux
ftp.win.tue.nl 131.155.70.100 /pub/linux
ftp.stack.urc.tue.nl 131.155.2.71 /pub/linux
ftp.ibr.cs.tu-bs.de 134.169.34.15 /pub/os/linux
ftp.denet.dk 129.142.6.74 /pub/OS/linux
Table C.1: Linux FTP Sites
Appendix D
Linux BBS List
Oops. The BBS list doesn't look very good in ASCII mode, and it took me
forever to format it. You can download the original Linux BBS list from
sunsite.unc.edu:/pub/Linux/docs or get it from Zane Healy
<healyzh@holonet.net>. The BBS list is included in the .dvi and PostScript
version of this book.
Appendix E
The GNU General Public License
Printed below is the GNU General Public License (the GPL or
copyleft), under which Linux is licensed. It is reproduced here to
clear up some of the confusion about Linux's copyright status---Linux is not
shareware, and it is not in the public domain. The bulk of the Linux kernel
is copyright (c)1993 by Linus Torvalds, and other software and parts of the
kernel are copyrighted by their authors. Thus, Linux is copyrighted, however,
you may redistribute it under the terms of the GPL printed below.
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
675 Mass Ave, Cambridge, MA 02139, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
Appendix: How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) 19yy <name of author>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.
Reference in New Issue View Git Blame Copy Permalink