 |  |
| |
Maintaining the System
Booting the System
System Startup and Initialization
Single-User Mode
Shutting Down the System
The /proc Filesystem
Managing User Accounts
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.
[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?
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.
|  | |
| 4.18. Processes |  | 5.2. Booting the System |
Copyright © 2003 O'Reilly & Associates. All rights reserved.