While a passionate administrator can spend any amount of time tuning
it for performance, you really have to perform administration only
when a major change occurs: you install a new disk, a new user comes
on the system, or a power failure causes the system to go down
unexpectedly. We discuss all these situations over the next four
chapters.
Linux is surprisingly accessible, in all respects--from the more
mundane tasks of upgrading shared libraries to the more esoteric, such
as mucking about with the kernel. Because all the source code is
available, and the body of Linux developers and users has
traditionally been of the hackish breed, systems maintenance is not
only a part of daily life but also a great learning experience. Trust
us: there's nothing like telling your friends how you upgraded from
X11R6.1 to X11R6.3 in less than half an hour, and all the while you were
recompiling the kernel to support the ISO 9660
filesystem.
(They may have no idea what you're talking about, in which
case you can give them a copy of this book.)
In the next few chapters, we explore your Linux system from the
mechanic's point of view--showing you what's under the hood, as
it were--and explain how to take care of it all, including
software upgrades, managing users, filesystems, and other resources,
taking backups, and what to do in emergencies. If you've never used a
Unix system before, we'll also take you for a test
drive and show you the basics of running and using the system.
Once you put the right entries in startup files, your Linux system
will, for the most part, run itself. As long as you're happy with the
system configuration and the software that's running on it, very
little work will be necessary on your part. However, we'd like to
encourage Linux users to experiment with their system and customize it
to taste. Very little about Linux is carved in stone, and if
something doesn't work the way that you'd like it to, you should be
able to change that. For instance, if you'd rather read blinking
green text on a cyan background, rather than the traditional
white-on-black, we'll show you how to configure that. (As long as you
promise not to let anyone know who told you.)
It should be noted that many Linux systems include fancy tools to
simplify many system administration tasks. These include YaST on SuSE
systems, LISA on Caldera systems, and the
control-panel or linuxconf on
Red Hat systems. These tools can do
everything from managing user accounts to creating filesystems to
doing your laundry. These utilities can either make your life easier
or more difficult, depending on how you look at them. In these
chapters, we present the "guts" of system administration,
demonstrating the tools that should be available on any Linux system
and indeed nearly all Unix systems. These are the
core of the system administrator's toolbox: the metaphorical hammer,
screwdriver, and socket wrench that you can rely on to get the job
done. If you'd rather use the 40-hp circular saw, feel free, but it's
always nice to know how to use the hand tools in case the power goes
out.
Good follow-up books, should you wish to investigate more topics in
Unix system administration, include the
Unix System Administration
Handbook and Essential System
Administration.
5.1. Running the System
Being the system administrator for any Unix system
requires a certain degree of responsibility and care. This is equally
true for Linux, even if you're the only user on your system.
Many of the system administrator's tasks are done by logging into the
root account. This account has
special properties on Unix systems; specifically,
the usual file permissions and other security mechanisms simply don't
apply to root. That is,
root can access and modify any
file on the system--no matter who it belongs to. Whereas normal
users can't damage the system (say, by corrupting filesystems or
touching other users' files), root has no such restrictions.
Why does the Unix system have security in the first
place? The most obvious reason for this is to allow users to choose
how they wish their own files to be accessed. By changing
file-permission bits (with the chmod command),
users can specify that certain files should only be readable,
writable, or executable by certain groups of other users or no other
users at all. Permissions help ensure privacy and integrity of data; you
wouldn't want other users to read your personal mailbox, for example,
or to edit the source code for an important program behind your back.
The Unix security mechanisms also prevent users
from damaging the system. The system restricts access to many of the
raw device files (accessed via /dev--more
on this in the section "Section 6.3, "Device Files"" in
Chapter 6, "Managing
Filesystems, Swap,
and Devices") corresponding to hardware,
such as your hard drives. If normal users could read and write
directly to the disk-drive device, they could wreak all kinds of
havoc: say, completely overwriting the contents of the drive. Instead,
the system requires normal users to access the drives via the
filesystem--where security is enforced via the file permission
bits described previously.
It is important to note that not all kinds of "damage"
that can be caused are necessarily malevolent. System security is more
a means to protect users from their own natural mistakes and
misunderstandings rather than to enforce a police state on the
system. And, in fact, on many systems security is rather lax;
Unix security is designed to foster the sharing of
data between groups of users who may be, say, cooperating on a
project. The system allows users to be assigned to groups, and file
permissions may be set for an entire group. For instance, one
development project might have free read and write permission to a
series of files, while at the same time other users are prevented from
modifying those files. With your own personal files, you get to decide
how public or private the access permissions should be.
The Unix security mechanism also prevents normal
users from performing certain actions, such as calling certain system
calls within a program. For example, there is a system call that
causes the system to halt, called by programs such as
shutdown (more on this later in the chapter) to
reboot the system. If normal users could call this function within
their programs, they could accidentally (or purposefully) halt the
system at any time.
In many cases, you have to bypass Unix security
mechanisms in order to perform system maintenance or upgrades. This is
what the root account is
for. Because no such restrictions apply to root, it is easy for a knowledgeable system
administrator to get work done without worrying about the usual file
permissions or other limitations.
The usual way to log in as root
is with the su command. su
allows you to assume the identification of another user--for
example:
su andy
will prompt you for the password for andy, and if it is correct will set your user
ID to that of andy. A superuser
often wants to temporarily assume a regular user's identity to correct
a problem with that user's files or some similar reason. Without a
username argument,
su will prompt you for the
root password, validating your
user ID as root. Once you are
finished using the root account,
you log out in the usual way and return to your own mortal identity.
Why not simply log in as root
from the usual login prompt? As we'll see, this is desirable in some
instances, but most of the time it's best to use su
after logging in as yourself. On a system with many users, use of
su records a message such as:
Nov 1 19:28:50 loomer su: mdw on /dev/ttyp1
in the system logs, such as
/var/log/messages
(we'll talk more about these files later). This message indicates that
the user mdw successfully issued
a
su command, in this case for root. If you were to log in directly as root, no such message would appear in the
logs; you wouldn't be able to tell which user was mucking about with
the root account. This is
important if there are multiple administrators on the machine: it is
often desirable to find out who used
su and when.
The root account can be
considered a magic wand--both a useful and potentially dangerous
tool. Fumbling the magic words you invoke while holding this wand can
wreak unspeakable damage on your system. For example, the simple
eight-character sequence rm -rf / will
delete every file on your system, if executed as root, and if you're not paying attention.
Does this problem seem far-fetched? Not at all. You might be trying
to delete an old directory, such as
/usr/src/oldp, and accidently slip in a space
after the first slash, producing the following:
rm -rf / usr/src/oldp
Another common mistake is to confuse the
arguments for commands such as dd, a command often
used to copy large chunks of data from one place to another. For
instance, in order to save the first 1024 bytes of data from the
device /dev/hda (which contains the boot record
and partition table for that drive), one might use the command:
dd if=/dev/hda of=/tmp/stuff bs=1k count=1
However, if we reverse
if and
of
in this command, something quite different happens: the contents
of
/tmp/stuff are written to the top of
/dev/hda. If
/tmp/stuff
contains garbage or incorrect data, you've just succeeded in hosing
your partition table and possibly a filesystem superblock. Welcome to
the wonderful world of system administration!
The point here is that you should sit on your hands before executing
any command as root. Stare at the
command for a minute before pressing Enter and make sure it makes
sense. If you're not sure of the arguments and syntax of the command,
quickly check the manual pages or try the command in a safe
environment before firing it off. Otherwise you'll learn these
lessons the hard way; mistakes made as root can be disastrous.
In many cases, the prompt for the root account differs from that for normal
users. Classically, the root
prompt contains a hash mark (#), while normal user
prompts contain $ or %. (Of
course, use of this convention is up to you; it is utilized on many
Unix systems, however.) Although the prompt may
remind you that you are wielding the root magic wand, it is not uncommon for users
to forget this or accidentally enter a command in the wrong window or
virtual console.
Like any powerful tool, the root
account can also be abused. It is important, as the system
administrator, to protect the root password, and if you give it out at
all, to give it only to those users whom you trust (or who can be held
responsible for their actions on the system). If you're the only user
of your Linux system, this certainly doesn't apply--unless, of
course, your system is connected to a network or allows dial-in login
access.
The primary benefit of not sharing the root account with other users
is not so much that the potential for abuse is diminished, although
this is certainly the case. Even more important is that if you're
the one person with the ability to use the root account, you have
complete knowledge of how the system is configured. If anyone were
able to, say, modify important system files (as we'll talk about in this
chapter), the system configuration could be changed behind your
back, and your assumptions about how things work would be incorrect.
Having one system administrator act as the arbiter for the system
configuration means that one person always knows what's going on.
Also, allowing other people to have the root password means that it's
more likely someone will eventually make a mistake using the
root account. Although each
person with knowledge of the root password may be trusted, anybody can
make mistakes. If you're the only system administrator, you have only
yourself to blame for making the inevitable human mistakes as
root.
That being said, let's dive into the actual tasks of system administration
under Linux. Buckle your seatbelt.
