If you’re running your own Linux system, one of the first tasks at hand is to learn the ropes of system administration. You won’t be able to get by for long without having to perform some kind of system maintenance, software upgrade, or mere tweaking to keep things in running order.
Running a Linux system is not unlike riding and taking care of a motorcycle.[11] Many motorcycle hobbyists prefer caring for their own equipment — routinely cleaning the points, replacing worn-out parts, and so forth. Linux gives you the opportunity to experience the same kind of “hands-on” maintenance with a complex operating system.
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, system 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 XFree86 3.3.6 to XFree86 4.0.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, performing backups, and what to do in emergencies.
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 prefer to 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.) But we’ll also show you something even more important: after installing a Linux distribution, you usually have lots of services running that you may not need (like a web server). Any of these services could be a potential security hole, so you might want to fiddle with the startup files to get only the services you absolutely need.
It should be noted that many Linux systems include fancy tools to simplify many system administration tasks. These include YaST on SuSE systems, COAS on Caldera systems, and a number of utilities on Red Hat systems. These tools can do everything from managing user accounts to creating filesystems to doing your laundry. These utilities can make your life either 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, by Evi Nemeth et. al. (Prentice Hall) and Essential System Administration, by Æleen Frisch (O’Reilly).
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 to whom it belongs.
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 be readable, writable, or executable only by certain groups of other users, or by 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 Section 6.3 in
Chapter 6) 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 it 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 an 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
multiple administrators are on the machine: it is often desirable to
find out who used su and when.
There is an additional little twist to the su
command. Just running it as described previously while only change
your user ID, but not give you the settings made for this ID. You
might have special configuration files for each user
(we’ll show you later how to create these), but
these are not executed when using su this way. In
order to emulate a real login with all the configuration files being
executed, you need to add a -
, like this:
su - andy
or
su -
for becoming root
and executing
root
’s configuration files.
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
accidentally slip in a space after the first slash, producing the
following:
rm -rf / usr/src/oldp
Also problematic are directory names with spaces in them.
Let’s say you have directory names Dir
1
and Dir 2
, where the backslash
indicates that Dir 1
is really one filename
containing a space character. Now you want to delete both
directories, but by mistake add an extra space again:
rm -rf Dir *
Now there are two spaces between the backslash and the asterisk. The first one is protected by the backslash, but not the second one, so it separates the arguments and makes the asterisk a new argument. Oops, your current directory and everything below it are gone.
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
. More likely than not,
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.
A nice tip is to use the
alias
command to make some of the commands
less dangerous for root
. For example, you could
use:
alias rm="rm -i"
The -i
option stands for
interactively and means that the
rm command will ask you before deleting each file.
Of course, this does not protect you against the horrible mistake
shown above; the -f
option (which stands for
force) simply overrides the -i
because it comes later.
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.
[11] At least one author attests a strong correspondence between Linux system administration and Robert Pirsig’s Zen and the Art of Motorcycle Maintenance. Does Linux have the Buddha nature?