Inhaltsverzeichnis von Essential System Administration : Tools and Techniques for Linux and Unix Administration

Inhaltsvorschau

The traditional way to begin a book like this is to provide a list of system administration tasks—I've done it several times myself at this point. Nevertheless, it's important to remember that you have to take such lists with a grain of salt. Inevitably, they leave out many intangibles, the sorts of things that require lots of time, energy, or knowledge, but never make it into job descriptions. Such lists also tend to suggest that system management has some kind of coherence across the vastly different environments in which people find themselves responsible for computers. There are similarities, of course, but what is important on one system won't necessarily be important on another system at another site or on the same system at a different time. Similarly, systems that are very different may have similar system management needs, while nearly identical systems in different environments might have very different needs.

But now to the list. In lieu of an idealized list, I offer the following table showing how I spent most of my time in my first job as full-time system administrator (I managed several central systems driving numerous CAD/CAM workstations at a Fortune 500 company) and how these activities have morphed in the intervening two decades.

Table 1-1: Typical system administration tasks
Then: early 1980s	Now: early 2000s
Adding new users.	I still do it, but it's automated, and I only have to add a user once for the entire network. Converting to LDAP did take a lot of time, though.
Adding toner to electrostatic plotters.	Printers need a lot less attention—just clearing the occasional paper jam—but I still get my hands dirty changing those inkjet tanks.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

I've touched briefly on some of the nontechnical aspects of system administration. These dynamics will probably not be an issue if it really is just you and your PC, but if you interact with other people at all, you'll encounter these issues. It's a cliché that system administration is a thankless job—one widely-reprinted cartoon has a user saying "I'd thank you but system administration is a thankless job"—but things are actually more complicated than that. As another cliché puts it, system administration is like keeping the trains on time; no one notices except when they're late.

System management often seems to involve a tension between authority and responsibility on the one hand and service and cooperation on the other. The extremes seem easier to maintain than any middle ground; fascistic dictators who rule "their system" with an iron hand, unhindered by the needs of users, find their opposite in the harried system managers who jump from one user request to the next, in continual interrupt mode. The trick is to find a balance between being accessible to users and their needs—and sometimes even to their mere wants—while still maintaining your authority and sticking to the policies you've put in place for the overall system welfare. For me, the goal of effective system administration is to provide an environment where users can get done what they need to, in as easy and efficient a manner as possible, given the demands of security, other users' needs, the inherent capabilities of the system, and the realities and constraints of the human community in which they all are located.

To put it more concretely, the key to successful, productive system administration is knowing when to solve a CPU-overuse problem with a command like:

# kill -9 `ps aux | awk '$1=="chavez" {print $2}'

(This command blows away all of user chavez's processes.) It's also knowing when to use:

$ write chavez 

You've got a lot of identical processes running on dalton. 

Any problem I can help with? 

^D

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

On a Unix system, the superuser refers to a privileged account with unrestricted access to all files and commands. The username of this account is root. Many administrative tasks and their associated commands require superuser status.

There are two ways to become the superuser. The first is to log in as root directly. The second way is to execute the command su while logged in to another user account. The su command may be used to change one's current account to that of a different user after entering the proper password. It takes the username corresponding to the desired account as its argument; root is the default when no argument is provided.

After you enter the su command (without arguments), the system prompts you for the root password. If you type the password correctly, you'll get the normal root account prompt (by default, a number sign: #), indicating that you have successfully become superuser and that the rules normally restricting file access and command execution do not apply. For example:

$ su 

Password:   Not echoed

#

If you type the password incorrectly, you get an error message and return to the normal command prompt.

You may exit from the superuser account with exit or Ctrl-D. You may suspend the shell and place it in the background with the suspend command; you can return to it later using fg.

When you run su, the new shell inherits the environment from your current shell environment rather than creating the environment that root would get after logging in. However, you can simulate an actual root login session with the following command form:

$ su -

Unlike some other operating systems, the Unix superuser has all privileges all the time: access to all files, commands, etc. Therefore, it is entirely too easy for a superuser to crash the system, destroy important files, and create havoc inadvertently. For this reason, people who know the superuser password (including the system administrator) should

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The commands discussed in this section are simple and familiar to most Unix users. For this reason, they're often overlooked in system administration discussions. However, I believe you'll find them to be an indispensable part of your repertoire. One other important communications mechanism is electronic mail (see Chapter 9).

A system administrator frequently needs to send a message to a user's screen (or window). write is one way to do so:

$ write 

               username[tty]

where username indicates the user to whom you wish to send the message. If you want to write to a user who is logged in more than once, the tty argument may be used to select the appropriate terminal or window. You can find out where a user is logged in using the who command.

Once the write command is executed, communication is established between your terminal and the user's terminal: lines that you type on your terminal will be transmitted to him. End your message with a CTRL-D. Thus, to send a message to user harvey for which no reply is needed, execute a command like this:

$ write harvey 

               The file you needed has been restored. 

               Additional lines of message text 

               ^D

In some implementations (e.g., AIX, HP-UX and Tru64), write may also be used over a network by appending a hostname to the username. For example, the command below initiates a message to user chavez on the host named hamlet:

$ write chavez@hamlet

When available, the rwho command may be used to list all users on the local subnet (it requires a remote who daemon be running on the remote system).

The talk command is a more sophisticated version of write. It formats the messages between two users in two separate spaces on the screen. The recipient is notified that someone is calling her, and she must issue her own talk command to begin communication. Figure 1-1 illustrates the use of

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

For several years now, vendors and independent programmers have been developing elaborate system administration applications. The first of these were menu-driven, containing many levels of nested menus organized by subsystem or administrative task. Now, the trend is toward independent GUI-based tools, each designed to manage some particular system area and perform the associated tasks.

Whatever their design, all of them are designed to allow even relative novices to perform routine administrative tasks. The scope and aesthetic complexity of these tools vary considerably, ranging from shell scripts employing simple selections lists and prompts to form-based utiliti es running under X. A few even offer a mouse-based interface with which you perform operations by dragging icons around (e.g., dropping a user icon on top of a group icon adds that user to that group, dragging a disk icon into the trash unmounts a filesystem, and the like).

In this section, we'll take a look at such tools, beginning with general concepts and then going on to a few practical notes about the tools available on the systems we are considering (usually things I wish I had known about earlier). The tools are very easy to use, so I won't be including detailed instructions for using them (consult the appropriate documentation for that).

Graphical and menu-based system administration tools have some definite good points:

They can provide a quick start to system administration, allowing you to get things done while you learn about the operating system and how things work. The best tools include aids to help you learn the underlying standard administrative commands.

Similarly, these tools can be helpful in figuring out how to perform some task for the first time; when you don't know how to begin, it can be hard to find a solution with just the manual pages.
They can help you get the syntax right for complex commands with lots of options.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We'll close this chapter with a brief look at a nice utility that can be useful for keeping track of how you spend your time, information that system administrators will find comes in handy all too often. It is called plod and was written by Hal Pomeranz (see http://bullwinkle.deer-run.com/~hal/plod/). While there are similar utilities with a GUI interface (e.g., gtt and karm, from the Gnome and KDE window manager packages, respectively), I prefer this simpler one that doesn't require a graphical environment.

plod works by maintaining a log file containing time stamped entries that you provide; the files' default location is ~/.logdir/yyyymm, where yyyy and mm indicate the current year and month, respectively. plod log files can optionally be encrypted.

The command has lots of options, but its simplest form is the following:

$ plod [text]

If some text is included on the command, it is written to the log file (tagged with the current date and time). Otherwise, you enter the command's interactive mode, in which you can type in the desired text. Input ends with a line containing a lone period.

Once you've accumulated some log entries, you can use the command's -C, -P, and -E options to display them, either as continuous output, piped through a paging command like more (although less is the default), or via an editor (vi is the default). You can specify a different paging program or editor with the PAGER and EDITOR environment variables (respectively).

You can also use the -G option to search plod log files; it differs from grep in that matching entries are displayed in their entirety. By default, searches are not case sensitive, but you can use -g to make them so.

Here is an example command that searches the current log file:

$ plod -g hp-ux

-----

05/11/2001, 22:56 --

Starting to configure the new HP-UX box.

-----

05/11/2001, 23:44 --

Finished configuring the new HP-UX box.

Given these features, plod

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

It's easy to identify the most important issues and concerns system managers face, regardless of the type of computers they have. Almost every system manager has to deal with user accounts, system startup and shutdown, peripheral devices, system performance, security—the list could go on and on. While the commands and procedures you use in each of these areas vary widely across different computer systems, the general approach to such issues can be remarkably similar. For example, the process of adding users to a system has the same basic shape everywhere: add the user to the user account database, allocate some disk space for him, assign a password to the account, enable him to use major system facilities and applications, and so on. Only the commands to perform these tasks are different on different systems.

In other cases, however, even the approach to an administrative task or issue will change from one computer system to the next. For example, "mounting disks" doesn't mean the same thing on a Unix system that it does on aVMS orMVS system (where they're not always even called disks). No matter what operating system you're using—Unix, Windows 2000, MVS—you need to know something about what's happening inside, at least more than an ordinary user does.

Like it or not, a system administrator is generally called on to be the resident guru. If you're responsible for a multiuser system, you'll need to be able to answer user questions, come up with solutions to problems that are more than just band-aids, and more. Even if you're responsible only for your own workstation, you'll find yourself dealing with aspects of the computer's operation that most ordinary users can simply ignore. In either case, you need to know a fair amount about how Unix really works, both to manage your system and to navigate the eccentric and sometimes confusing byways of the often jargon-ridden technical documentation.

This chapter will explore the Unix approach to some basic computer entities: files, processes, and devices. In each case, I will discuss how the Unix approach affects system administration procedures and objectives. The chapter concludes with an overview of the standard Unix directory structure.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Files are central to Unix in ways that are not true for some other operating systems. Commands are executable files, usually stored in standard locations in the directory tree. System privileges and permissions are controlled in large part via access to files. Device I/O and file I/O are distinguished only at the lowest level. Even most interprocess communication occurs via file-like entities. Accordingly, the Unix view of files and its standard directory structure are among the first things a new administrator needs to know about.

Like all modern operating systems, Unix has a hierarchical (tree-structured) directory organization, know collectively as the filesystem . The base of this tree is a directory called the root directory. The root directory has the special name / (the forward slash character). On Unix systems, all user-available disk space is transparently combined into a single directory tree under /, and the physical disk a file resides on is not part of a Unix file specification. We'll discuss this topic in more detail later in this chapter.

Access to files is organized around file ownership and protection. Security on a Unix system depends to a large extent on the interplay between the ownership and protection settings on its files and the system's user account and group structure (as well as factors like physical access to the machine). The following sections discuss the basic principles of Unix file ownership and protection.

Unix file ownership is a bit more complex than it is under some other operating systems. You are undoubtedly familiar with the basic concept of a file having an owner: typically, the user who created it and has control over it. On Unix systems, files have two owners: a user owner and a group owner. What is unusual about Unix file ownership is that these two owners are decoupled. A file's group ownership is independent of the user who owns it. In other words, although a file's group owner is often, perhaps even usually, the same as the group its user owner belongs to, this is not required. In fact, the user owner of a file does need not even need to be a member of the group that owns it. There is no necessary connection between them at all. In such a case, when file access is specified for a file's group owner, it applies to members of that group and not to other members of its user owner's group, who are treated simply as part of "other": the rest of the world.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In simple terms, a process is a single executable program that is running in its own address space. It is distinct from a job or a command, which, on Unix systems, may be composed of many processes working together to perform a specific task. Simple commands like ls are executed as a single process. A compound command containing pipes will execute one process per pipe segment. For Unix systems, managing CPU resources must be done in large part by controlling processes, because the resource allocation and batch execution facilities available with other multitasking operating systems are underdeveloped or missing.

Unix processes come in several types. We'll look at the most common here.

Interactive processes are initiated from and controlled by a terminal session. Interactive processes may run either in the foreground or the background. Foreground processes remain attached to the terminal; the foreground process is the one with which the terminal communicates directly. For example, typing a Unix command and waiting for its output means running a foreground process.

While a foreground process is running, it alone can receive direct input from the terminal. For example, if you run the diff command on two very large files, you will be unable to run another command until it finishes (or you kill it with CTRL-C).

Job control allows a process to be moved between the foreground and the background at will. For example, when a process is moved from the foreground to the background, the process is temporarily stopped, and terminal control returns to its parent process (usually a shell). The background job may be resumed and continue executing unattached to the terminal session that launched it. Alternatively, it may eventually be brought to the foreground, and once again become the terminal's current process. Processes may also be started initially as background processes.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

One of the strengths of Unix is that users don't need to worry about the specific characteristics of devices and device I/O very often. They don't need to know, for example, what disk drive a file they want to access physically sits on. And the Unix special file mechanism allows many device I/O operations to look just like file I/O. As we've noted, the administrator doesn't have these same luxuries, at least not all the time. This section discusses Unix device handling and then surveys the special files used to access devices.

Device files are characterized by their majorandminor numbers , which allow the kernel to determine which device driver to use to access the device (via the major number), as well as its specific method of access (via the minor number).

Major and minor numbers appear in place of the file size in long directory listings. For example, consider these device files related to the mouse from a Linux system:

$ cd /dev; ls -l *mouse

crw-rw-r--    1 root     root      10,  10 Jan 19 03:36 adbmouse

crw-rw-r--    1 root     root      10,   4 Jan 19 03:35 amigamouse

crw-rw-r--    1 root     root      10,   5 Jan 19 03:35 atarimouse

crw-rw-r--    1 root     root      10,   8 Jan 19 03:35 smouse

crw-rw-r--    1 root     root      10,   6 Jan 19 03:35 sunmouse

crw-rw-r--    1 root     root      13,  32 Jan 19 03:36 usbmouse

The major number for all but the last special file is 10; only the minor number differs for these devices. Thus, all of these mouse device variations are handled by the same device driver, and the minor number indicates the variation within that general family. The final item, corresponding to a USB mouse, has a different major number, indicating that a different device driver is used.

Device files are created with the mknod command, and it takes the desired device name and major and minor numbers as its arguments. Many systems provide a script named MAKEDEV (located in /dev), which is an easy-to-use interface to

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The right tools make any job easier, and the lack of them can make some tasks almost impossible. When you need an Allen wrench, nothing but an Allen wrench will do. On the other hand, if you need a Phillips head srewdriver, you might be able to make do with a pocket knife, and occasionally it will even work better.

The first section of this chapter will consider ways the commands and utilities that Unix provides can make system administration easier. Sometimes that means applying common user commands to administrative tasks, sometimes it means putting commands together in unexpected ways, and sometimes it means making smarter and more efficient use of familiar tools. And, once in a while, what will make your life easier is creating tools for users to use, so that they can handle some things for themselves. We'll look at this last topic in Chapter 14.

The second section of this chapter will consider some essential administrative facilities and techniques, including the cron subsystem, the syslog facility, strategies for handling the many system log files, and management software packages. We'll close the chapter with a list of Internet software sources.

In this section, we consider advanced and administrative uses of familiar Unix commands.

The manual page facility is the quintessentially Unix approach to online help: superficially minimalist, often obscure, but mostly complete. It's also easy to use, once you know your way around it.

Undoubtedly, the basics of the man command are familiar: getting help for a command, specifying a specific section, using -k (or apropos) to search for entries for a specific topic, and so on.

There are a couple of man features that I didn't discover until I'd been working on Unix systems for years (I'd obviously never bothered to run man man). The first is that you can request multiple manual pages within a single man command:

$ man umount fsck newfs

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In this section, we consider advanced and administrative uses of familiar Unix commands.

The manual page facility is the quintessentially Unix approach to online help: superficially minimalist, often obscure, but mostly complete. It's also easy to use, once you know your way around it.

Undoubtedly, the basics of the man command are familiar: getting help for a command, specifying a specific section, using -k (or apropos) to search for entries for a specific topic, and so on.

There are a couple of man features that I didn't discover until I'd been working on Unix systems for years (I'd obviously never bothered to run man man). The first is that you can request multiple manual pages within a single man command:

$ man umount fsck newfs

man presents the pages as separate files to the display program, and you can move among them using its normal method (for example, with :n in more).

On FreeBSD, Linux, and Solaris systems, man also has a -a option, which retrieves the specified manual page(s) from every section of the manual. For example, the first command below displays the introductory manual page for every section for which one is available, and the second command displays the manual pages for both the chown command and system call:

$ man -a intro 

$ man -a chown

Manual pages are generally located in a predictable location within the filesystem, often /usr/share/man. You can configure the man command to search multiple man directory trees by setting the MANPATH environment variable to the colon-separated list of desired directories.

Section 3.1.1.1: Changing the search order

The man command searches the various manual page sections in a predefined order: commands first, followed by system calls and library functions, and then the other sections (i.e., 1, 6, 8, 2, 3, 4, 5, and 7 for BSD-based schemes). The first manual page matching the one specified on the command line is displayed. In some cases, a different order might make more sense. Many operating systems allow this ordering scheme to be customized via the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In this section, we consider several system facilities with which system administrators need to be intimately familiar.

cron is a Unix facility that allows you to schedule programs for periodic execution. For example, you can use cron to call a particular remote site every hour to exchange email, to clean up editor backup files every night, to back up and then truncate system log files once a month, or to perform any number of other tasks. Using cron, administrative functions are performed without any explicit action by the system administrator (or any other user).

For administrative purposes, cron is useful for running commands and scripts according to a preset schedule. cron can send the resulting output to a log file, as a mail or terminal message, or to a different host for centralized logging. The cron command starts the crond daemon, which has no options. It is normally started automatically by one of the system initialization scripts.

Table 3-3 lists the components of the cron facility on the various Unix systems we are considering. We will cover each of them in the course of thissection.

Table 3-3: Variations on the cron facility
Component	Location and information
crontab files	Usual: `/var/spool/cron/crontabs` FreeBSD: `/var/cron/tabs,` `/etc/crontab` Linux: `/var/spool/cron` (Red Hat), `/var/spool/cron/tabs`

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Most of the time, bringing up or shutting down a Unix system is actually very simple. Nevertheless, every system administrator needs to have at least a conceptual understanding of the startup and shutdown processes in order to, at a minimum, recognize situations where something is going awry—and potentially intervene. Providing you with this knowledge is the goal of this chapter. We will begin by examining generic boot and shutdown procedures that illustrate the concepts and features common to virtually every Unix system. This will be followed by sections devoted to the specifics of the various operating systems we are discussing, including a careful consideration of the myriad of system configuration files that perform and control these processes.

Bootstrapping is the full name for the process of bringing a computer system to life and making it ready for use. The name comes from the fact that a computer needs its operating system to be able to do anything, but it must also get the operating system started all on its own, without having any of the services normally provided by the operating system to do so. Hence, it must "pull itself up by its own bootstraps." Booting is short for bootstrapping, and this is the term I'll use.

The basic boot process is very similar for all Unix systems, although the mechanisms used to accomplish it vary quite a bit from system to system. These mechanisms depend on both the physical hardware and the operating system type (System V or BSD). The boot process can be initiated automatically or manually, and it can begin when the computer is powered on (a cold boot ) or as a result of a reboot command from a running system (a warm boot or restart).

The normal Unix boot process has these main phases:

Basic hardware detection (memory, disk, keyboard, mouse, and the like).
Executing the firmware system initialization program (happens automatically).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Bootstrapping is the full name for the process of bringing a computer system to life and making it ready for use. The name comes from the fact that a computer needs its operating system to be able to do anything, but it must also get the operating system started all on its own, without having any of the services normally provided by the operating system to do so. Hence, it must "pull itself up by its own bootstraps." Booting is short for bootstrapping, and this is the term I'll use.

The basic boot process is very similar for all Unix systems, although the mechanisms used to accomplish it vary quite a bit from system to system. These mechanisms depend on both the physical hardware and the operating system type (System V or BSD). The boot process can be initiated automatically or manually, and it can begin when the computer is powered on (a cold boot ) or as a result of a reboot command from a running system (a warm boot or restart).

The normal Unix boot process has these main phases:

Basic hardware detection (memory, disk, keyboard, mouse, and the like).
Executing the firmware system initialization program (happens automatically).
Locating and running the initial boot program (by the firmware boot program), usually from a predetermined location on disk. This program may perform additional hardware checks prior to loading the kernel.
Locating and starting the Unix kernel (by the first-stage boot program). The kernel image file to execute may be determined automatically or via input to the boot program.
The kernel initializes itself and then performs final, high-level hardware checks, loading device drivers and/or kernel modules as required.
The kernel starts the init process, which in turn starts system processes (daemons) and initializes all active subsystems. When everything is ready, the system begins accepting user logins.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This section discusses the Unix initialization files: command scripts that perform most of the work associated with taking the system to multiuser mode. Although similar activities take place under System V and BSD, the mechanisms by which they are initiated are quite different. Of the systems we are considering, FreeBSD follows the traditional BSD style, AIX is a hybrid of the two, and all the other versions use the System V scheme.

Understanding the initialization scripts on your system is a vital part of system administration. You should have a pretty good sense of where they are located and what they do. That way, you'll be able to recognize any problems at boot time right away, and you'll know what corrective action to take. Also, from time to time, you'll probably need to modify them to add new services (or to disable ones you've decided you don't need). We'll discuss customizing initialization scripts later in this chapter.

Although the names, directory locations, and actual shell program code for system initialization scripts varies widely between BSD-based versions of Unix and those derived from System V, the activities accomplished by each set of scripts as a whole differs in only minor ways. In high-level terms, the BSD boot process is controlled by a relatively small number of scripts in the /etc directory, with names beginning with rc, which are executed sequentially. In contrast, System V executes a large number of scripts (as high as 50 or more), organized in a three-tiered hierarchy.

Unix initialization scripts are written using the Bourne shell (/bin/sh). As a convenience, Bourne shell programming features are summarized in Appendix A.

Aspects of the boot process are also controlled by configuration files that modify the operations of the boot scripts. Such files consist of a series of variable definitions that are read in at the beginning of a boot script and whose values determine which commands in the script are executed. These variables can specify things like whether a subsystem is started at all, the command-line options to use when starting a daemon, and the like. Generally, these files are edited manually, but some systems provide graphical tools for this purpose. The dialog on the left in Figure 4-1 shows the utility provided by SuSE Linux 7 as part of its YaST2 administration tool.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

From time to time, you will need to shut thesystem down. This is necessary for scheduled maintenance, running diagnostics, hardware changes or additions, and other administrative tasks.

During a clean system shutdown, the following actions take place:

All users are notified that the system will be going down, preferably giving them some reasonable advance warning.
All running processes are sent a signal telling them to terminate, allowing them time to exit gracefully, provided the program has made provisions to do so.
All subsystems are shut down gracefully, via the commands they provide for doing so.
All remaining users are logged off, and remaining processes are killed.
Filesystem integrity is maintained by completing all pending disk updates.
Depending on the type of shutdown, the system moves to single-user mode, the processor is halted, or the system is rebooted.

After taking these steps, the administrator can turn the power off, execute diagnostics, or perform other maintenance activities as appropriate.

Unix provides the shutdown command to accomplish all of this. Generally, shutdown sends a series of timed messages to all users who are logged on, warning them that the system is going down; after sending the last of these messages, it logs all users off the system and places the system in single-user mode.

All Unix systems—even those running on PC hardware—should be shut down using the commands described in this section. This is necessary to ensure filesystem integrity and the clean termination of the various system services. If you care about what's on your disks, never just turn the power off.

There are two main variations of the shutdown command. The System V version is used by Solaris and HP-UX (the latter slightly modified from the standard), and the BSD version is used under AIX, FreeBSD, Linux, Solaris (in

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Even the best-maintained systems crash from time to time. A crash occurs when the system suddenly stops functioning. The extent of system failure can vary quite a bit, from a failure affecting every subsystem to one limited to a particular device or to the kernel itself. System hang-ups are a related phenomenon in which the system stops responding to input from any user or device or stops producing output, but the operating system nominally remains loaded. Such a system also may be described as frozen.

There are many causes of system crashes and hangups. These are among the most common:

Hardware failures: failing disk controllers, CPU boards, memory boards, power supplies, disk head crashes, and so on.
Unrecoverable hardware errors, such as double-bit memory errors. These sorts of problems may indicate hardware that is about to fail, but they also just happen from time to time.
Power failures or surges due to internal power supply problems, external power outages, electrical storms, and other causes.
Other environmental problems: roof leaks, air conditioning failure, etc.
I/O problems involving a fatal error condition rather than a device malfunction.
Software problems, ranging from fatal kernel errors caused by operating system bugs to (much less frequently) problems caused by users or third-party programs.
Resource overcommitment (for example, running out of swap space). These situations can interact with bugs in the operating system to cause a crash or hang-up.

Some of these causes are easier to identify than others. Rebooting the system may seem like the most pressing concern when the system crashes, but it's just as important to gather the available information about why the system crashed while the data is still accessible.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Since very few computers exist in isolation, managing networks is an inextricable part of system administration. In fact, in some circles, the designations "system administrator" and "network administrator" are more or less synonymous.

This chapter provides an overview of TCP/IP networking on Unix systems. It begins with a general discussion of TCP/IP concepts and procedures and then covers basic network configuration for client systems, including the variations and quirks of each of our reference operating systems. There are other discussions of network-related topics throughout the remainder of the book, including in-depth treatments of network security issues in Chapter 7 and coverage of administering and configuring network facilities and services in Chapter 8.

For a book-length discussion of TCP/IP networking, consult Craig Hunt's excellent book, TCP/IP Network Administration (O'Reilly & Associates).

The term "TCP/IP" is shorthand for a large collection of protocols and services that are used for internetworking computer systems. In any given implementation, TCP/IP encompasses operating system components, user and administrative commands and utilities, configuration files, and device drivers, as well as the kernel and library support upon which they all depend. Many of the basic TCP/IP networking concepts are not operating system-specific, so we'll begin this chapter by considering TCP/IP networking in a general way.

Figure 5-1 depicts an example TCP/IP network including several kinds of network connections. Assuming that these computers are in reasonably close physical proximity to one another, this network would be classed as a local area network (LAN). In contrast, a wide area network (WAN) consists of multiple LANs, often widely separated geographically (see Figure 5-5, later in this chapter). Different physical network types are also characteristic of the LAN/WAN distinction (e.g., Ethernet versus frame relay).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The term "TCP/IP" is shorthand for a large collection of protocols and services that are used for internetworking computer systems. In any given implementation, TCP/IP encompasses operating system components, user and administrative commands and utilities, configuration files, and device drivers, as well as the kernel and library support upon which they all depend. Many of the basic TCP/IP networking concepts are not operating system-specific, so we'll begin this chapter by considering TCP/IP networking in a general way.

Figure 5-1 depicts an example TCP/IP network including several kinds of network connections. Assuming that these computers are in reasonably close physical proximity to one another, this network would be classed as a local area network (LAN). In contrast, a wide area network (WAN) consists of multiple LANs, often widely separated geographically (see Figure 5-5, later in this chapter). Different physical network types are also characteristic of the LAN/WAN distinction (e.g., Ethernet versus frame relay).

Each computer system on the network is known as a host and is identified by both a name and an IP address (more on these later). Most of the hosts in this example have a permanent name and IP address. However, two of them, italy and chile, have their IP address dynamically assigned when they first connect to the network (typically, at boot time), using the DHCP facility (indicated by the highlighted final element in the IP address).

Figure 5-1: TCP/IP local area network

If I am logged in to, say, spain (either by direct connection or via a modem), spain is said to be the local system, and brazil is a remote system with respect to processes running on spain. A system that performs a task for a remote host is called a server; the host for whom the task is performed is called the client. Thus, if I request a file from

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

To add a new host to thenetwork, you must:

Install networking software and build a kernel capable of supporting networking and the installed networking hardware (if necessary). These days, basic networking is almost always installed by default with the operating system, but you may have to add some features manually.
Physically connect the system to the network and enable the hardware network interface. Occasionally, on older PC systems, the latter may involve setting jumpers or switches on the network adapter board or setting low-level system parameters (usually via the pre-boot monitor program).
Assign a hostname and network address to the system (or find out what has been assigned by the network administrator). When you add a new host to an existing network, the unique network address you assign it must fit in with whatever addressing scheme is already in use at your site. You can also decide to use DHCP to assign the IP address and other networking parameters dynamically instead of specifying a static address.
Ensure that necessary configuration tasks occur at boot time, including starting all required networking-related daemons.
Configure name resolution (hostname-to-IP address translation).
Set up any static routes and configure any other routing facilities in use. This includes defining a default gateway for packets destined beyond the local subnet.
Test the network connection.
Enable and configure any additional network services that you plan to use on that computer.

The ifconfig command ("if" for interface) is used to set the basic characteristics of the network adapter, the most important of which is associating an IP address with the interface. Here are some typical commands:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Once network configuration is complete, you will need to test network connectivity and address any problems that may arise. Here is an example testing scheme:

Verify that the network hardware is working by examining any status lights on the adapter and switch or hub.
Check basicnetwork connectivity using the ping command. Be sure to use IP addresses instead of hostnames so you are not dependent on DNS.
Test name resolution using ping with hostnames or nslookup (see Section 8.1).
Check routing by pinging hosts beyond the local subnet (but inside the firewall).
Test higher-level protocol connectivity by using telnet to a remote host. If this fails, be sure that inetd is running, that the telnet daemon is enabled, and that the remote host from which you are attempting to connect is allowed to do so (inetd is discussed in Chapter 8).
If appropriate, verify that other protocols are working. For example, use a browser to test the web server and/or proxy setup. If there are problems, verify that the browser itself is configured properly by attempting to view a local page.
Test any network servers that are present on the local system (see Chapter 8).

The first step is to test the network setup and connection with the ping command. ping is a simple utility that will tell you whether the connection is working and the basic setup is correct. It takes a remote hostname or IP address as its argument:

$ ping hamlet 

PING hamlet: 56 data bytes 

64 bytes from 192.0.9.3: icmp_seq=0. time=0. ms 

64 bytes from 192.0.9.3: icmp_seq=1. time=0. ms 

64 bytes from 192.0.9.3: icmp_seq=4. time=0. ms

... 

            ^C

----hamlet PING Statistics---- 

8 packets transmitted, 8 packets received, 0% packet loss 

round-trip (ms)  min/avg/max = 0/0/0

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

User accounts and authentication are two of the most important areas for which a system administrator is responsible. User accounts are the means by which users present themselves to the system, prove that they are who they claim to be, and are granted or denied access to the information and resources on a system. Accordingly, properly setting up and managing user accounts is one of the administrator's chief tasks.

In this chapter we consider Unix user accounts, groups, and user authentication (the means by which the system verifies a user's identity). We will begin by spending a fair amount of time looking at the process of adding a new user. Later sections of the chapter will consider passwords and other aspects of user authentication in detail.

From the system's point of view, auser isn't necessarily an individual person. Technically, to the operating system, a user is an entity that can execute programs or own files. For example, some user accounts exist only to execute the processes required by a specific subsystem or service (and own the files associated with it); such users are sometimes referred to as pseudo users . In most cases, however, a user means a particular individual who can log in, edit files, run programs, and otherwise make use of the system.

Each user has a username that identifies him. When adding a new user account to the system, the administrator assigns the username a user identification number (UID). Internally, the UID is the system's way of identifying a user. The username is just mapped to the UID. The administrator also assigns each new user to one or more groups : a named collection of users who generally share a similar function (for example, being members of the same department or working on the same project). Each group has a group identification number (GID) that is analogous to the UID: it is the system's internal way of defining and identifying a group. Everyuser is a member of one or more groups. Taken together, a user's UID and group memberships determine what access rights he has to files and other system resources.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

From the system's point of view, auser isn't necessarily an individual person. Technically, to the operating system, a user is an entity that can execute programs or own files. For example, some user accounts exist only to execute the processes required by a specific subsystem or service (and own the files associated with it); such users are sometimes referred to as pseudo users . In most cases, however, a user means a particular individual who can log in, edit files, run programs, and otherwise make use of the system.

Each user has a username that identifies him. When adding a new user account to the system, the administrator assigns the username a user identification number (UID). Internally, the UID is the system's way of identifying a user. The username is just mapped to the UID. The administrator also assigns each new user to one or more groups : a named collection of users who generally share a similar function (for example, being members of the same department or working on the same project). Each group has a group identification number (GID) that is analogous to the UID: it is the system's internal way of defining and identifying a group. Everyuser is a member of one or more groups. Taken together, a user's UID and group memberships determine what access rights he has to files and other system resources.

User account information is stored in several ASCII configuration files:

/etc/passwd: User accounts.
/etc/shadow: Encoded passwords and password settings. As we'll see, the name and location of this file varies.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In this section, we will consider the processes of adding, configuring, and removing user accounts on Unix systems.

Adding a new user to the system involves the following tasks:

Assign the user a username, a user ID number, and a primary group, and decide which other groups she should be a member of (if any). Enter this data into the system user account configuration files.
Assign a password to the new account.
Create a home directory for the user.
Place initialization files in the user's home directory.
Use chown and/or chgrp to give the new user ownership of his home directory and initialization files.
Set other user account parameters appropriate for your system (possibly including password aging, account expiration date, resource limits, and system privileges).
Add the user to any other facilities in use as appropriate (e.g., the disk quota system, mail system, and printing system).
Grant or deny access to additional system resources as appropriate, using file protections or the resources' own internal mechanisms (e.g., the /etc/ftpusersfile controls access to the ftp facility).
Perform any other site-specific initialization tasks.
Test the new account.

We will consider each of these steps in detail in this section. This discussion assumes that you'll be adding a user by hand. Few people actually do this anymore, but it is important to understand the whole process even if you use a tool that automates a lot of it for you. The available tools are discussed later in this chapter.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Shell scripts to automate the user account creation process have been common for a long time on Unix systems, and most Unix vendors/environments also provide graphical utilities for the same purpose. The latter tools allow you to make selections from pick lists and radio buttons and type information into blank fields to specify the various user account settings.

The advantage of these tools is that they take care of remembering a lot of the steps in the process for you. They usually add entries to all relevant account configuration files (including ones related to enhanced security, if appropriate), and they make sure that the entries are formatted correctly. They also typically create the user's home directory, copy initialization files to it, and set the correct ownerships and protection. Most of the tools are extremely easy to use, if somewhat tedious and occasionally time-consuming.

All of these tools also suffer from the same disadvantage: their abilities usually end after completing the activities I've already listed. A few of them perform one or two additional activities—adding the user to the mail system is among the most common—but that still leaves a lot to do. The best of these tools allow you to customize the activities that are performed, as well as the default values for available account settings; unfortunately, many of the currently available Unix user account management facilities lack any serious customization capabilities.

The best way to use any of these tools is first to set up defaults that reflect how things are done on your system, to the extent that the tool you've chosen allows you to do so. Doing so will minimize the time it takes to add a new user account to the configuration files. Then write a script that you can run by hand after the tool completes its work to automate the rest of the steps required to fully set up a new account.

In this section, we'll consider the most important and useful command-line utilities and graphical facilities for managing user accounts that are available on the Unix systems we are considering.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Because passwords play a central role in overall system security, all user accounts should have passwords. However, simply having a password is only the first step in making a user account secure. If the password is easy to figure out or guess, it will provide little real protection. In this section, we'll look at characteristics of good and bad passwords. The considerations discussed here apply both to choosing the root password (which the system administrator chooses) and to user passwords. In the latter case, your input usually takes the form of educating users about good and bad choices.

The purpose of passwords is to prevent unauthorized people from accessing user accounts and the system in general. The basic selection principle is this: Passwords should be easy to remember but hard to figure out, guess, or crack.

The first part of this principle argues against imposing automatically-generated random passwords (except when government or other mandated security policies require it). Many users have a very hard time remembering them, and in my experience, most users will keep a written record of their password for some period of time after they first receive it, even when this is explicitly prohibited.

If users are educated about easier ways to create good passwords, and you take advantage of features that Unix systems provide requiring passwords to be a reasonable length, users can select passwords that are just as good as system-generated ones. Allowing users to select their own passwords will make it much more likely that they will choose one that they can remember easily.

In practical terms, the second part of the principle means that passwords should be hard to guess even if someone is willing to go to a fair amount of effort—and there are plenty of people who are. This means that the following items should be avoided as passwords or even as components of passwords:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Traditionally, with very few exceptions, user authentication on Unix systems occurs at login time. In recent years, however, a new scheme has emerged that allows the authentication process to be performed and customized for a variety of system contexts. This functionality is provided by the PAM facility.

PAM stands for Pluggable Authentication Modules. PAM is a general user authentication facility available under and provided by current versions of FreeBSD, HP-UX, Linux, and Solaris. PAM's goal is to provide a flexible and administrator-configurable mechanism for authenticating users, independent of the various programs and facilities which require authentication services. In this way, programs can be developed independently of any specific user-authentication scheme instead of having one explicitly or implicitly embedded within them. When using this approach, utilities call various authentication modules at runtime to perform the actual user-validation process, and the utilities then act appropriately depending on the results the modules return to them.

There are several components to the PAM facility:

PAM-aware versions of traditional Unix authentication programs (for example, login and passwd). Such programs are referred to as services.
Modules to perform various specific authentication tasks. These are implemented as shared libraries (.so files), stored in /lib/security under Linux, /usr/lib/security under Solaris and HP-UX, and in /usr/lib under FreeBSD. Each module is responsible for just one small aspect of authentication. After executing, a module returns its result value to the PAM facility, indicating whether it will grant access or deny access to the user in question. A module may also return a neutral value, corresponding to no specific decision (essentially abstaining from the final decision).
Configuration data indicating what authentication process should be performed for each supported service, specified via one or more PAM configuration files. On Linux systems, each service has its own configuration file—with the same name as the service itself—in the directory

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

For several years now, every time anyone put together a list of hot system administration topics, LDAP was sure to be near the top. Many sites are beginning to use LDAP for storing employee information, including user account information, and as a means for performing enterprise-wide user authentication. In this way, LDAP-based account data and authentication can replace separate, per-system logins and network-based authentication schemes like NIS.

In this closing section of the chapter, we'll take a brief look at LDAP—and specifically, the OpenLDAP environment—and consider how it may be used for user authentication.

LDAP, as its fully expanded name—Lightweight Directory Access Protocol—indicates, is a protocol that supports a directory service. The best analogy for a directory service is the phone company's directory assistance. Directory assistance is a mechanism for customers to find information that they need quickly. Traditionally, human operators provided the (hopefully friendly) interface between the user (customer) and the database (the list of phone numbers). Directory assistance is not a means for customers to change their phone number, indicate whether their phone number should be listed or unlisted, or to obtain new telephone service.

A computer-based directory service provides similar functionality. It is a database and means of accessing information within it. Specifically, the directory service database has several specific characteristics that are different from, say, databases used for transaction processing:

It is optimized for reading (writing may be expensive).
It provides advanced searching features.
Its fundamental data structures—collectively known as the schema—can be extended according to local needs.
It adheres to published standards to ensure interoperability among vendor implementations (specifically, a boatload of RFCs).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

These days, the phrase "computer security" is most often associated with protecting against break-ins: attempts by an unauth orized person to gain access to a computer system (and the person will bear a strong resemblance to an actor in a movie like War Games or Hackers ). Such individuals do exist, and they may be motivated by maliciousness or mere mischievousness. However, while external threats are important, security encompasses much more than guarding against outsiders. For example, there are almost as many security issues relating to authorized users as to potential intruders.

This chapter will discuss fundamental Unix security issues and techniques, as well as important additional security features offered by some Unix versions. See Practical Internet and Unix Security by Simson Garfinkel and Gene Spafford (O'Reilly & Associates) for an excellent, book-length discussion of Unix security.

This chapter will undoubtedly strike some readers as excessivelyparanoid. The general approach I take to system security grows out of my experiences working with a large manufacturing firm designing its new products entirely on CAD-CAM workstations and experiences working with a variety of fairly small software companies. In all these environments, a significant part of the company's future products and assets existed solely online. Naturally, protecting them was a major focus of system administration and the choices that are appropriate for sites like these may be very different from what makes sense in other contexts. This chapter presents some options for securing a Unix system. It will be up to you and your site to determine what you need.

Security considerations permeate most system administration activities, and security procedures work best when they are integrated with other, normal system activities. Given this reality, discussions of security issues can't really be isolated to a single chapter. Rather, they pop up again and again throughout the book.

Before turning to the specifics of securing and monitoring Unix systems, let's take a brief look at three well-known historical Unix security problems (all of them were fixed years ago):

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Before turning to the specifics of securing and monitoring Unix systems, let's take a brief look at three well-known historical Unix security problems (all of them were fixed years ago):

The Sendmail package used to include a debug mode designed to allow a system administrator to type in raw commands by hand and observe the effects. Unfortunately, because anyone can run the sendmail program, and because it runs as setuid root, a nefarious user could use sendmail to execute commands as root. This is an example of a security hole created by a back door in a program: an execution mode that bypasses the program's usual security mechanisms.
Traditionally, the passwd -f command enabled users to change the information in the GECOS field of their password-file entries. However, as originally implemented, the command simply added the new information to the user's GECOS field without examining it first for characters such as, for example, colons and new lines. This oversight meant that a treacherous user could use the command to add an entry to the password file. This is an example of a program's failure to validate its input. The program simply assumes that the input it receives is valid and harmless without checking that it is in the form and length that is expected.

Another variation of this problem is called a buffer overflow . A buffer overflow occurs when a program receives more input than the maximum amount that it is able to handle. When it later chokes on that input, there can be unexpected side effects, including the ability to run arbitrary commands in the user context of the program (often root). Modern programs are usually written to reject input that is too large, but we are still finding and fixing such bugs in programs written in previous years/decades.
The finger command displays various information about the user you specify as its argument: his full name and other password-file information, as well as the contents of the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Security discussions often begin by considering the kinds ofthreats facing a system. I'd like to come at this issue from a slightly different angle by focusing first on what needs to be protected. Before you can address any security-related issue on your system, you need to be able to answer the following questions:

What are you trying to protect?
What valuable asset might be lost?

If you can answer these questions, you've gone a long way toward identifying and solving potential security problems. One way to approach them is to imagine discovering one morning that your entire computer system/network was stolen during the previous night. Having this happen would upset nearly everyone, but for many different reasons:

Because of the monetary cost: what is valuable is the computer as a physical object (loss of equipment).
Because of the loss of sensitive or private data, such as company secrets or information about individuals (one type of loss of data).
Because you can't conduct business: the computer is essential to manufacturing your product or providing services to your customers (loss of use). In this case, the computer's business or educational role is more important than the hardware per se.

Of course, in addition to outright theft, there are many other causes of all three kinds of losses. For example, data can also be stolen by copying it electronically or by removing the medium on which it is stored, as well as by stealing the computer itself. There is also both physical and electronicvandalism. Physical vandalism can mean broken or damaged equipment (as when thieves break into your office, get annoyed at not finding any money, and pour the cup of coffee left on a desk into the vents on the computer and onto the keyboard). Electronic vandalism can consist of corrupted or removed files or a system overwhelmed by so many garbage processes that it becomes unusable; this sort of attack is called a

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We've already looked at the issues surrounding password selection and aging in Section 6.4. In this section, we will consider optional user authentication methods and techniques that extend beyond standard password selection and aging. We will also consider another method of securing remote access—the secure shell—later in this chapter.

The purpose of all user authentication schemes, from passwords on, is to require a prospective user to prove that she really is the person she is claiming to be. The standard Unix login procedure and most secondary authentication programs validate a user's identity based on something she knows, like a password, assuming that no one else knows it.

There are other approaches to user authentication. A user can also be validated based on something she is, that is, some unique and invariant physical characteristic such a fingerprint or retina image. Biometric devices validate a person's identity in this way. They are commonly used to protect entrances to secure installations or areas, but they are seldom used just to authenticate users on a computer system.

A third approach is to validate the user based upon something she has. That something, known generically as a token, can be as simple as a photo ID badge. In the context of login authentication, smart cards are used most often. Smart cards are small, ranging in size from more or less credit card-size to about the same size as a small calculator. Some of them operate as a simple token that must be placed into a reader before computer access is granted.

Other smart cards look something like a calculator, with a keypad and a display in which a number appears. Users are required to enter a number from the display in addition to their normal password when they log in to a protected computer. This type of card generally requires the user to enter a personal identification number (PIN) before the card will operate (to provide some protection if the card is lost or stolen). Smart cards are also often designed to stop working if anyone tries take them apart or otherwise gain access to their protected memory.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In general, the goal of every security measure on a system is to prevent people from doing things they shouldn't. Given the all-or-nothing structure of Unix privileges, in practical terms this means you are trying to prevent unauthorized access to the root account—it also implies that the root account is what the bad guys are trying to gain access to. When they cannot do so directly because the root password has been well chosen, they may try other, indirect routes through the filesystem to gain superuser status.

So, how can you get root access from an ordinary, unprivileged user account? One way is to get root to execute commands like these:

# cp /bin/sh /tmp/.junk

# chmod 4755 /tmp/.junk

These commands create a setuid root version of the Bourne shell: any user can start a shell with this file, and every command that he runs within it will be executed as if he were root. Of course, no reputable system administrator will run these commands on demand, so a cracker will have to trick her into doing it anyway by hiding these commands—or other commands just as deadly—within something that she will execute. One large class of system attack revolves around substituting hacked, pernicious copies of normally benign system entities: Unix command executables, login or other initialization files, and so on. Making sure that the filesystem is protected will prevent many of them from succeeding.

In this section, we'll consider the types of vulnerabilities that come from poorly-chosen filesystem protections and general system disorganization. In the next section, we'll look at ways of finding potential problems and fixing them.

It is important to place the current directory and the bin subdirectory of the user's home directory at the end of the path list, after the standard locations for Unix commands:

$ echo $PATH 

/usr/ucb:/bin:/usr/bin:/usr/bin/X11:/usr/local/bin:$HOME/bin:.

This placement closes a potential security hole associated with search paths. If, for example, the current directory is searched before the standard command locations, it is possible for someone to sneak a file named, say,

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

So far, we have considered stronger user authentication and better file protection schemes. The topic we turn to next is a complement to both of these. Role-based access control (RBAC) is a technique for controlling the actions that are permitted to individual users, irrespective of the target of those actions and independent of the permissions on a specific target.

For example, suppose you want to delegate the single task of assigning and resetting user account passwords to user chavez. On traditional Unix systems, there are three approaches to granting priv ileges:

Tell chavez the root password. This will give her the ability to perform the task, but it will also allow here to do many other things as well. Adding her to a system group that can perform administrative functions usually has the same drawback.
Give chavez write access to the appropriate user account database file (perhaps via an ACL to extend this access only to her). Unfortunately, doing so will give her access to many other account attributes, which again is more than you want her to have.
Give her superuser access to just the passwd command via the sudo facility. Once again, however, this is more privilege than she needs: she'll now have the ability to also change the user's shell and GECOS information on many systems.

RBAC can be a means for allowing a user to perform an activity that must traditionally be handled by the superuser. The scheme is based on the concept of roles: a definable and bounded subset of administrative privileges that can be assigned to users. Roles allow a user to perform actions that the system security settings would not otherwise permit. In doing so, roles adhere to the principle of least privilege, granting only the exact access that is required to perform the task. As such, roles can be thought of as a way of partitioning the all powerful root privilege into discrete components.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We'll now turn our attention beyond the single system and consider security in a network context. As with all types of system security, TCP/IP network security inevitably involves tradeoffs between ease-of-use issues and protection against (usually external) threats. And, as is true all too often with Unix systems, in many cases your options are all or nothing.

Successful network-based attacks result from a variety of problems. These are the most common types:

Poorly designed services that perform insufficient authentication (or even none at all) or otherwise operate in an inherently insecure way (NFS and X11 are examples of facilities having such weaknesses that have been widely and frequently exploited).
Software bugs, usually in a network-based facility (for example, sendmail) and sometimes in the Unix kernel, but occasionally, bugs in local facilities can be exploited by crackers via the network.
Abuses of allowed facilities and mechanisms. For example, a user can create a .rhosts file in her home directory that will very efficiently and thoroughly compromise system security (these files are discussed later in this section).
Exploiting existing mechanisms of trust by generating forged network packets impersonating trusted systems (known as IP spoofing ).
User errors of many kinds, ranging from innocent mistakes to deliberately circumventing security mechanisms and policies.
Problems in the underlying protocol design, usually a failure to anticipate malicious uses. This sort of problem is often what allows a denial-of-service attack to succeed.

Attacks often use several vulnerabilities in combination.

Maintaining a secure system is an ongoing process, requiring a lot of initial effort and a significant amount of work on a permanent basis. One of the most important things you can do with respect to system and network security is to educate yourself about existing threats and what can be done to protect against them. I recommend the following classic papers as good places to start:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Throughout this chapter, I've been suggesting that systems ought to provide only the minimum amount of services and access that are needed. This is especially true for important server systems, especially—but not limited to—ones at site boundaries. The process of making a system more secure than the level the default installed operating system provides is known as hardening the system.

In this section, we'll look at the general principles of system hardening. Naturally, the actual process is very operating system-specific. Some vendors provide information and/or tools for automating some of the process. There are also some open source and commercial tools related to this topic. Here is a list of helpful websites related to system hardening that are available at this writing (July 2002):

AIX: http://biss.beckman.uiuc.edu/security/workshops/1999-10/
FreeBSD: http://www.trustedbsd.org

http://draenor.org/securebsd/
HP-UX: http://www.interex.org/conference/iworks2001/proceedings/5103/5103.pdf

http://www.bastille-linux.org (This tool works under HP-UX as well.)
Linux: http://www.linux-sec.net/Distro/distro.gwif.html

http://www.bastille-linux.org
Solaris: http://wwws.sun.com/software/security/blueprints/

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

So far, we've looked at lots of ways to prevent security problems. The remainder of this chapter will look at ways to detect and investigate security breaches. We'll consider all of the various monitoring activities that you might want to use as they would be performed manually and in isolation from one another. There are both vendor-supplied and free tools to simplify and automate the process, and you may very well choose to use one of them. However, knowing what to look for and how to find it will help you to evaluate these tools and use them more effectively. The most sophisticated system watchdog package is ultimately only as good as the person reading, interpreting, and acting on the information it produces.

The fundamental prerequisite for effective system monitoring is knowing what normal is, that is, knowing how things ought to be in terms of:

General system activity levels and how they change over the course of a day and a week.
Normal activities for all the various users on the system.
The structure, attributes, and contents of the filesystem itself, key system directories, and important files.
The proper formats and settings within important system configuration files.

Some of these things can be determined from the current system configuration (and possibly by comparing it to a newly installed system). Others are a matter of familiarity and experience and must be acquired over time.

It is important to examine the password file regularly for potential account-level security problems, as well as the shadow password file when applicable. In particular, it should be examined for:

Accounts without passwords.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Users have come to expect and rely on a variety of network services: logging in to a remote system, accessing files stored on a remote system, seeing information from various websites, and so on. High level network operations typically use a hostname to specify a network location, an easy and convenient practice for users. Accordingly, at the most basic level, network operations depend on two essential abilities: translating a hostname to an IP address and determining the route to a desired remote destination.

For this reason, configuring and managing services that handle name resolution and routing will take up a large part of this chapter. After considering these topics in detail, we will also consider other important network services, including DHCP, which is responsible for assigning IP addresses, and the service that synchronizes the current time on the various systems within a network. The final section of the chapter will consider software and techniques for monitoring network status over time.

inetd is another important network service. It controls many application-specific services (such as ftp and telnet). It is discussed in Section 7.6 in conjunction with the TCP Wrappers package, because its configuration has a large potential effect on system security.

The Domain Name System (DNS) is the facility that provides name resolution services. This service consists of two distinct activities: the actual hostname-to-IP address translation process and distribution mechanisms for the underlying translation data. Structurally, DNS is a distributed database whose contents are spread across the entire Internet, with individual DNS servers permanently storing only the subset of data for which they are responsible. Queries into this massively distributed database work because DNS has the ability to forward translation requests to the appropriate server automatically, in a manner that scales extremely well. The total amount of DNS data is also referred to as theDNS namespace

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Domain Name System (DNS) is the facility that provides name resolution services. This service consists of two distinct activities: the actual hostname-to-IP address translation process and distribution mechanisms for the underlying translation data. Structurally, DNS is a distributed database whose contents are spread across the entire Internet, with individual DNS servers permanently storing only the subset of data for which they are responsible. Queries into this massively distributed database work because DNS has the ability to forward translation requests to the appropriate server automatically, in a manner that scales extremely well. The total amount of DNS data is also referred to as theDNS namespace.

The DNS organizational structure defines thedomain name hierarchy familiar to most Internet users (see Figure 8-1). Domain names are arranged within a tree structure rooted at the root domain, which is designated by a single dot: ".". Underneath the root domain are a series of top-level domains (TLDs) whose names take one of two forms: generic suffixes loosely indicating organization type (gTLDs) or two-character country codes (ccTLDs). The currently defined generic TLDs are summarized in Table 8-1 (see http://www.icann.org/tlds/ for up-to-the-minute information).

Figure 8-1: The DNS namespace

Table 8-1: Generic TLDs
gTLD	Current use
.com	Commercial entity (used by companies worldwide)
.edu	Degree-granting U.S. higher education institutions (i.e., accredited colleges and universities)

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Having covered the first step in any network operation—finding out the address for the desired host—it is now time to turn to the second prerequisite: determining how to get there. The routing needs of many sites can be handled by installing routers and setting up default gateways and static routes on client systems (as we saw in Section 5.2). However, some situations call for more sophisticated routing services. This section provides an introduction to the daemons that provide them. The processes and algorithms described here are also used by dedicated routers.

Routing daemons dynamically select the best route from among the multiple paths to a given packet's destination. More precisely, what is determined is the best next step along the path toward the destination, because the ultimate target may be far beyond their field of vision.

Routers cache routing information that they learn in the course of their operation, and the routers and daemons within a network use various schemes to exchange routing information.

There are two routing daemons provided by Unix systems: routed and gated. routed (pronounced "route-D") is the older and simpler of the two and is infrequently used these days. gated (pronounced "gate-D") is a general purpose routing daemon, and it is the preferred choice for most sites.

For detailed information about the topics and daemons discussed in this section, see TCP-IP Network Administration by Craig Hunt (O'Reilly & Associates).

As we noted, many sites need only minimal routing (specifying a default gateway on every system) or static routing (defining some static routes as needed). These approaches work well for networks that are fairly simple (there are not many alternate paths to destinations), are relatively stable (routers do not go down very often), and have ample network bandwidth (routing efficiency is not a major factor in network traffic).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In Section 5.2, we considered the process of configuring a client system to obtain an IP address from a DHCP server. In this section, we complete the picture by discussing DHCP server configuration and management.

DHCP servers vary quite a bit from system to system, but the basic concepts that apply to all of them do not. We'll consider these concepts before diving into the specifics of server configuration on the various Unix systems.

DHCP servers draw the IP addresses that they provide from lists of addresses that they have been given to manage. These lists are known as scopes . Unix DHCP servers can manage one or more scopes. For example, suppose we have a network of two subnets, 10.10.1.0/24 and 10.10.20.0/24, and we place a DHCP server on each one. We want to use 101 IP addresses from each subnet for dynamic assignment, hosts 100 through 200. We might divide up the addresses this way:

Subnet 1 DHCP Server
10.10.1.100-10.10.1.175
10.10.20.176-10.10.20.200

Subnet 2 DHCP Server
10.10.20.100-10.10.20.175
10.10.1.176-10.10.1.200

Each server is assigned part of the address range for each subnet. When a client requests an IP address, the DHCP server always assigns one from the appropriate subnet (if none is available, the request fails). Splitting the addresses this way provides for some fault tolerance. If either server goes down, a DHCP relay (see below) can be set up temporarily on its subnet pointing to the other server, and IP address assignment will still take place.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Computers often don't work right when the hosts on a network have differing ideas about what time it is. For example, DNS servers become very upset when the master server's and slave servers' ideas of the current time are significantly different and will not accept zone transfers under such conditions. Also, many security protocols, such as Kerberos, have time-out values that depend on accurate clocks

The Network Time Protocol (NTP) was designed to remedy this situation by automating time synchronization across a network. The NTP home page is http://www.ntp.org. There is also a lot of useful information available at http://www.eecis.udel.edu/~mills/ntp.htm.

You may wonder how computer clocks get out of synchronization in the first place. Computers contain a oscillator along with some hardware to interface it to the CPU. However, instability in the oscillator (for example, due to temperature changes) and latencies in computer hardware and software cause errors in the system clock (known as wander and jitter , respectively). Thus, over time, the clock settings of different computers that were initially set to the same time will diverge since the errors introduced by their respective hardware will be different.

NTP is designed to deal with these realities in a very sophisticated manner. It has been around since 1980 and was designed and written by Professor David L. Mills of the University of Delaware and his students. This protocol provides time synchronization for all of the computers within a network and is constructed to be both fault tolerant and scalable to very large networks. It also includes features for authentication between clients and servers and for collecting and displaying statistics about its operations. The protocol has a target precision of about 232 picoseconds.

Here we look at time strictly from a standards point of view.

In 1967, a second was defined as "the duration of 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium-133 atom." (Cesium atoms keep busy.) Before 1967, the length of a second was tied to the Earth's rotation, and the exact length of a second would get longer each year. The time standard consisting of these 1967 standard seconds is known as TAI (International Atomic Time).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In general, AIX uses the System Resource Controller to manage daemons, and the ones related to networking are no exception. The startsrc and stopsrc commands are used to manually start and stop server processes within the SRC. The following commands illustrate the facility's use with several common TCP/IP daemons:

# stopsrc -g tcpip                     

            Stop all TCP/IP-related daemons.

# stopsrc -s named                     

            Stop the DNS  name server.

# startsrc -s inetd                    

            Start the master networking server.

# startsrc -g nfs                      

            Start all NFS-related daemons.

As these commands illustrate, the -s and -g options are used to specify the individual server or server group (respectively) to which the command applies. As usual, the lssrc command may be used to display the status of daemons controlled by the SRC, as in this command, which lists the servers within the nfs group:

# lssrc -g nfs

Subsystem        Group            PID       Status

biod             nfs              344156    active

rpc.statd        nfs              376926    active

rpc.lockd        nfs              385120    active

nfsd             nfs                        inoperative

rpc.mountd       nfs                        inoperative

On this system, the daemons related to accessing remote filesystems are running, while those related to providing remote access to local filesystems are not.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

For most of us, networking-related tasks make up a large fraction of our system administration duties. Installing and configuring a network can be a daunting task, especially if you're starting from scratch. However, monitoring and managing the network on an ongoing basis can be no less daunting, especially for very large networks. Fortunately, there are a variety of tools to help with this job, ranging from simple single-host network status utilities to complex network monitoring and management packages. In this section, we'll take a look at representative examples of each type, thereby enabling you to select the approach and software that is appropriate for your site.

We'll begin with the standard Unix commands designed for various network monitoring and troubleshooting tasks on the local system. Each command provides a specific type of network information and allows you to probe and monitor various aspects of network functionality. (We've already considered three such tools: ping and arp in Section 5.3 and nslookup in Section 8.1.5.2 earlier in this chapter).

The netstat command is the most general of these tools. It is used to monitor a system's TCP/IP network activity. It can provide some basic data about how much and what kind of network activity is currently going on, and also summary information for the recent past.

The specific output of the netstat command varies somewhat from system to system, although the basic information that it provides is the same. Moving from these generic examples to the format on your systems will be easy.

Without arguments, netstat lists all active network connections with the local host. In this output, it is often useful to filter out lines containing "localhost" to limit the display to interesting data:

# netstat | grep -v localhost 

Active Internet connections 

Proto Recv-Q Send-Q  Local Address  Foreign Address (state) 

tcp        0    737  hamlet.1018    duncan.shell    ESTABLISHED 

tcp        0      0  hamlet.1019    portia.shell    ESTABLISHED 

tcp      348      0  hamlet.1020    portia.login    ESTABLISHED 

tcp      120      0  hamlet.1021    laertes.login   ESTABLISHED 

tcp      484      0  hamlet.1022    lear.login      ESTABLISHED 

tcp     1018      0  hamlet.1023    duncan.login    ESTABLISHED 

tcp        0      0  hamlet.login   lear.1023       ESTABLISHED

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Making sure that electronic mail gets sent out and delivered is one of the system administrator's most important jobs, and it's also one that becomes extremely visible should things go wrong. Administering email is inevitably time-consuming and frustrating, at least intermittently. It also is comprised of a set of tasks that can seem rather daunting to the newcomer. However, don't let any initial feelings of confusion discourage or overwhelm you; in a surprisingly short time, you'll be in control and complaining with the best of them about the mail system's eccentricities and shortcomings.

As with regular postal mail, a properly functioning electronic-mail system depends on a series of distinct and often geographically-separated facilities and processes working together. Typically, each of these parts is handled by one or more programs specifically designed to perform the corresponding tasks.

In general, on Unix systems, the electronic mail facility is composed of the following components:

Programs that allow users to read and write mail messages: In the jargon, such programs are known as mail user agents . There are a variety of such programs available, ranging from the traditional (and primitive) mail command to character-based, menu-driven programs such as elm, mutt, pine, and the mh family, to Internet-integrated packages such as Netscape (some users also prefer the mail facilities embedded within their favorite editor, such as emacs). These programs require only a little administrative time and attention, usually consisting of setting system-wide defaults for the various packages.
Programs that accept outgoing email (submission agents), send it along its way, and begin the delivery process: Delivering mail to its final destination is the responsibility of mail transport agents

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As with regular postal mail, a properly functioning electronic-mail system depends on a series of distinct and often geographically-separated facilities and processes working together. Typically, each of these parts is handled by one or more programs specifically designed to perform the corresponding tasks.

In general, on Unix systems, the electronic mail facility is composed of the following components:

Programs that allow users to read and write mail messages: In the jargon, such programs are known as mail user agents . There are a variety of such programs available, ranging from the traditional (and primitive) mail command to character-based, menu-driven programs such as elm, mutt, pine, and the mh family, to Internet-integrated packages such as Netscape (some users also prefer the mail facilities embedded within their favorite editor, such as emacs). These programs require only a little administrative time and attention, usually consisting of setting system-wide defaults for the various packages.
Programs that accept outgoing email (submission agents), send it along its way, and begin the delivery process: Delivering mail to its final destination is the responsibility of mail transport agents , which relay mail messages within a site or out onto the Internet toward their final destinations. Transport agents run as daemons, and they generally use the directory /var/spool/mqueue as a work queue to hold messages waiting for processing.

sendmail is the traditional Unix transport agent. sendmail usually functions as the submission agent as well, although some mail programs (user agents) now incorporate this capability themselves. Current estimates indicate that sendmail handles about 75% of all email. Other available transport agents include Postfix,

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As we've noted, there are a variety of mailer programs available for use as user agents. Some of the most popular are listed in Table 9-1. Some of them—pine, the mh family, and Netscape—can also be configured to function as direct mail submission agents; the others rely on the transport agent for this task.

Table 9-1: Mail programs provided by Unix systems
	AIX	FreeBSD	HP-UX	Linux	Solaris	Tru64
System V `mail`
BSD `mail`

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

There are several administrative tasks associated with using message stores for some or all email recipients:

Selecting and designating a mail server for the message store. For large sites, this task expands to designing and deploying a scheme in which several servers divide this task.
Configuring daemons to run POP and/or IMAP on the mail servers.
Setting up user mail programs to access the message store instead of or in addition to the default local mailbox.

The first item is intimately related to the overall network architecture and capacity planning, and this issue is discussed in this context in Chapter 15.

The second item deals with providing server-side support for remote email clients wishing to access and retrieve messages. There are two main protocols used for this purpose: the Post Office Protocol Version 3 (POP3, or justPOP) and theInternet Message Access Protocol Version 4 (IMAP4, or just IMAP).

POP is the older of the protocols, and it is also simpler than IMAP . It was designed for "offline" mail processing; the user's mail program connects to the mail server and downloads any new mail messages to the local system (usually deleting them from the server after doing so). In this scheme, the remote server functions purely as a temporary remote storage site. Although POP clients can be configured to automatically poll the mail server periodically, POP remains a manual transfer method at heart.

IMAP implements an interactive client-server model of interaction between the mail server and the client software. Mail can be downloaded to the local system as with POP, but an IMAP client can also be used to access and manage a centrally located mailbox from any remote location. When an IMAP client accesses a remote mailbox, it can perform operations on the messages stored there without necessarily having to download any of them. By default, only mail headers are transferred to the client (to save bandwidth). The body of the message is downloaded only when a message is selected for viewing, and it is not deleted from the server. Messages can be marked with various status flags (e.g., read vs. unread), and this data is stored along with the message (and accordingly appears during subsequent IMAP sessions). An IMAP client can also access multiple mailboxes and mailboxes shared among a group of users.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Setting up the transport agent is perhaps the most crucial mail-related job presented to the system administrator. There are a variety of transport agents available on Unix systems, but sendmail is by far the most widely used. According to current estimates, sendmail handles over 75% of all Internet mail traffic (Unix and non-Unix alike). Other transport agents used on Unix systems include Postfix, smail, qmail, and exim. We will consider sendmail and Postfix here.

Eric Allman's sendmail package is a very powerful facility, capable of handling email from the moment a user submits a message from a mailer program, transporting it across a LAN or the Internet to the proper destination system, and then finally handing it off to the delivery agent, which actually places the message in the user's mailbox. In fact, because the package includes a delivery agent program, the facility as a whole can handle every aspect of electronic mail except composing and reading messages and retrieving them from message stores. sendmail is also a well-proven facility, and, at this point, is quite secure, provided that it is configured properly.

There are commercial and free versions of sendmail. The commercial versions, developed and sold by Sendmail, Inc., include additional features as well as easy-to-use graphical interfaces, integration with other related commercial products (e.g., virus-scanning software), and technical support. Vendor-supplied versions of sendmail are created from the free package.

sendmail is available from http://www.sendmail.org; see also http://www.sendmail.net, which is Sendmail, Inc.'s site for the free version. For information about commercial sendmail products, see http://www.sendmail.com.

The current sendmail version series is 8.12.3 (circa April, 2002). sendmail's major version number—8—refers to the extensive rewrite of sendmail done in 1993 by its author, Eric Allman. The other numbers are revisions within that series. Unfortunately, vendor-included versions of

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As we've already seen, sites that connect intermittently to the Internet can complicate mail relaying and delivery. The central issue for such sites is the method for forcing mail to be sent and retrieved periodically in some automated way. Basically, the local queue needs to be flushed (e.g., via sendmail -q or postfix flush) when the connection is made, and mail for local users needs to be retrieved. (Of course, these two processes can be handled by different servers and so need not happen at the same time). Sending local mail is easily handled by adding the appropriate command to the connection script (or creating a script that activates the connection, flushes the queue, and then terminates the connection).

Retrieving mail can be performed manually via the SMTP ETRN command on remote servers that allow SMTP connections and support the enhanced SMTP protocol. Here is an example:

# telnet kevin.ahania.com 25

Trying 10.0.19.223...

Connected to kevin.

Escape character is `^]'.

220 kevin.ahania.com ESMTP Sendmail 8.11.0/8.11.0; 

Mon, 16 Apr 2001 11:22:54 -0400

EHLO astarte

250 kevin.ahania.com Hello astarte

...

ETRN mailhost.zoas.org

The final command requests mail for the specified host.

The fetchmail program, written by Eric Raymond, provides automated mail retrieval capabilities. It is a powerful program that supports a variety of transport protocols and authentication mechanisms. It operates by retrieving messages from a remote mail server and sending them on to SMTP port 25 on the local system (or a specified remote system). As a result, to the transport agent, they look like normal incoming mail messages.

You will often need to ensure that localhost is included in the transport agent's list of allowed relay hosts for fetchmail to function properly.

The fetchmail command is the heart of the package. It is generally started at boot time via a command like this one:

fetchmail -d 900

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Previously, we've considered spam suppression features in both sendmail and Postfix. These features can be very effective at blocking some spam before it ever enters your site. The procmail program, written by Stephen van den Berg, offers a different method for accomplishing this task. The package's homepage is http://www.procmail.org.

In fact, procmail is a very powerful, general-purpose mail filtering facility. Its capabilities are not limited to removing spam; procmail can be used for several different purposes:

To identify spam messages, which can then be discarded or set aside for later examination.
To scan mail for security problems, such as viruses, macros within mail attachments, and so on, allowing you to discard or quarantine suspicious messages.
To sort incoming mail messages by sender, subject area, or any other scheme that makes sense to you.
To reject mail from specific users or sites or with specific characteristics or content (as defined locally); again, such mail can either be discarded or set aside as appropriate.

In fact, procmail is the mail filtering tool of choice for most users on Unix systems.

procmail can be applied to incoming mail in two main ways: by using it as the local delivery agent (the program to which the transport agent hands off local messages for actual delivery), or by piping incoming mail for individual users to it, usually in the .forward file, as in this canonical example:

"|IFS=' ' && exec /usr/bin/procmail -Yf- || exit 75 #username"

This example first sets the shell's interfield separator character to a space (see Chapter 3) and execs procmail, specifying -Y (assume BSD mailbox format) and -f- (which tells the program to update the timestamp in the leading From header). You may need to modify the path to one appropriate to your system. If you want to be extra cautious, you can use an entry like this one:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We'll end this chapter on electronic mail by looking at a few related tools and utilities.

You should be aware of the vacation program (included with the sendmail package). It is a utility for automatically sending a predefined reply to all arriving mail while a user is away from email access. To use it, the user creates a file named .vacation.msg in his home directory and creates a .forward file containing an entry like the following:

\username, "|/usr/bin/vacation username"

This sends each mail message to the user's usual mailbox and pipes it to the vacation program, giving the username as its argument. The slash is needed before the username to create a terminal mail destination and avoid an infinite loop.

Finally, the user activates the service with the following command:

$ vacation -I

To disable vacation, simply move or remove the .forward file.

Running the vacation command without any arguments triggers an automated setup process. First, a message file is created and started in a text editor (selected via the EDITOR environment variable). The program then automatically creates a .forward file and runs vacation -I. As a side effect, any existing .forward file is lost.

Next, you might find useful these commands that notify users that they have received new mail: biff , xbiff, and coolmail (a prettier xbiff written by Byron C. Darrah and Randall K. Sharpe; I found it on the Internet at http://www.redhat.com/swr/src/coolmail-1.3-9.src_dl.html, but it builds easily on other systems). The oldest of these, biff, requires the comsat network service, which is managed by inetd. These days, however, it is often disabled by default in /etc/inetd.conf because the graphical utilities have usually replaced biff. To enable the comsat service, uncomment the corresponding line in

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Managing Unix filesystems is one of the system administrator's most importanttasks. You are responsible for ensuring that users have access to the files they need and that these files remain uncorrupted and secure. Administering afilesystem includes tasks such as:

Making local and remote files available to users
Monitoring and managing the system's disk resources
Protecting against file corruption, hardware failures, and user errors via a well-planned backup schedule
Ensuring data confidentiality by limiting file and system access
Checking for and correcting filesystem corruption
Connecting and configuring new storage devices when needed

Some of these tasks—such as checking for and correcting filesystem corruption—are usually done automatically at boot time, as part of the initial system startup. Others—like monitoring disk space usage and backups—are often done manually, on a periodic or as-needed basis.

This chapter describes how Unix handles disks and filesystems. It covers such topics as mounting and dismounting local and remote filesystems, the filesystem configuration file, making local filesystems available to remote Unix and Windows users, checking local filesystem integrity with the fsck utility, and adding new disks to the system. It also looks at some optional filesystem features offered in some Unix implementations.

We looked at file ownership and protection in Section 2.1. This chapter considers filesystem protection for network shared filesystems. Other related topics considered elsewhere in this book include the discussions in Chapter 15 of managing disk space with disk quotas (Section 15.6), disk I/O performance (Section 15.5), and planning for swap space (Section 15.4), and the discussion of planning and performing backups in Chapter 11.

Before any disk partition can be used, a filesystem must be built on it. When a filesystem is made, certain data structures are written to disk that will be used to access and organize the physical disk space into files (see Section 10.3, later in this chapter).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Before any disk partition can be used, a filesystem must be built on it. When a filesystem is made, certain data structures are written to disk that will be used to access and organize the physical disk space into files (see Section 10.3, later in this chapter).

Table 10-1 lists the most important filesystem types available on the various systems we are considering.

Table 10-1: Important filesystem types
Use	AIX	FreeBSD	HP-UX	Linux	Solaris	Tru64
Default local	jfs or jfs2	ufs	vxfs	ext3, reiserfs	ufs	ufs or advfs
NFS	nfs	nfs	nfs	nfs	nfs	nfs
CD-ROM	cdrfs	cd9660	cdfs	iso9660

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This section covers such topics as mounting and dismounting local and remote filesystems, the filesystem configuration file, and checking local filesystem integrity with the fsck utility: in other words, the nitty gritty details of managing filesystems.

Mounting is the process that makes a filesystem's contents available to the system, merging it into the system directory tree. A filesystem can be mounted or dismounted: that is, it can be connected to or disconnected from the overall Unix filesystem. The only exception is the root filesystem, which is always mounted on the root directory while the system is up and cannot be dismounted.

Thus, in contrast to some other operating systems, mounting a Unix filesystem does more than merely make its data available. Figure 10-1 illustrates the relationship between a system's disk partitions (and their corresponding special files) and its overall filesystem. On this system, the root filesystem—the filesystem stored on the first partition of the root disk (disk 0)—contains the standard Unix subdirectories /bin, /etc, and so on. It also contains the empty directories /home, /var, and /chem, which serve as mount points for other filesystems. This filesystem is accessed via the special file /dev/dsk/c1d0s0.

Figure 10-1: Mounting disk partitions within the Unix filesystem

The figure also shows several other filesystems. One of them, accessed via the special file /dev/dsk/c1d0s8 (partition 8 of the root disk), contains the files and directories under /var. A third filesystem—partition 9 on disk 1—is accessed via the special file /dev/dsk/c1d1s9 and contains users' home directories, located under /home.

Another filesystem on this system is stored on partition 2 of disk 1 and is accessed via the special file /dev/dsk/c1d1s2. Its own root directory contains the subdirectories

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As we've seen, the basic Unix file storage unit is the disk partition. Filesystems are created on disk partitions, and all of the separate filesystems are combined into a single directory tree. The initial parts of this section discuss the process by which a physical disk becomes one or more filesystems on a Unix system, treating the topic at a conceptual level. Later subsections discuss the mechanics of adding a new disk to the various operating systems we are considering.

Traditionally, the Unix operating system organizes disks into fixed-size partitions, whose sizes and locations are determined when the disk is first prepared (as we'll see). Unix treats disk partitions as logically independent devices, each of which is accessed as if it were a physically separate disk. For example, one physical disk may be divided into four partitions, each of which holds a separate filesystem. Alternatively, a physical disk may be configured to contain only one partition comprising its entire capacity.

Many Unix implementations allow several physical disks to be combined into a single logical device or partition upon which you can build a filesystem. Systems offering a logical volume manager carry this trend to its logical conclusion, allowing multiple physical disks to be combined into a single logical disk, which can then be divided into logical partitions. AIX uses only an LVM and does not use traditional partitions at all.

Physically, adisk consists of a vertical stack of equally spaced circular platters. Reading and writing is done by a stack of heads that move in and out along the radius as the platters spin around at high speed. The basic idea is not so different from an audio turntable—I hope you've seen one—although both sides of the platters can be accessed at once.

Partitions consist of subcylinders of the disk: specific ranges of distance from the spindle (the vertical center of the stack ofplatters): e.g., from one inch to two inches, to make up an arbitrary example. Thus, a disk partition uses the same sized and located circular section on all the platters in the disk drive. In this way, disks are divided vertically, through the platters, not horizontally.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In the final section of this chapter, we consider sharing local filesystems with other systems, including Windows systems. It covers the most common Unix filesystem sharing facility, NFS, and the Samba facility, which makes Unix filesystems available to Windows systems.

More information about NFS is available in NFS and NIS by Hal Stern, Mike Eisler and Ricardo Labiaga (O'Reilly & Associates). More information about Samba is available in the books Teach Yourself Samba in 24 Hours by Gerald Carter with Richard Sharpe (SAMS) and Using Samba by Robert Eckstein, David Collier-Brown, and Peter Kelly (O'Reilly & Associates).

The Network File System (NFS) enables filesystems physically residing on one computer system to be used by other computers in the network, appearing to users on the remote host as just another local disk. NFS is universally available on Unix systems.

The following configuration files are used by NFS:

/etc/fstab ( /etc/vfstab under Solaris): Remote filesystems are entered into the filesystem configuration file, using only a slightly varied syntax from regular entries.
/etc/exports: This file controls which filesystems on the local system can be mounted by remote hosts and under what conditions and restrictions. On Solaris systems, this file is not used, but the file /etc/dfs/dfstab performs an analogous function.

Table 10-10 lists the daemons used by NFS and the files that start them in the various Unix versions.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Every user of any computer figures out sooner or later that files are occasionally lost. These losses have many causes: users may delete their own files accidentally, a bug can cause a program to corrupt its data file, a hardware failure may ruin an entire disk, and so on. The damage resulting from these losses can range from minor to expansive and can be very time-consuming to fix. To ensure against loss, one primary responsibility of a system administrator is planning and implementing a backup system that periodically copies all files on the system to some other location. It is also the administrator's responsibility to see that backups are performed in a timely manner and that backup tapes (and other media) are stored safely and securely. This chapter will begin by discussing backup strategies and options and then turn to the tools that Unix systems provide for making them.

An excellent reference work about backups on Unix systems is Unix Backup and Recovery by W. Curtis Preston (O'Reilly & Associates). It covers the topics we are discussing here in complete detail and also covers material beyond the scope of this book (e.g., backing up and restoring databases).

Developing an effective backup strategy is an ongoing process. You usually inherit something when you take over an existing system and start out doing the same thing you've always done when you get a new system. This may work for a while, but I've seen companies try to retain their centralized, hordes-of-operators-based backup policies after they switched from a computer room full of mainframes to a building full of workstations. Such an attempt is ultimately as comical as it is heroic, but it all too often ends up only in despair, with no viable policy ever replacing the outdated one. The time to develop a good backup strategy is right now, starting from however you are approaching things at the moment.

Basically, backups are insurance. They represent time expended in an effort to prevent future losses. The time required for any backup strategy must be weighed against the decrease in productivity, schedule slippage, and so on if the files are needed but are not available. The overall requirement of any backup plan is that it be able to restore the entire system—or group of systems—within an acceptable amount of time in the event of a large-scale failure. At the same time, a backup plan should not sacrifice too much in the way of convenience, either in what it takes to get the backup done or how easy it is to restore one or two files when a user deletes them accidentally. The approaches one might take when considering only disaster recovery or only day-to-day convenience in isolation are often very different, and the final backup plan will need to take both of them into account (and will accordingly reflect the tension between them).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Developing an effective backup strategy is an ongoing process. You usually inherit something when you take over an existing system and start out doing the same thing you've always done when you get a new system. This may work for a while, but I've seen companies try to retain their centralized, hordes-of-operators-based backup policies after they switched from a computer room full of mainframes to a building full of workstations. Such an attempt is ultimately as comical as it is heroic, but it all too often ends up only in despair, with no viable policy ever replacing the outdated one. The time to develop a good backup strategy is right now, starting from however you are approaching things at the moment.

Basically, backups are insurance. They represent time expended in an effort to prevent future losses. The time required for any backup strategy must be weighed against the decrease in productivity, schedule slippage, and so on if the files are needed but are not available. The overall requirement of any backup plan is that it be able to restore the entire system—or group of systems—within an acceptable amount of time in the event of a large-scale failure. At the same time, a backup plan should not sacrifice too much in the way of convenience, either in what it takes to get the backup done or how easy it is to restore one or two files when a user deletes them accidentally. The approaches one might take when considering only disaster recovery or only day-to-day convenience in isolation are often very different, and the final backup plan will need to take both of them into account (and will accordingly reflect the tension between them).

There are many factors to consider in developing a backup plan. The following questions are among the most important:

What files need to be backed up?

The simplest answer is, of course, everything, and while everything but scratch files and directories needs to be saved somewhere, it doesn't all have to be saved as part of the system backups. For example, when the operating system has been delivered on CD-ROM, there is really no need to back up the system files, although you may choose do so anyway for reasons of convenience.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

When I first started working as a system administrator, 9-track tape was the only medium you'd consider using for a backup. That's certainly no longer true. Today, there are many different media suitable for storing backed-up data. This section provides a quick summary of the available choices. This list includes most of the drives and media types which are in common use. The backup strategy for any particular system will often involve more than one media type.

Up-to-the-minute information about available backup devices and media may be obtained from http://www.storagemountain.com. There is also an excellent discussion in Unix Backup and Recovery.

Magnetic tape of one sort or another has been the traditional backup medium for decades. Over the years, it has taken on a variety of sizes and forms, beginning with 7-track and then 9-track tape: 1/2-inch wide tape wound around a circular reel. The introduction of plastic cartridges containing the tape and both reels was a major step forward in terms of reducing the space requirements of backup media. The first tape of this type was 1/4-inch cartridge tape (also known as QIC tape), which for a while was the medium of choice for most workstations; these tapes are still occasionally used.

Around 20 years ago, higher-capacity tapes in formats originally developed for other markets became available. 8 mm tape drives became popular in the late 1980s and are still in wide use. Originally designed for video uses, the tapes are about the size of an audio cassette. 4 mm digital audio tapes (commonly called DAT tapes although the data storage scheme is technically known as DDS) are also in wide use. DAT cartridges are about 25% smaller than 8 mm tapes.

8 mm and 4 mm tapes come in two grades, one designed for video and audio recording (respectively), and a better, more expensive grade designed for data. Be sure to purchase only data-quality tapes. Although lower-quality tapes will sometimes appear to work fine, in my experience they are much, much less reliable about retaining data (despite urban legends to the contrary).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Most systems offer a variety of utilities for performing backups, ranging from general-purpose archiving programs like tar and cpio to programs designed for implementing multilevel incremental backup schemes on a per-filesystem basis. When the largest tapes held only a couple hundred megabytes, choosing the right utility for system backups was easy. tar and cpio were used for small and ad hoc backups and other data transfer needs, and the more sophisticated utilities specifically designed for the task were used for system backups, because their specialized abilities—the ability to span tapes and to automatically perform incremental backups—were essential to getting the job done.

This distinction breaks down to a great extent when a single tape can hold gigabytes of data. For example, incrementals are less important when you can fit all the important data on a system onto one or two tapes—and you have the time to do so. Large tapes also make it practical to back up a system in logically grouped chunks of files, which may be spread arbitrarily throughout the physical filesystem. A successful system backup process can be built around whatever utilities make sense for your system.

One dubious piece of advice about backups that is frequently given is that you should limit filesystem size to the maximum backup media capacity available on the system. In this view, multi-tape backup sets are simply too much trouble, and the backup process is simplified if all of the data from a filesystem will fit onto a single tape.

While being able to back up a filesystem with a single tape is certainly convenient, I think it is a mistake to let current media capacity dictate filesystem planning to such a degree. Breaking disks into more, smaller filesystems limits flexibility in allocating their resources, a concern that is almost always far more important than reducing the complexity of backing them up. Designing the filesystem needs to take all of the factors affecting the system and its efficient use into account. If tape-sized backup sets are what is desired, it's easy enough to write scripts to do so when overall circumstances dictate that some individual filesystems need to be bigger.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

All of the backup facilities described in the previous sections have corresponding file restoration facilities. We'll look at each of them in turn in this section.

Individual files or entire subtrees can be restored easily from tar and cpio archives. For example, the following pairs of commands restore the file /home/chavez/freeway/quake95.data and user harvey's home directory (respectively) from an archive made of /home located on the tape in the default tape drive (here, we use /dev/rmt0 for as the example location):

$ tar -xp /home/chavez/freeway/quake95.data

$ cpio -im '*quake95.data' < /dev/rmt0

$ tar -xp /home/harvey

$ cpio -imd '/home/harvey*' < /dev/rmt0

The -p option to tar and -m option to cpio ensure that all file attributes are restored along with the file. cpio's -d option creates subdirectories as necessary when restoring a directory subtree (tar does so by default).

Restores with pax are similar. For example, the first of the following commands lists the files on the tape in drive 0, and the remaining commands extract various files from it:

$ pax -f /dev/rmt0 -v               

               -v

                

               gives a more detailed/verbose listing. 

$ pax -r '/h95/*.exe'               

               Select files via a regular expression. 

$ pax -r /home/chavez               

               Restore chavez's home directory. 

$ pax -r -f my_archive -c '*.o'     

               Restore everything except object files.

# pax -r -pe -f /dev/rmt0           

               Restore files incl. owner, mode & mod. time.

pax's coolest feature has to be its -s option, which allows you to massage filenames as files are written to, extracted from, or even just listed from an archive. It takes a substitution command as used in ed or sed as its argument (which will usually need to be enclosed in single quotation marks) indicating how filenames should be transformed. For example, the following command changes the second-level directory name of each file from

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

It is often convenient to have online listings of the contents of system backup tapes. For one thing, they make it much easier to figure out which tape has the file you need to restore, especially when multiple levels of incremental backups are in use. It is quite easy to create such files at the time the backup is performed.

If you're using tar or cpio for backup, you can take advantage of the -v option to create a listing of the tape's contents as it is written, as in these examples:

$ today='date +%d%b%Y' 

$ tar -cv /home > /backup/home_full_$today.TOC 

                                                     or

$ tar -cv /home | tee /backup/home_full_$today.TOC

Both tar commands archive the contents of /home, generating a long, directory-like listing as it does so and saving it to a file with a name like /backup/home_full_21mar1995.TOC. The second command also displays the same output on the screen.

cpio sends the file list to standard error, so it must be captured slightly differently:

$ toc='date +/backup/home_full_%d%b%y.TOC' 

$ find /home -print |  cpio -ov > /dev/rmt0 2> $toc

If you want to use the C shell, the commands are a little different:

% set toc='date +/backup/home_full_%d%b%y.TOC' 

% (find /home -print | cpio -ov > /dev/rmt0) >& $toc

The file lists produced by cpio commands like these contain only the pathnames of the files in the archive. If you want a more detailed listing, you can generate it with a second cpio command or a more complex pipe leading up to the cpio backup command:

$ cpio -itv < /dev/rmt0 > $toc 

$ find /home | cpio -o | tee /dev/rmt0 | cpio -t -i -v > $toc

The first command lists the files in the archive on tape. The second command avoids having to reread the backup tape by using the find command to generate a list of files, which cpio makes into an archive. This archive is then sent both the the tape drive and to another cpio command. The latter lists the archive contents and writes it to the specified table-of-contents file.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

So far, we've considered only backups and restores of disks on a local computer system. However, many organizations need to take a more unified and comprehensive approach to their total backup needs. We will consider various available solutions for this problem in this section.

The simplest way to move beyond the single-system backup view is to consider remote backup and restores. It is very common to want to perform a backup over the network. The reasons are varied: your system may not have a tape drive at all since not all systems come with one by default any more, there may be a better (faster, higher capacity) tape drive on another system, and so on.

Most versions of dump and restore can perform network-based operations (Tru64 requires you to use the separate rdump and rrestore commands). This is accomplished by specifying a device name of the form host:local_device as an argument to the -f option. The hostname may also optionally be preceded by a username and at-sign; for example,

-f

chavez@hamlet:/dev/rmt1

performs the operation on device /dev/rmt1 on host hamlet as user chavez.

This capability uses the same network services as the rsh and rcp commands. Remote backup facilities depend on the daemon /usr/sbin/rmt (which is often linked to /etc/rmt). To be allowed access on the remote system, there needs to be a .rhosts in its root directory, containing at least the name of the (local) host from which the data will come. This file must be owned by root, and its mode must not allow any access by group or other users (for example, 400). This mechanism has the mechanism's usual negative security implications (see Section 7.6).

Some versions of the tar command can also use the rmt remote tape facility.

The HP-UX fbackup and frestore utilities accept remote tape drives as arguments to the normal -f option. For example:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This final section covers backing up and restoring the filesystem containing the operating system itself, including the case of a system disk failure. Recovering from such a disaster has come to be known as "bare metal recovery" in recent years. Unix Backup and Restoreincludes detailed chapters describing these techniques and procedures for several Unix varieties.

Filesystems containing operating system files such as / and /usr pose few problems when all you need to restore is the occasional accidentally deleted or otherwise lost file. When the file in question is an unmodified system file, you can usually restore it from the operating system installation media, provided you have it and that it is readable under normal system conditions. If either of these conditions is not true, you should do a full backup of all system filesystems from time to time.

Files that you modify in the system partitions should be backed up regularly. In Chapter 14, we looked at a script that saves all modified configuration and other files to a user filesystem, allowing them to be backed up regularly and automatically via the system backup procedures. Alternatively, the script could save them directly to the backup media (even to a diskette if the archive is small enough).

When system filesystems need to be completely restored (usually due to hardware problems), some special considerations come into play. There are often two distinct approaches that can be taken:

Reinstalling from the original operating system installation tapes or CDs and then restoring files you have modified. This approach may also involve reconfiguring some subsystems.
Booting from alternate media and then restoring the filesystems from full backups that you have made.

Which alternative is preferable depends a lot on the characteristics of your particular system: how many files have been customized and how widely they are spread across the various system filesystems, how much device and other reconfiguration needs to be redone, and similar considerations. If you have to restore multiple partitions, it is usually faster to reinstall the operating system from scratch unless unsaved data in another partition on the same disk will be lost using the standard installation procedures.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This chapter discusses how to work with serial lines on Unix systems. Traditionally, this meant configuring terminals and modems, but now the topic's scope has grown to include related facilities as well, such as fax services and USB.

This chapter begins by considering traditional serial lines. First, we'll look at the special files used for serial lines and other terminal sessions. Next, we will discuss how to set the characteristics of individual terminals and generic terminal types. We then go on to consider terminal line configuration issues, including how to add and troubleshoot new terminals and modems. We'll conclude with a brief look at the HylaFAX fax service package and USB devices.

Celeste Stokely's website, at http://www.stokely.com/unix.serial.port.resources, is an invaluable guide to all aspects of using serial ports on Unix systems.

Serial lines were first used for connecting terminals to computers. As time went on, however, many other devices have been connected via serial lines as well: modems, printers, digital cameras, and MP3 players, to name just a few. While serial lines are not fast communications channels, they do provide a straightforward, standardized way of sending data to or from a computer. In traditional contexts, serial lines use the RS-232 communications standard. We will consider this standard in some detail later in this chapter, after we've discussed some more practical aspects of administering serial lines and devices.

The special files for serial ports vary between systems, but they traditionally have names of the form /dev/ttyn, where n is a one- or two-digit number corresponding to the serial line number (System V and BSD style, respectively); numbering begins at 0 or 00. For example, /dev/tty2 and /dev/tty16 correspond to the third and seventeenth serial lines on a system, respectively (BSD-style systems always use two digits: /dev/tty02). Terminals, modems, and other serial devices are accessed via these special files.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Serial lines were first used for connecting terminals to computers. As time went on, however, many other devices have been connected via serial lines as well: modems, printers, digital cameras, and MP3 players, to name just a few. While serial lines are not fast communications channels, they do provide a straightforward, standardized way of sending data to or from a computer. In traditional contexts, serial lines use the RS-232 communications standard. We will consider this standard in some detail later in this chapter, after we've discussed some more practical aspects of administering serial lines and devices.

The special files for serial ports vary between systems, but they traditionally have names of the form /dev/ttyn, where n is a one- or two-digit number corresponding to the serial line number (System V and BSD style, respectively); numbering begins at 0 or 00. For example, /dev/tty2 and /dev/tty16 correspond to the third and seventeenth serial lines on a system, respectively (BSD-style systems always use two digits: /dev/tty02). Terminals, modems, and other serial devices are accessed via these special files.

On more recent System V-based systems, special files for direct terminal lines are stored in the directory /dev/term and have names that are their line number: /dev/term/14, for example. There are often links to the older names.

The file /dev/tty (no suffix) serves a special purpose. It is a synonym for each process's controlling TTY. It can be used to ensure output goes to the terminal, regardless of any I/O redirection.

The special file /dev/console always refers to the system console device. On many workstation systems, /dev/console is redefined depending on how the workstation is being used. /dev/console refers to the system CRT display when the system is being used in a nongraphical mode. When a windowing session is running, however, /dev/console may become one of its windows (rather than the device as a whole).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Unix programs are generally written to beterminal-independent: they don't know about or rely on the specific characteristics of any particular kind ofterminal, but rather, they call a standard screen manipulation library that is responsible for interfacing to actual terminals. Such libraries serve to map general terminal characteristics and functions (e.g., clearing the screen) to the specific character sequences required to perform them on any specific terminal.

Terminal definitions are stored in databases on the system, and users indicate what kind of terminal they are using by setting the TERM environment variable (usually at login time). These databases are handled differently under BSD and System V and are the subject of the next section.

Programs use the name specified in the TERM environment variable as a key into the system terminal definitions database. Under the BSD scheme, terminal definitions are stored in the file /etc/termcap ; under System V, they are stored in the subdirectories of the terminfo top-level subdirectory. Some systems provide both facilities:

AIX	`/usr/lib/terminfo`
FreeBSD	`/etc/termcap` (a link to `/usr/share/misc/termcap`)
Linux

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

To add a new serial device to the system, you must perform the following steps:

Physically connect the terminal or modem to the computer.
Determine the special file in /dev that communicates with the serial line.
In the case of terminals, make sure a termcap or terminfo entry exists for the kind of terminal you are adding. If none exists, you will have to create one.
Add or modify an entry in the relevant configuration files (which files to use depends on the desired use: login, dial-up, dial-out, and so on).
If appropriate, force init to reread the terminal configuration information.

Each of these steps will be considered in turn.

This section discusses issues related to making the physical connection between a terminal or modem and the computer. It is condensed from the Nutshell Handbook Managing uucp and Usenet, by Grace Todino and Tim O'Reilly (O'Reilly & Associates), with some additions and slight alterations.

The serial cables used to connect computers or terminals to modems are commonly called RS-232 cables; technically, they conform—more or less—to the Electronic Industries Association (EIA) RS-232C or the more recent RS-232D standard. By extension (really by bending, if not breaking, the standard), RS-232 cables have come to be used to connect computers to all kinds of serial devices—terminals, printers, and ports on other computers, as well as modems.

Full RS-232 cables consist of up to 25 wires, each with a specific function and each intended to carry a different signal. Only two of the wires are commonly used for data transmission; the rest are used for various kinds of control signals. In fact, many of the signals defined by theRS-232 standard are rarely used. Table 12-3 lists the RS-232 signals typically used for serial devices. Accordingly, current devices virtually always use only a subset of the 25 pins, and smaller connectors containing only the relevant pins are much more common than ones with the full set.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Messed-up terminals are an occasional problem that system administrators have to deal with. When a terminal is hung (when it won't respond to any input) or seems to have gone crazy, here are some things to try that address the most common causes:

If the user knows what she did last, try to undo it. For example, if she was experimenting with stty options, try a stty sane command.
If the terminal doesn't respond at all, the user might have accidentally hit Ctrl-S, the pause key, the hold screen key, or something else that temporarily stops output. Try entering Ctrl-Q and then these other keys to see if things get going again.
Check the terminal settings via its setup menu. In particular, is its baud rate set correctly?
Try entering the reset command. If it doesn't work, try preceding and following it with a line feed (Ctrl-J if the terminal has no line feed key):
```
                  ^Jreset^J

               
```
Substituting stty sane in place of reset can also work. Running either command twice in succession is frequently necessary.
If the user has turned the power off and back on, check other settings like the emulation mode. If the user hasn't cycled power, try this yourself; there are some conditions that only cycling the power will clear. Leave the terminal off for about 10 seconds to allow the internal capacitors to discharge completely.
Next, go to another terminal and try to kill the program that was running on the hung terminal. It may be that the program—and not the terminal—is hung. Try a variety of signals in an attempt to neutralize the process—TERM (kill's default), KILL, INT, QUIT, STOP—use kill -l to list the available signals or consult /usr/include/sys/signal. h.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Most Unix versions provide some mechanism for limiting direct root logins to certain terminal lines. Note that these mechanisms have no effect on the ability of a user to gain root access via the su command. We'll consider the ones offered by each operating system in turn.

As we've seen earlier in this chapter, FreeBSD allows you to state explicitly whether direct root logins may take place on a line-by-line basis via the secure keyword in /etc/ttys . For example, these entries allow root logins on the terminal connected to the first serial line, but not on the terminal connected to the second serial line:

# name  getty                           type    flags 

ttyd0   "/usr/libexec/getty std.9600"   vt100   on secure   

ttyd1   "/usr/libexec/getty std.9600"   vt100   on

FreeBSD also provides general user class-based terminal restrictions via the ttys.allow and ttys.denyattributes in /etc/login.conf. See Section 6.2 for details.

Under Solaris, if the file /etc/default/login contains a CONSOLE entry, direct root logins are limited to that device. For example, this entry limits root logins to the system console:

CONSOLE=/dev/console

On HP-UX systems, the file /etc/securetty lists devices where root is allowed to log in. Here are some sample entries:

console 

tty00 

tty01

Note that /dev/ is not included in the line designation. The HP-UX file restricts access to the listed terminal lines to privileged users, rather than applying only to root.

Tru64 uses the file /etc/securettys in a similar manner:

/dev/console     # console 

:0               # X display

local:0

Note that the full special filename is included in the Digital Unix file. The second and third entries are also typically found in these files and refer to X-based sessions.

Linux systems can restrict terminal access via the PAM facility. The pam_securetty module provides support for a HP-UX style

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Under HP-UX and Tru64, the enhanced security facility provides a mechanism for specifying several security-related terminal line attributes. Default values applying to all terminals without explicitly set overrides are found in the t_ fields of the default file, stored in /etc/auth/system under Tru64 and /tcb/files/auth/system under HP-UX.

Here is an example from a Tru64 system:

default:\

       :d_name=default:\

        ...

       :t_logdelay#2:t_maxtries#10:t_unlock#0:\

       :t_login_timeout#15:chkent:

These are the settable terminal line attribute fields, which may be used in the default file and in the ttys file; the latter contains entries for each terminal line on the system and is located in /etc/auth/system under Tru64 (in binary form, as ttys.db) and in /tcb/files/auth/systemunder HP-UX:

t_maxtries: Terminal will be automatically locked after t_maxtries+1 consecutive login failures.
t_logdelay: Indicates the number of seconds to wait after an unsuccessful login attempt before giving the next prompt.
t_lock: Indicates that the terminal line is locked (t_lock@ means unlocked).
t_login_timeout: Number of seconds after which to abort an incomplete login.
t_unlock: Number of seconds after which to unlock a terminal locked due to too many unsuccessful login attempts (Tru64 only). A value of 0 means that the terminal line must be explicitly unlocked by the system administrator.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Many current Unix operating systems provide some sort of fax support. In this section, we'll consider the free HylaFAX package, originally written by Sam Leffler while at Silicon Graphics, because it is the most widely used and is available for many different Unix versions. HylaFAX is capable of sending and receiving faxes on the local system, and accepting fax jobs from other hosts on the network. Outgoing faxes are queued as necessary. An interface to electronic mail is also available. The package's home page is http://www.hylafax.org.

Fax services are provided by three daemons:

faxq: The queuing agent, which prepares fax files, and schedules and initiates outgoing fax transmissions.
hfaxd: The fax server daemon, which provides local and remote fax submission support, access control and other management functions.
faxgetty: A getty implementation which handles incoming faxes.

The package also includes a variety of utilities, many of which we'll consider here; the corresponding binary files are mainly stored in /usr/local/bin and /usr/local/sbin, although a few are in /var/spool/hylafax/bin (if you use the default installation directories).

Actual fax images are stored in the subdirectories docq (outgoing) and recvq (incoming) under /var/spool/hylafax . Other important subdirectories of this main HylaFAX spooling location are sendq (outgoing job control files), log (contains log files for each fax session), config (modem type definitions), and etc (most HylaFAX configuration files).

HylaFAX installs easily on most systems, and the documentation provides lots of information about the process, so we won't spend time considering it here. Once the software is installed, you use the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Universal Serial Bus (USB) was designed by a consortium of hardware and software vendors—Compaq, Intel, Microsoft and NEC—beginning in 1994. It was conceived to provide a standardized way of connecting a wide range of peripheral devices to a computer (read "personal computer") and to correct some of the limitations of traditional serial and parallel lines.

USB has the following advantages:

Up to 127 devices can be connected.
Devices can be added and removed while the system is running.
Connectors have been standardized across all device types.
It is much faster. The theoretical bandwidth of a USB bus is 12 Mbs/sec; however, actual throughput is more like 8-8.5 Mbs/sec, and devices seldom achieve more than about 2 Mbs/sec.

USB cables contain only four wires: power, ground, send, and receive. Communication is handled in a hierarchical manner, under the control of a master; attached devices all function as slaves, thereby eliminating issues such as avoiding collisions. USB cable connectors are illustrated on the far left in Figure 12-2, and Figure 12-5 illustrates their corresponding pinouts.

Figure 12-5: USB connectors

B-type connectors are used for the USB port on the device, and A-type connectors are used for the port on the hub or computer system.

FreeBSD, HP-UX, Linux, Solaris, and Tru64 all support USB devices to some extent, although the support under HP-UX and Tru64 is limited to the USB keyboards and mice that come with the system (and are accordingly preconfigured by the operating system).

We will consider configuring three sample USB devices—a mouse, a Zip drive, and a printer—on the other three systems in the remainder of this section.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Despite years of hype about the coming paperless office, printing has become more frequent and more complex as time has passed, not less so. Ordinary users now routinely print tens or even hundreds of pages a week, often including the sort of high-quality graphics formerly done only rarely, on expensive, special-purpose devices.

This chapter discusses the printing subsystems of the various Unix versions we are considering. Nowhere is there more variation than in accessing printing devices and spooling jobs. The FreeBSD, Linux, and Tru64 operating systems use the BSD spooling system, HP-UX and Solaris use the System V spooling system, and AIX uses its own spooling system. Each of them is discussed individually.

In this chapter, I'll talk almost exclusively about "print" jobs, but the general discussion applies equally well to related hardcopy devices such asplotters. In fact, the Unix spooling subsystems are flexible enough to be used for purposes unrelated to printing: archiving data, running programs in batch mode, and playing music, among others.

A spooling system typically includes the following components:

Printers: Current output devices include laser printers and inkjet printers, as well as special-purposes devices such as label printers. Printing can be done by a printer attached to the local computer via a serial, parallel, or USB port; by a printer on a remote system; or by a standalone device connected directly to the local area network.
User commands to initiate printing: The user specifies the file to print, which device to print it on (if there is more than one possibility), and any other necessary instructions. BSD calls them print jobs, while System V and AIX refer to them as print requests.
Queues

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The BSD printing subsystem is often referred to by the name of the spooling daemon, lpd . We will so designate it from now on. It can maintain multiple printers, printers at local and remote sites, and multiple print queues. This system can be adapted to support laser printers, raster printers, and other types of devices. As shipped, the spooling system is usually configured to support only a standard line printer.

The LPD spooling system provides several commands allowing users to submit and manage their print jobs:

lpr: Submits a job for printing. When a job is submitted, the lpd daemon assigns it a job ID number, which is used to refer to it in any subsequent commands.
lpq: Lists jobs that are currently in a print queue.
lprm: Removes jobs from the print queues. By default, users can remove only their own jobs, but root can delete any job.

Each of these commands includes a -P option for specifying the desired printer. If it is omitted, the default printer is used, which is specified by setting the PRINTER environment variable to the name of the printer to be used by default. If this variable is not set and -P is not included on a command, the first printer defined in the /etc/printcap configuration file (discussed below) is used (although some older LPD subsystem implementations default to the printer named

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The System V printing system is used on a wide range of Unix systems, from microcomputers with a single printer to high-end mainframes with many printers. Among the operating systems we are considering, the System V printing facility is used by HP-UX and Solaris.

Traditionally, System V printing command options did not allow a space between the option letter and its argument. Although some implementations are more flexible today, we retain the older syntax here.

The System V spooling subsystem provides several user commands for submitting and managing print jobs:

lp: Initiate print requests. When a user submits a print job, it is assigned a unique request ID, which is used to identify it thereafter, usually consisting of the printer name and a number: "ps-102" for example. The lp user command is also supported for compatibility purposes by FreeBSD.
lpstat: List queue contents and configuration. This command is discussed later in this subsection.
cancel: Cancel a pending request. By default, users can remove only their own jobs, but root can delete any job.

All of these commands are supported by AIX as an alternate interface to its own queuing system.

Section 13.2.1.1: The system default printer

The lp command includes a -d option for specifying the desired destination: printer or printer class (see below). If it is omitted, the destination designated in the

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

AIX offers a third approach toprinting and spooling. It is based on AIX's general queueing system; printing is just one predefined way to use it. The queueing system's general operation is illustrated in Figure 13-5.

Figure 13-5: The AIX queueing system

Jobs are submitted to a queue by users using the qprt or enq commands (or another user command that calls them). A file printed using these commands is linked to the spooling area by default, so if the file changes or is deleted before the job actually prints, the output will be affected (the -c option may be used to copy the file to the spooling area with either command). Print requests are stored in /var/spool/lpd/qdir, and any spooled files are stored in /var/spool/qdaemon.

AIX also supports the BSD and System V user print commands for ease-of-use purposes: lp, cancel, lpstat, lpr, lpq, and lprm.

The queues are monitored by the qdaemon daemon, which schedules and initiates jobs. When it is time for a job to execute, qdaemon sends the corresponding file to the queue's backend program for processing. In the case of printing on the local system, the program is /usr/lib/lpd/piobe, but in theory, any program may be used as a backend (this is discussed further later in this section). The output of the backend program is then sent to a specified physical device in the case of local printing. It may also be directed to a file.

SMIT provides an excellent interface to the queueing system, and it is usually the easiest way to create and configure queues and their associated devices. In this section, we will look at all of the components of the queuing system individually so that you will understand how the system works, even if you choose to use SMIT to make administering it easier. The SMIT fastpaths mkpq and chpq will take you directly to the forms to create and modify queues and their associated printing devices.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This section contains strategies and suggestions for approaching various printing problems.

The first step is to narrow down the problem as precisely as possible. Which printers are affected? Are all users affected or just the one with the problem? Once you've determined where the problem is, you can set about dealing with it.

If you've installed a printer but nothing prints on it, check the following items:

Make sure you're using the right kind of cable. Check the printer's documentation for the manufacturer's recommendations.
Make sure the connections are good and that you've specified the right port in the configuration file or commands. If you're using a serial line, make sure the line has been deactivated in /etc/ttytab, /etc/ttys, or /etc/inittab. Signal init to reread its configuration file. Kill the getty process watching that line, if necessary.
Verify that its queue is set up correctly. Send a file to it and then make sure something appears in the spool directory (use the -c option on the printing command under System V and AIX). If it doesn't, the protection on the spooling directories or files may be wrong. In particular, root may own something it shouldn't.

On System V systems, the spool directories located under /var/spool/lp/request are usually owned by the user lp and are protected 755 (write access only for the owner) or sometimes 770. The files in the spool directories are owned by group and user lp and are protected 440.

Under BSD, the spool directories are traditionally owned by user daemon or lp and group lp and also protected 755 (or more stringently).

Under AIX, pending requests are stored in /var/spool/lpd/qdir, owned by user root and group printq and protected 660, and spooled files are stored in /var/spool/q daemon, owned by user bin and group printq, and protected 660.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In this section, we'll consider printing to and from Windows systems.

Like most System V-based Unix operating systems, Windows NT and Windows 2000 systems provide an LPD service to handle incoming remote print jobs from non-Windows systems. The queues on the client Unix systems can be set up as normal for outgoing printing to a remote LPD server (as discussed earlier in this chapter). On the Windows server, you will need to do the following:

Install the LPD printing support software, if necessary. This is part of the Windows TCP/IP implementation, but it is not selected by default at initial operating system installation. Under Windows NT 4, you can do this via the Services tab of the Network Properties dialog.

Under Windows 2000, start the Add/Remove Programs control panel applet, click Add/Remove Windows Components, and then select Other Network File and Print Services. Click the Details button, and then choose Print Services for Unix.
Start the LPD service. Under Windows NT 4, execute the net start lpdsvc command to start the incoming print job server. You may want to add this command to the AutoExNT.Bat file if you have installed that facility.

Under Windows 2000, navigate to the Services and Applications → Services object in the Computer Management application. Then select the TCP/IP Print Server entry and change the start up method to Automatic (as illustrated in Figure 13-7).

Figure 13-7: Modifying the Windows 2000 LPD service

The Samba facility can be used to make Unix printers visible to Windows clients as normal shared printers (for Samba basics, see Section 10.4).

Sharing a printer can be accomplished in two ways: by creating a share entry for a specific printer or by sharing all of the printers within a printcap file. Here is a Samba configuration file entry corresponding to the first approach. It creates a share named

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The LPRng package is an enhanced version of the BSD LPD print spooling system. It was initially developed in the early 1990s by PatrickPowell, first as a rewrite of the LPD spooler that was free of the licensing problems of the original code. Very quickly, however, it began to develop beyond the original LPD capabilities, and it is now a feature-rich version of the original. LPRng is available for virtually any Unix system. The home page for the project is http://www.lprng.com.

Using LPRng does require knowledge of the standard BSD printing subsystem, so you'll need to become familiar with it if your previous experience is mostly with the System V and/or AIX version.

LPRng provides the usual BSD-style user commands: lpr, lpq, and lprm. In addition, it provides versions of lp, lpstat, and cancel for compatibility. It uses the conventional top-level spool directory, /var/spool/lpd.

The LPRng version of lpr is quite a bit smarter than the standard version. It is capable of submitting print jobs directly to a remote system, so there is no longer any need to run the lpd daemon on hosts that are not also print servers themselves (eliminating its modest system load).

Here is an lpr example, which spools a print job directly to the matisse queue on system painters:

$ lpr -Pmatisse@painters 

            files

Another nice feature of LPRng is that lpd may optionally be run as the daemon user rather than root.

Installing LPRng is straightforward and well documented in both the LPRng-HOWTO document and in the Network Printing book mentioned earlier, so I'll simply outline the steps here:

Disable all queues, wait for any current jobs to finish, and stop the current print daemon.
Back up all current print subsystem components: configuration files, command binaries, and so on.
Rename or remove the old printing items.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Common Unix Printing System (CUPS) is another project aimed at improving, and ultimately superceding, the traditional printing subsystems. CUPS is distinguished by the fact that it was designed to address printing within a networking environment from the beginning, rather than being focused on printing within a single system. Accordingly, it has features designed to support both local and remote printing, as well as printers directly attached to the network. We will take a brief look at CUPS in this section. The homepage for the project is http://www.cups.org.

CUPS is implemented via the Internet Printing Protocol (IPP). This protocol is supported by most current printer manufacturers and operating systems. IPP is implemented as a layer on top of HTTP, and it includes support for security-related features such as access control, user authentication, and encryption. Given this structure, CUPS requires a web server on printer server systems.

Architecturally, CUPS separates the print job handling and device spooling functions into distinct modules. Print jobs are given a identifier number and also have a number of associated attributes: their destination, priority, media type, number of copies, and so on. As with other spooling subsystems, filters may be specified for print queues and/or devices in order to process print jobs. TheCUPS system provides many of them. Finally, backend programs are responsible for sending print jobs to the actual printing devices.

CUPS also supports printer classes: groups of equivalent printers fed by a single queue (we've previously also referred to such entities as printer pools). CUPS extends this construct by introducing what it calls "implicit classes." Whenever distinct printers and/or queues on different servers are given the same name, the CUPS system treats the collection as a class, controlling the relevant entities as such. In other words, multiple servers can send jobs to the same group of equivalent printers. In this way, implicit classes may be used to prevent any individual printing device or server system from becoming a single point of failure. Classes may be nested: a class can been a member of another class.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

On most current Unix systems, fonts are made available to applications via the X Window system (although some application packages manage their own font information). In this section, we will consider the main administrative tasks related to managing fonts.

In an ideal world, fonts would be something that users took care of themselves. However, in this world, font handling under X is cumbersome enough that the system administrator often needs to get involved.

In this section, we consider font management using the standard X11R6 tools, and we refer to directory locations as defined by the normal installation of the package. These facilities and locations are often significantly altered (and broken) in some vendors' implementations.

When you think of afont, you probably think of something like Times or Helvetica. These names actually referred tofont families containing a number of different typefaces: for example, regular Times, italic Times, bold Times, bold italic Times, and so on. At the moment, there are quite a few different formats for font files. The most important distinction among them is between bitmap fonts and outline fonts. Bitmap fonts store the information about the characters in a font as bitmap images, while outline fonts define the characters in a font as a series of lines and curves, comprising in this way mathematical representations of the component characters.

From a practical point of view, the main difference between these two font types is scalability. Outline fonts can be scaled up or down any arbitrary amount and look equally good at all sizes. In contrast, bitmap fonts do not scale well, and they look extremely jagged and primitive as they get larger. For this reason, outline fonts are generally preferred to bitmap fonts.

To further complicate matters, there are two competing formats foroutline fonts: Adobe Type 1 and TrueType. In technical terms, the chief difference between them consists of the kind of curves used to represent the characters: Bezier curves and b-splines, respectively. The other major difference between the two formats is price, withType 1 fonts generally being significantly more expensive than TrueType fonts.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Although extensive programming experience is seldom a requirement for a system administration position, writing shell scripts and other sorts of programs is nevertheless an important part of a system administrator's job. There are two main types of programs and scripts that you will be called upon to create:

Those designed to make system administration easier or more efficient, often by automating some process or job.
Those that provide users with necessary or helpful tools that are not otherwise available to them.

This chapter discusses scripts intended for both contexts.

In general, automation offers many advantages over performing such tasks by hand, including the following:

Greater reliability: Tasks are performed in the same (correct) way every time. Once you have automated a task, its correct and complete performance no longer depends on how alert you are or your memory.
Guaranteed regularity: Tasks can be performed according to whatever schedule seems appropriate and need not depend on your availability or even your presence.
Enhanced system efficiency: Time-consuming or resource-intensive tasks can be performed during off hours, freeing the system for users during their normal work hours.

We've already considered the cron facility, which runs commands and scripts according to a preset schedule (see Section 3.2). In this chapter, we'll begin by looking at some example shell scripts and then consider some additional programming/scripting languages and other automation tools.

Lazy people write shell scripts. Laziness is a very important system administrative virtue when it motivates you to create new tools and utilities that make your job easier, more efficient, or even just more pleasant. Ploddingly industrious people type the same commands over and over, day after day; lethargic people write scripts to make the job go faster; truly lazy people develop utilities and programs that make all kinds of jobs go faster (including ones they weren't even thinking about when they started).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In this section, we'll consider several different routine system administration tasks as examples of creating and using administrative shell scripts. The discussions are meant to consider not only these tasks in themselves but also the process of writing scripts. Most of the shell script examples use the Bourne shell, but you can use any shell you choose; it's merely a Unixprejudice that "real shell programmers use the Bourne/Korn/zsh shell," however prevalent that attitude/article of faith may be.

We discussed the various security issues surrounding the password file in Section 7.8 and Section 6.1. The various commands used to check it and its contents could be combined easily in a shell script. Here is one version (named ckpwd):

#!/bin/sh

# ckpwd - check password file (run as root)

#

# requires a saved password file to compare against:

#     /usr/local/admin/old/opg

#

umask 077 

PATH="/bin:/usr/bin"; export PATH



cd /usr/local/admin/old                # stored passwd file location

echo ">>> Password file check for `date`"; echo ""



echo "*** Accounts without passwords:" 

grep '^[^:]*::' /etc/passwd 

if [ $? -eq 1 ]                         # grep found no matches 

then 

   echo "None found." 

fi 

echo ""



# Look for extra system accounts

echo "*** Non-root UID=0 or GID=0 accounts:" 

grep ':00*:' /etc/passwd | \ 

awk -F: 'BEGIN       {n=0}

         $1!="root"  {print $0 ; n=1}

         END         {if (n==0) print "None found."}' 

echo ""



sort </etc/passwd >tmp1 

sort <opg >tmp2                         # opg is the previously saved copy 

echo "*** Accounts added:" 

comm -23 tmp[1-2]                       # lines only in /etc/passwd 

echo "" 

echo "*** Accounts deleted:" 

comm -13 tmp[1-2]                       # lines only in ./opg 

echo "" 

rm -f tmp[1-2]



echo "*** Password file protection:" 

echo "-rw-r--r--  1 root     wheel>>> correct values" 

ls -l /etc/passwd



echo ""; echo ">>> End of report."; echo ""

The script surrounds each checking operation with

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Perl is a free programming language created by Larry Wall and currently developed and maintained by a core group of talented programmers (see http://www.perl.org, http://www.perl.com and http://www.cpan.org for more information). Perl has become quite popular in recent years. It contains many features that make it very well suited to writing scripts for system administrative tasks, including the following:

It combines the short development time of traditional shell programming with some of the best aspects of high-level languages such as C. For example, Perl contains well-implemented arrays (unlike any shell) and an impressive range of built-in functions, and it also includes the ability easily to run standard Unix commands and use filename wildcards (as in a shell).
It provides things that are missing from most or all shells, including string functions, built-in arithmetic, and general regular expression support.
Handling many simultaneous open files is a breeze.
It offers enhanced security features over standard shells.

Perl features come from a variety of sources, including standard shells, C, Fortran, Basic, Pascal, awk, and sed. I don't think Larry's managed to use any COBOL features yet, but I've been wrong before.

To get started using Perl, I recommend the following books:

Learning Perl, by Randall L. Schwartz and Tom Phoenix (O'Reilly & Associates), and Effective Perl Programming, by Joseph N. Hall with Randal L. Schwartz (Addison-Wesley).
If you are interested in incorporating a graphical interface into Perl scripts, consult Learning Perl/Tk by Nancy Walsh (O'Reilly & Associates).
For examples of using Perl for system administration tasks, see

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Don Libes describes his Expect package as "a software suite for automating interactive tools." Expect lets you drive interactive programs from a script. The shell lets you do that too, but only to a very limited extent and not in any general way. Expect lets a script feed input to commands and programs that demand their input from the terminal—meaning /dev/tty. It also allows different things to happen depending on the output it gets back, which goes far beyond what the shell offers. If this doesn't sound like any big deal—and it didn't to me, at first—read on and consider some of the examples in this section. Expect is actually quite addictive once you begin to figure out what it's good for.

For more information on Expect, see its home page at http://expect.nist.gov. The book Exploring Expect, by Don Libes (O'Reilly & Associates) is also very helpful.

Conceptually, Expect is a chat script generalized to the entire Unix universe. Structurally, Expect is actually an extension to another programming language called Tcl. This means that Expect adds commands—and functionality—to the Tcl language. It also means that to build and use Expect, you must also obtain and build Tcl.

The following Expect script illustrates many of the facility's basic features. It is used to run the /usr/local/sbin/test_user script from a user's account. This shell script tests various security-related features of the user's runtime environment, and it needs to be run as the relevant user. This Expect script allows it to be run by the system administrator:

#!/usr/local/bin/expect                  Executable location may vary.

# run_test_user - check security of user acct



set user [lindex $argv 0]                # set user to first argument 

spawn /bin/sh                            # start a conversation 

expect "#" 

send "su - $user\r" 

expect -re "..* $" 

send "/usr/local/sbin/test_user >> /tmp/results\r" 

expect -re "..* $" 

send "exit\r" 

expect "#" 

close                                    # end the conversation

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

There are some system administrative tasks that cannot be done from a shell script or even from Perl. In such cases, it will be necessary to write a program in a programming language such as C (or whatever you like). However, many of the programming principles we've considered so far still apply.

As a first example, consider this small program, which is a version of the yes command created for a system that lacks it:

/* yes.c */ 

#include <stdio.h>



main(argc,argv) 

int argc; 

char *argv[]; 

{ 

while(1)                   /* repeat forever */ 

   if(argc>=2)             /* if there was an argument */ 

      puts(argv[1]);       /* repeat it */ 

   else 

      puts(argv[0]);       /* otherwise use command's name */ 

}

This command works a little differently than the standard yes command in that if no argument is given to the command, it repeats the name it was invoked under rather than "y" by default (if an argument is given, that argument is repeated indefinitely). This allows multiple hard links to be made to the same executable file: yes and no, for example. In virtually every case, repeating "yes" is equivalent to repeating "y".

This version of yes illustrates that C programming need not be incredibly complex and time-consuming, and the program made users on this system quite happy. This program could have been written in Perl, but C is actually easier and more straightforward.

The next C program, designed for an AIX system, illustrates an operation that is best performed in C. This program, setp, assigns a fixed (unvarying) priority to a process (why you might want to do so is discussed in Section 15.2). Here is a simple version, suitable for a single system administrator's own use:

/* setp.c - assign process a fixed priority */ 

#include <sys/sched.h> 

#include <stdio.h>



main(argc,argv) 

char *argv[]; 

int argc; 

{ 

    pid_t pid; 

    int p;



    pid=(pid_t)(atoi(*++argv));/* 1st arg is the PID */ 

    p=atoi(*++argv);/* 2nd arg is the priority */ 

    setpri(pid,p);/* set it */ 

    printf("Setting priority of process %d to %d.\n",(int)pid,p); 

}

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Cfengine is a wonderful tool for configuring and maintaining Unix computer systems. MarkBurgess, the author ofCfengine, describes it as follows:

Cfengine, or the configuration engine, is an autonomous agent and a middle to high level policy language for building expert systems which administrate and configure large computer networks. Cfengine uses the idea of classes and a primitive intelligence to define and automate the configuration and maintenance of system state, for small to huge configurations.

What'd he say? Using Cfengine means that you'll have to get used to some unfamiliar jargon, but it's worth it. Basically, what Mark is saying is that Cfengine is a standalone tool (set of tools) that administers and configures computers according to the instructions in its configuration files. The configuration files describe the desired characteristics of various system components using a high-level language which is easy to learn and use (and involves no programming). In this way, Cfengine can automatically bring one or a very large number of systems into line with each one's individually defined configuration specifications. It can also make sure they stay that way by monitoring them and correcting them as needed on an ongoing basis.

In more practical terms, the following list will give you some idea of the breadth of administration and configuration tasks thatCfengine can automate:

Configure the network interface.
Edit system configuration files and other text files.
Create symbolic links.
Check and correct the permissions and ownership of files.
Delete unwanted files.
Compress selected files.
Distribute files within a network in a correct and secure manner.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In this section, we'll look at Stem, a package that makes it very easy to create sophisticated client-server applications for administrative services. Stem is a relatively new open source package developed by Uri Guttman. The project's home page is http://www.stemsystems.com. Stem can be used to create a variety of useful client-server applications, including ones that are network-based. In essence, Stem allows you to create complex applications with only script-level effort.

Running the Stem demonstration programs is a good way to get used to Stem's capabilities. The ones discussed in this section are available from my website (http://www.aeleen.com).

Installing Stem is straightforward. Once installed, Stem provides you with the ability to create communicating processes via simple configuration files and ordinary Unix commands (or scripts). Stem handles all interprocess communication for you transparently. As we'll see, Stem can be used to create entirely new applications and can also serve as the conduit that allows existing commands and programs to communicate regardless of their individual interfaces.

To understand some Stem examples, we first need to define a few terms:

A hub is a Stem daemon running on a computer system. Stem applications consist of one or more interconnected hubs.
A Stem cell is an object within a Stem hub. Cells provide the various parts of the applications functionality. Stem cells are objects. As such, they have unique names, a list of attributes that can be set, and some defined methods (functions that perform various operations on them).

Stem defines three kinds of cells: a class cell (a defined cell type), an object cell (an actual instance of some class cell making up part of a hub), and a cloned cell (the second and later instances of a cell type that allows for multiple cells to be created from it).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

There's an old and somewhat scatological saying about a job not being finished until thepaperwork is done. In the case of creating scripts and programs, this means writing some sort of documentation. Tools you create can be documented in many different ways, but the usual Unix practice is to produce an online manual page. We'll conclude this chapter with a brief look at creating manual pages for the tools you develop.

Manual-page files are named for the command or utility that they describe, and they are given an extension that matches the number or letter of the man subdirectory in which they reside. For example, a manual-page file for the wgrep command placed into man1 subdirectory would be named wgrep.1.

The simplest possible manual page is just a text file describing a command or topic. However, if you'd like to create something a bit more elaborate, and more like the other manual pages typically found on Unix systems, it is very easy to do so. Manual-page source files are designed for the nroff text formatting system, and they combine the text of the manual page with nroff directives specifying how to format the text. (Not all Unix versions provide the text formatting utilities by default or at all.)

The best way to figure out what the various nroff directives do is to see them in context. In general, they are placed at the beginning of a line and start with a period. Here is a brief manual page source file for the wgrep command, which can also serve as a template for manual pages you might create:

.TH wgrep l 

.SH NAME 

wgrep - windowed grep utility 

.SH SYNOPSIS 

wgrep [options] regexp file(s) 

.SH DESCRIPTION 

.B wgrep 

is a 

.B grep 

utility which prints a window of lines surrounding 

each matching line that it finds in the list of files.

By default, the window is three lines before and after

each matching line. 

.PP 

.B wgrep 

has many options which control how its output looks. 

It can range from plain to painfully excessive. 

.SH OPTIONS 

.TP 5 

.B -w 

Specifies the window size in the form 

.B before:after Either one can be omitted. 

.TP 5 

.B -n 

Include line numbers before each printed line. 

.TP 5 

.B -s 

Include asterisks in front of matching lines. 

.PP 

.SH BUGS 

None of course. 

.SH SEE ALSO 

egrep(1), VMS SEARCH command

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This chapter describes the tools and facilities Unix offers for monitoring and managing the system's CPU, memory, disk and network resources, including some of the limitations inherent in the Unix approach. The first part of the chapter provides an overview of system performance considerations and then discusses Unix processes. The chapter then goes on to consider managing the various sytem resources—CPU, memory, local and network I/O, disk space—in detail.

A large part of managing any system resource is knowing how to measure and interpret its current state, and so we'll spend some time looking at ways to monitor resources and to track their use over time.

This chapter provides a detailed introduction to performance monitoring and tuning. For more detailed information about tuning Unix systems, I recommend these books:

System Performance Tuning by Gian-Paolo D. Musameci and Mike Loukides (O'Reilly). This work focuses on Solaris and Linux systems.
AIX Performance Tuning by Frank Waters (Prentice Hall).
HP-UX Tuning and Performance by Robert F. Sauers and Peter S. Weygant (Hewlett-Packard Professional Books).
Solaris Internals by Jim Mauro and Richard McDougall (Prentice Hall).
NFS and NIS by Hal Stern, Mike Eisler, and Ricardo Labiaga (O'Reilly).

Why is the system so slow? is probably second on any system administrator's things-I-least-want-to-hear list (right after Why did the system crash again?!). Like system reliability, system performance is a topic that comes up only when there is a problem. Unfortunately, no one is likely to compliment or thank you for getting the most out of the system's resources.

System performance-related complaints can take on a variety of forms, ranging from sluggish interactive response time, to a job that takes too long to complete or is unable to run at all because of insufficient resources.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Why is the system so slow? is probably second on any system administrator's things-I-least-want-to-hear list (right after Why did the system crash again?!). Like system reliability, system performance is a topic that comes up only when there is a problem. Unfortunately, no one is likely to compliment or thank you for getting the most out of the system's resources.

System performance-related complaints can take on a variety of forms, ranging from sluggish interactive response time, to a job that takes too long to complete or is unable to run at all because of insufficient resources.

In general, system performance depends on how efficiently a system's resources are applied to the current demand for them by various jobs in the system. The most important system resources from a performance perspective are CPU, memory, and disk and network I/O, although sometimes other device I/O can also be relevant. How well a system performs at any given moment is the result of both the total demand for the various system resources and how well the competition among processes for them is being managed. Accordingly, performance problems can arise from a number of causes, including both a lack of needed resources and ineffective control over them. Addressing a performance problem involves identifying what these resources are and figuring out how to manage them more effectively.

As with most of life, performance tuning is much harder when you have to guess what normal is. If you don't know what the various system performance metrics usually show when performance is acceptable, it will be very hard to figure out what is wrong when performance degrades. Accordingly, it is essential to do routine system monitoring and to maintain records of performance-related statistics over time.

When the lack of a critical resource is the source of a performance problem, there are a limited number of approaches to improving the situation. Put simply, when you don't have enough of something, there are only a few options: get more, use less, eliminate inefficiency and waste to make the most of what you have, or ration what you have. In the case of a system resource, this can mean obtaining more of it (if that is possible), reducing job or system requirements to desire less of it, having its various consumers share the amount that is available by dividing it between them, having them take turns using it, or otherwise changing the way it is allocated or controlled.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Unix provides the ability to monitor process execution and, to a limited extent, specify execution priorities. By doing so, you can control how CPU time is allocated and (indirectly) how memory is used. For example, you can expedite certain jobs at the expense of all others, or you can maintain interactive response times by forcing large jobs to run at lowered priority. This section discusses Unix processes and the tools available for monitoring and controlling process execution.

The uptime command gives you a rough estimate of the system load:

% uptime 

3:24pm up 2 days, 2:41, 16 users, load average: 1.90, 1.43, 1.33

uptime reports the current time, how long the system has been up, and three load average figures. The load average is a rough measure of CPU use. These three figures report the average number of processes active during the last minute, the last five minutes, and the last 15 minutes. High load averages usually mean that the system is being used heavily and the response time is correspondingly slow. Note that the system's load average does not take into account the priorities of the processes that are running.

What's high? As usual, that depends on your system. Ideally, you'd like a load average under about 3-5 (per CPU), but that's not always possible given the workload that some systems are required to handle. Ultimately, "high" means high enough that you don't need uptime to tell you that the system is overloaded—you can tell from its response time.

Furthermore, different systems behave differently under the same load average. For example, on some workstations, running a single CPU-bound background job at the same time as X Windows will bring interactive response to a crawl even though the load average remains quite low. A low load average is no guarantee of a fast response time, because CPU availability is just one factor affecting overall system performance. You can generally expect to see higher typical load averages on server systems than on single-user workstations.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

CPU usage is usually the first factor that I consider when I am tracking down a performance problem or just trying to assess the current system state in general.

Most Unix systems use a priority-based round-robin scheduling algorithm to distribute CPU resources among multiple competing processes. All processes have an execution priority assigned to them, an integer value that is dynamically computed and updated on the basis of several factors. Whenever the CPU is free, the scheduler selects the most favored process to begin or resume executing; this usually corresponds to the process with the lowest priority number, because lower numbers are defined as more favored than higher ones in typical implementations.

Although there may be a multitude of processes simultaneously present on the system, only one process actually uses the CPU processor at any given time (assuming the system has only a single CPU). Once a process begins running, it continues to execute until it needs to wait for an I/O operation to complete, receives an interrupt from the kernel, or otherwise gives up control of the CPU, or until it exhausts the maximum execution time slice (or quantum ) defined on that system (10 milliseconds is a common value). Once the current process stops executing, the scheduler again selects the most favored process on the system and starts or resumes it. The process of changing the current running process is called a context switch.

Multiple runnable processes at the same priority level are placed into the run queue for that priority level. Whenever the CPU is free, the scheduler starts the processes at the head of the lowest-numbered, nonempty run queue. When the process at the top of a run queue stops executing, it goes to the end of the line, and the next process moves to the front.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Memory resources have at least as much effect on overall system performance as the distribution of CPU resources. To perform well, a system needs to have adequate memory not just for the largest jobs it will run, but also for the overall mix of jobs typical of its everyday use. For example, the amount of memory that is sufficient for the one or two big jobs that run overnight might provide only a mediocre response time under the heavy daytime interactive use. On the other hand, an amount of memory that supports a system's normal interactive use might result in quite poor performance when larger jobs are run. Thus, both sets of needs should be taken into consideration when planning for and evaluating system memory requirements.

Paging and swapping are the means by which Unix distributes available memory among current processes when their total memory needs exceed the amount of physical memory. Technically, swapping refers to writing an entire process to disk, thereby freeing all of the physical memory it had occupied. A swapped-out process must then be reread into memory when execution resumes. Paging involves moving sections of a process's memory—in units called pages—to disk, to free up physical memory needed by some process. A page fault occurs when a process needs a page of memory that is not resident and must be (re)read in from disk. On virtual memory systems, true swapping occurs rarely if at all and usually indicates a serious memory shortage, so the two terms are used synonymously by most people.

Despite the strong negative connotations the term has acquired, paging is not always a bad thing. In the most general sense, paging is what makes virtual memory possible, allowing a process' memory requirements to greatly exceed the actual amount of physical memory. A process' total memory requirement includes the sum of the size of its executable image (known as its text segment) and the amount of memory it uses for data.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Disk I/O is the third major performance bottleneck that can affect a system or individual job. This section will look first at the tools for monitoring disk I/O and then consider some of the factors that can affect disk I/O performance.

Unfortunately, Unix tools for monitoring disk I/O data are few and rather poor. BSD-like systems provide the iostat command (all but Linux have some version of it). Here is an example of its output from a FreeBSD system experiencing moderate usage on one of its two disks:

$ iostat 6

      tty             ad0              ad1              cd0             cpu

 tin tout  KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id

   0   13 31.10  71  2.16   0.00   0  0.00   0.00   0  0.00   0  0 11  2 87

   0   13 62.67  46  2.80   0.00   0  0.00   0.00   0  0.00   0  0 10  2 88

   0   13  9.03  64  0.56   0.00   0  0.00   0.00   0  0.00   1  0  7  1 91

   0   13  1.91  63  0.12   0.00   0  0.00   0.00   0  0.00   2  0  4  2 92

   0   13  2.29  64  0.14   0.00   0  0.00   0.00   0  0.00   2  0  5  1 92

The command parameter specifies the interval between reports (and we've omitted the first, summary one, as usual). The columns headed by disk names are the most useful for our present purposes. They show current disk usage as the number of transfers/sec (tps) and MB/sec.

System V-based systems offer the sar command, and it can be used to monitor disk I/O. Its syntax in this mode is:

$ sar 

               -d 

               interval [count]

interval is the number of seconds between reports, and count is the total number of reports to produce (the default is one). In general, sar's options specify what data to include in its report. sar is available for AIX, HP-UX, Linux, and Solaris. However, it requires that process accounting be set up before it will return any data.

This report shows the current disk usage on a Linux system:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This section looks at the tools available to monitor and track disk space usage. It then goes on to discuss ways of approaching a perennial administrative challenge: getting users to reduce their disk use.

The

df

-k

command produces a report that describes all the filesystems, their total capacities, and the amount of free space available on each one (reporting sizes in KB). Here is the output from a Linux system:

File system    Kbytes   used     avail     capacity     Mounted on 

/dev/sd0a      7608     6369     478       93%          /

/dev/sd0g      49155    45224    0         102%         /corp

This output reports the status of two filesystems: /dev/sd0a, the root disk, and /dev/sd0g, the disk mounted at corp (containing all files and subdirectories underneath /corp). Each line of the report shows the filesystem's name, the total number of kilobytes on the disk, the number of kilobytes in use, the number of kilobytes available, and the percentage of the filesystem's storage that is in use. It is evident that both filesystems are heavily used. In fact, the /corp filesystem appears to be overfull.

As we've noted earlier, the operating system generally holds back some amount of space in each filesystem, allocatable only by the superuser (usually 10%, although Linux uses 5% by default). A filesystem may appear to use over 100% of the available space when it has tapped into this reserve.

The du -k command reports the amount of disk space used by all files and subdirectories underneath one or more specified directories, listed on a per-subdirectory basis (amounts are given in KB).

A typical du report looks like this:

$ du -k /home/chavez 

50    /home/chavez/bin 

114    /home/chavez/src 

... 

34823 /home/chavez

This report states that in the directory /home/chavez, the subdirectory bin occupies 50 blocks of disk space, and the subdirectory

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This section concludes our look at performance monitoring and tuning on Unix systems. It contains a brief introduction to network performance, a very large topic whose full treatment is beyond the scope of this book. Consult the work by Musameci and Loukides for further information.

The netstat -s command is a good place to start when examining networkperformance. It displays network statistics. You can limit the display to a single network protocol via the -p option, as in this example from an HP-UX system:

$ netstat -s -p tcp                    

               Output shortened.

tcp:

    178182 packets sent

          111822 data packets (35681757 bytes)

          30 data packets (3836 bytes) retransmitted

          66363 ack-only packets (4332 delayed)

    337753 packets received

          89709 acks (for 35680557 bytes)

          349 duplicate acks

          0 acks for unsent data

          284726 packets (287618947 bytes) received in-sequence

          0 completely duplicate packets (0 bytes)

               3 packets with some dup, data (832 bytes duped)

               11 out of order packets (544 bytes)

               5 packets received after close

               11 out of order packets (544 bytes)

The output gives statistics since the last boot.

Network operations are proceeding nicely on this system. The highlighted lines are among those that would indicate transmission problems if the values in them rose to appreciable percentages of the total network traffic.

More detailed network performance data can be determined via the various network monitoring tools we considered in Section 8.6.

Good network performance depends on a combination of several components working properly and efficiently. Performance problems can arise in many places and take many forms. These are among the most common:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

As we've noted many times before, the kernel is the heart of the Unix operating system. It is the core program, always running while the operating system is up, providing and overseeing the system environment. Thekernel is responsible for all aspects of system functioning, including:

Process creation, termination and scheduling
Virtual memory management (including paging)
Device I/O (via interfaces with device drivers : modules that perform the actual low-level communication with physical devices such as disk controllers, serial ports, and network adapters)
Interprocess communication (both local and network)
Enforcing access control and other security mechanisms

Traditionally, the Unix kernel is a single, monolithic program. On more recent systems, however, the trend has been toward modularized kernels: small core executable programs to which additional, separate object or executable files—modules —can be loaded and/or unloaded as needed. Modules provide a convenient way to provide support for a new device type or add specific new functionality to an existing kernel.

In many instances, the standard kernel program provided with the operating system works perfectly well for the system's needs. There are a few circumstances, however, where it is necessary to create a custom kernel (or perform equivalent customization activities) to meet the special needs of a particular system or environment. Some of the most common are:

To add capabilities to the kernel (e.g., support for disk quotas or a new filesystem type)
To add support for new devices
To remove unwanted capabilities/features from the kernel to reduce its size and resource consumption (mostly memory) and thereby presumably improve system performance

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Tru64 and FreeBSD use an almost identical process for building a customized kernel. They rely on a configuration file for specifying which capabilities to include within the kernel and setting the values of various system parameters. The configuration file is located in /usr/sys/conf on Tru64 systems and in /usr/src/sys/arch/conf under FreeBSD, where arch is an architecture-specific subdirectory (we'll use i386 as an example).

Configuration filenames are conventionally all uppercase, and the directory typically contains several different configuration files. The one used to build the current kernel is usually indicated in the /etc/motd file. For example, the GENERIC file was used to build the kernel on this FreeBSD system:

FreeBSD 4.3-RELEASE (GENERIC) #0: Sat Apr 21 10:54:49 GMT 2001

Default Tru64 configuration files are often named GENERIC or sometimes ALPHA.

On FreeBSD systems, you will first need to install the kernel sources if you have not already done so:


            FreeBSD

# cd /

# mkdir -p /usr/src/sys       

            If not already present.

# mount /cdrom

# cat /cdrom/src/ssys.[a-d]* | tar xzvf -

To add a device to a Tru64 system, you must boot the generic kernel, /genvmunix, to force the system to recognize and create configuration information for the new device:


            Tru64

# shutdown -r now

...

>>> boot -fi /genvmunix

...

# bcheckrc 

            or

             lsmbstartup

# sizer -n NEWDEVS

On both systems, the first step in configuring and building a kernel is to save a copy of the old configuration file and then make any necessary changes to it:

FreeBSD	Tru64
# cd /usr/src/sys/i386/conf # cp GENERIC NEWKERN # chmod +w NEWKERN # emacs NEWKERN

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

SAM is still the easiest way to build a new kernel under HP-UX. However, you can build one manually if you prefer:

# cd /stand                                      

            Move to kernel directory.

# mv vmunix vmunix.save                          

            Save current kernel.

# cd build                                       

            Move to build subdirectory.

# /usr/lbin/sysadm/system_prep -v -s system      

            Extract system file.

# kmtune -s 

            var

            =

            value

             -S /stand/build/system     

            Modify kernel parameters.

  ...

# mk_kernel -s ./system -o ./vmunix_new          

            Build new kernel.

# kmupdate /stand/build/vmunix_new               

            Schedule  kernel install.

# mv /stand/system /stand/system.prev            

            Save old system file.

# mv /stand/build/system /stand/system           

            Install new system file.

The system_prep script creates a new system configuration file by extracting the information from the running kernel. The kmtune command(s) specify the values of kernel variables for the new kernel.

The mk_kernel script calls the config command and initiates the make process automatically. Once the kernel is built, you use the kmupdate command to schedule its installation at the next reboot. You can then reboot to activate it.

If there is a problem with the new kernel, you can boot the saved kernel with a command like the following:

ISL> hpux /stand/vmunix.save

To determine what kernel object files are available, use the following command to list the contents of the /stand directory:

ISL> hpux ll /stand

The system file contains information about system devices and settings for various kernel parameters. Here are some examples of the latter:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

There was a time when changes to the Linux kernel came out on a daily basis, and the hardest part about building a Linux kernel was knowing how to stop. These days, the production kernel tree is much more stable, but there are still significant kernel updates released on a regular basis.

One way to take advantage of these updates is to download and install the kernel update packages made available in conjunction with the Linux distribution you are using. The advantage of this method is that the changes are merged into the actual distribution's kernel source code—in other words, the source code as modified by the distribution's creators—a process that can be daunting and difficult for anyone else.

However, you may still decide to build your own custom kernel, probably beginning from a standard source-code package. If you decide to go this route, be sure that you understand any changes that may be required to support distribution-specific features that you may be using.

The following commands illustrate the basic procedure for building a Linux kernel (the conservative way, not the kernel hacker's way). By way of illustration, they apply patches to bring the source code package to the current revision level before building the kernel.

The first steps are to save the old kernel and unpack the kernel source code, if necessary:

# cp /boot/vmlinuz /boot/vmlinuz.save           

            Save current kernel.

# cd /usr/src                                   

            Change to source code area.

# bzip2 -dc linux-2.4.

            x

            .tar.bz2 | tar xvf -     

            Unpack starting kernel.

You may choose to install a source-code RPM from your distribution instead of the standard tar archive (the latter is available from http://www.kernel.org).

Once you have the Linux kernel source code installed, you start the process here:

# for p in 

            patch-list

            ; do                       

            Apply any patches to kernel.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The Solaris kernel is stored in /kernel/unix. It is structured around loadable modules: executables that add capabilities and functionality to the system. Modules add flexibility in that they can be installed and uninstalled as needed. The operating system probes the hardware each time the system boots and loads the needed modules. Modules are stored in the subdirectories of /kernel.

The following commands display information about the current system configuration (in voluminous quantities):

modinfo: Display loadable modules.
prtconf: Show system hardware configuration (peripheral devices).
sysdef: Display loadable modules, hardware configuration, and the values of some tunable kernel parameters.

In general, little kernel configuration is required on Solaris systems, other than adding modules or drivers to support new devices when they are installed.

Vendors generally provide installation instructions and associated drivers along with their hardware. Device drivers can also be manually loaded and unloaded with add_drv and rem_drv, respectively, and other modules can be loaded and unloaded with modload and modunload.

The /etc/system configuration file allows you to specify what modules are and are not loaded and to specify the values of system parameters. The latter occurs in the section headed by these comment lines:

* set: Set an integer variable in the kernel or a module 

*      to a new value. 

*

set scsi_options=0x58 

set TS:ts_maxupri=69 

set TS:ts_maxkmdpri=39

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

On AIX systems, you never need to rebuild a kernel because system parameters may be changed on a running system. The current values of AIX system parameters may be displayed with the lsattr command:

# lsattr -EHl sys0                     

             

            Final option letter is a lowercase L.

attribute    value    description                    user_settable

  

keylock      normal   State of system keylock at boot time   False

maxbuf       20       Maximum pages in block I/O BUFFER CACHE True

maxmbuf      2048     Maximum KB real memory allowed for MBUFSTrue

maxuproc     400      Maximum # PROCESSES allowed per user    True

autorestart  false    Automatically REBOOT after a crash      True

iostat       false    Continuously maintain DISK I/O history  True

realmem      65536    Amount of usable physical memory (KB)  False

conslogin    enable   System Console Login                   False

fwversion    IBM,SPH01184   Firmware version,revision levels False

maxpout      0        HIGH water mark pending write I/Os/file True

minpout      0        LOW water mark pending write I/Os/file  True

fullcore     false    Enable full CORE dump                   True

pre430core   false    Use pre-430 style CORE dump             True

ncargs       6        ARG/ENV list size in 4KB blocks         True

rtasversion  1        Open Firmware RTAS version             False

modelname    IBM,7044-270   Machine name                     False

systemid     IBM,011000189  Hardware system identifier       False

boottype     disk     N/A                                    False

SW_dist_intr false    Enable SW distribution of interrupts    True

cpuguard     disable  CPU Guard                               True

frequency    93750000 System Bus Frequency                   False

The list includes parameters that can be modified and ones that can't. Being able to see, for example, the amount of physical memory present on the system and the current setting of the front panel key (keylock) can be useful and convenient. The latter item is especially useful when the CPU unit is positioned so that the physical key position not readily visible.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Virtually all current Unix systems provide some form of user-based process accounting: the operating system tracks system usage by recording statistics about each process that is run, including its UID. In addition, records are kept of the image that was run by the process and the system resources (such as memory, CPU time, and I/O operations) that it used.

The accounting system is designed for tracking system resource usage, primarily so that users can be charged money. The data collected by the accounting system can also be used for some types of system performance monitoring and security investigations (see Chapter 15 and Chapter 7).

There are two distinctaccounting systems in use, originating from the traditional vanilla BSD and System V environments. Although they are quite different, they are based on the same raw data. Hence, the sort of information that may be gleaned from them is essentially identical, although output methods and formats are not. They also suffer from the same limitations; for example, neither system provides for project-based accounting in any straightforward way.

As with all accounting systems, the Unix accounting software places a small but detectable load on the system. BSD-style accounting used to be enabled in new systems but is generally disabled these days; the process for enabling it is described later in this chapter. System V-style accounting is always initially disabled and must be set up by the system administrator.

On many systems, the accounting utilities are packaged as a separately installable module that the system administrator may include or not, as appropriate. Since the accounting system is also an important component of performance and system security monitoring, I recommend always installing it, even if you don't need accounting features, because the disk requirements are quite modest.

Accounting capabilities also need to be present in the Unix kernel, and many systems make this configurable as well (although they are usually present in default kernels).

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

When accounting is enabled, the Unix kernel writes a record to a binary data file as each process terminates. These files are traditionally stored in the home directory of the standard user adm (/var/adm on most recent systems), although some current systems no longer use that account and simply run the accounting software as root. Nevertheless, for sentimental reasons, the examples in this chapter generally use /var/adm as the location of the accounting data files.

Records written to the rawaccounting file by the System V and BSD accounting systems contain the same data. It is only the ordering of the fields within each record that varies between the flavors (consult the /usr/include/sys/acct.h file for details). Accounting records contain the following data about each process that runs on the system:

Image name (for example, grep)
CPU time used (separated into user and system time)
Elapsed time taken for the process to complete (sometimes called "wall clock time")
Time the process began
Associated user and group IDs
Lifetime memory usage (in BSD, the average use of the process' lifetime; in System V, the aggregate sum of the memory in use at each clock tick)
Number of characters read and written
Number of disk I/O blocks read and written
Initiating TTY
Accounting flags associated with the process
Process' exit status

Other binary data files store additional accounting data:

utmp: Contains data about each currently logged-in user.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Administering BSD-style accounting involves several tasks:

Enabling the accounting system and arranging for it to be started automatically at boot time.
Periodically merging raw accounting records into the summary data files.
Running accounting reports.

As indicated, BSD-style accounting uses some additional accounting summary files, located in the same directory as the primary accounting file. These files store processed, summarized versions of the accumulated raw accounting data. They are maintained by the sa command and are useful in keeping the size of the accounting file to a manageable level:

savacct: The standard accounting summary file
usracct: The user-based accounting summary file

The accton command controls the current state of a BSD-style accounting facility. The command enables accounting when an accounting file is specified as its argument (its location in the filesystem varies). Without an argument, the command disables accounting. Once the command is executed, accounting records will be written automatically to the accounting file.

The one tricky aspect of accton is that any raw accounting data file you specify must already exist, because the command will not create it. Accordingly, commands such as the following are used to start the accounting system from one of the system boot scripts:

return="done"

echo -n "Starting process accounting: "

test -e /var/account/pacct || touch /var/adm/pacct

/usr/sbin/accton /var/adm/pacct || return="failed"

echo "$return"

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The System V-style accounting scheme is much more elaborate than the BSD-style variant. It is used by AIX, HP-UX, and Solaris systems.

This facility is a complex system of commands, shell scripts, and C programs, called by one another in long sequences, all purported to be totally automated and requiring little or no intervention. In reality, it's a design only a fervent partisan could love (although, to be fair, it does generally get the job done on stable systems). Older versions of the manual pages alternated between assuring the reader that the system was robust, reliable, and trouble-free and describing convoluted procedures for patching corrupted accounting data files. Most of the latter has been edited out at this point, but be forewarned.

The main accounting file is named pacct, usually found in /var/adm . Other key subdirectories used by the system are found under /var/adm/acct:

fiscal: Reports by fiscal period (usually month) and old binary fiscal period summary files
nite: Daily binary summary file; daily processed accounting record; raw disk accounting records; and status, error log, and lock files
sum: Binary daily and current fiscal period cumulative summary files and daily reports

On AIX systems, these subdirectories have to be created by hand:

# cd /var/adm/acct

# mkdir -m 755 fiscal nite sum

# chown adm.adm fiscal nite sum

In addition to the wtmp and pacct files discussed previously, there are some other raw data files generated by this accounting system:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Unix systems which use the BSD/lpd-style spooling subsystem also usually offer printing accounting via the pac utility. Printer accounting is enabled with the af field in its /etc/printcap entry. For example, this entry designates /var/adm/ps1_acct as the accounting file for this printer:

laser|postscript|ps1:\

     :lp=/dev/lp:sd=/var/spool/ps1:if=/usr/local/sbin/filt:\

     :mx#0:af=/var/adm/ps1_acct:pw#132:pl#66:pc#100:\ 

     ...

For text printers, the pw and pl fields (page width and length, in characters and lines, respectively) are used to generate accounting data. For other printer types, a more sophisticated approach is required.

Under AIX, printing accounting is enabled by adding an acctfile keyword to the queue definition stanza in /etc/qconfig:

laser: 

device = dlas1,dlas2 

header = group 

trailer = never 

acctfile = /var/adm/qacct 

...

This line may be added with a text editor, by using the chque command, or by using SMIT, but in any case, the queue should be stopped first (for example, with

enq

-D

) and then restarted after reconfiguration (see Chapter 13 for more information).

Merely defining the accounting file field will not in itself cause accounting records to be created. The facility requires support for accounting data from the filter(s) used to process the print jobs. There are many filters available that include this functionality. See Chapter 13 for more information about filters. Printing accounting, including techniques for generating the required data for modern printers, is also discussed in detail in Network Printing, by Todd Radermacher and Matthew Gast (O'Reilly & Associates).

By default, pac displays total usage of the current printer (as designated in an environment variable or as the system default printer) for each user on each host over the lifetime of the printer's accounting files. The units are pages for printers and linear feet for plotters and similar raster devices. You can combine all the host-specific entries for each user by including

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

We'll conclude this book as we began: by considering the system administrator's job, this time considering it as a profession.

I find system administrators to be a very interesting group of people. One of the reason is that system administrators as a group tend to have diverse and varied backgrounds. Many people come to system administration after being educated and/or working in other areas. It's only relatively recently that system administration has been available as an "official" educational track and career path.

Whatever their backgrounds, though, system administrators are valuable technical professionals, and they should be treated as such (and also should act accordingly). Sadly, the contributions of system administrators are not always respected or even noticed. The way to address this oversight lies in greater visibility for the profession as a whole.

SAGE, the System Administrators Guild, is an organization that works very hard at doing just that. It also provides many valuable services to the individual system administrators that are its members.

For almost a decade,SAGE has served the needs of system administrators around the world. One of SAGE's main goals is the increase of visibility and recognition of system administration as a profession. To this end, SAGE has published as series of short topics handbooks. All of them are excellent. A good one to start with is Job Descriptions for System Administrators (Revised and Expanded Edition), edited by Tina Darmohray. This work provides detailed job descriptions for system administration positions at various levels. As such, it is very useful for evaluating both your skills and your present position in light of general practices.

Along the same lines, SAGE committees are currently working on the System Administration Book of Knowledge, which includes a listing of all the tasks a system administrator might encounter (but not how to do them), and they are also working on a university curriculum for new system administrators. Complementing these is a vendor-neutral certification program developed as a "career certification" instead of the usual "product certification."

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

For almost a decade,SAGE has served the needs of system administrators around the world. One of SAGE's main goals is the increase of visibility and recognition of system administration as a profession. To this end, SAGE has published as series of short topics handbooks. All of them are excellent. A good one to start with is Job Descriptions for System Administrators (Revised and Expanded Edition), edited by Tina Darmohray. This work provides detailed job descriptions for system administration positions at various levels. As such, it is very useful for evaluating both your skills and your present position in light of general practices.

Along the same lines, SAGE committees are currently working on the System Administration Book of Knowledge, which includes a listing of all the tasks a system administrator might encounter (but not how to do them), and they are also working on a university curriculum for new system administrators. Complementing these is a vendor-neutral certification program developed as a "career certification" instead of the usual "product certification."

Organized as a special technical group ofUSENIX, SAGE's thousands of members share information, technical tips, and white papers on SAGE's website. Many of SAGE's services are available for no charge at the SAGE portal http://www.sage.org. They include:

SAGEwire: An online discussion forum with daily updates of news for and about system administration.
SAGEweb: Items of long-term interest, including SAGE's activities, member services, and organizational news.
SAGEnews: An email periodical with just the right amount of summarization on system administration news.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

I'll close this brief consideration of the profession and professionalism with the full list of administrative virtues. This time, we'll take a somewhat more humorous tack than we have previously:

Flexibility: Being able to wriggle out of tight spots and escape when irate users seem to have you cornered.
Ingenuity: Realizing that you can use syslog to send messages to your friend on another system.
Patience: Remaining capable of waiting until the final sendmail configuration bug is fixed.
Persistence: The compulsion to try just-one-more-thing to fix a problem before going home.
Adherence to Routine: Insisting on real cream and sugar-in-the-raw in your coffee (which is Kona or nothing).
Attention to Detail: Noticing that the clock on one of your systems is using Aleutian time, and changing all the others to match.
Laziness: Writing a 250-line Perl script to avoid typing 15 characters.

What these alternative definitions are designed to highlight is the fact that system administration is not only challenging and sometimes frustrating, but can also be fun. In fact, this is my last piece of advice for you:

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The purpose of this appendix is to review major Bourne shell (sh) programming features. It is not intended as a comprehensive treatment of shell programming or of the features of the various shells. Rather, it will enable you to understand and modify the system administration scripts on your system, most of which are Bourne shell scripts (although this is slowly changing).

In the course of this appendix, we will look at many examples drawn from actual system scripts, as well as some other simple examples to illustrate basic features. Some of the latter examples use shell commands executed at the command prompt (although the corresponding commands could obviously appear just as easily in scripts).

With the exception of AIX and Linux, the Unix versions we are considering use the Bourne shell for system scripts. AIX uses the Korn shell (ksh), and Linux uses the Bourne-Again shell (bash). Linux system scripts also frequently use bash features that are not part of the standard shell. Since they are extensions to sh, however, the most important of these features are now described in this appendix. When I mention bash features here, I am doing so in a descriptive sense only—not in an historical sense—in comparison to what is offered in the standardBourne shell. The feature in question may also be present in other shells and may very well have originated in a shell other than bash.

The books UNIX in a Nutshell: System V Edition, by Arnold Robbins, and Learning the bash Shell, by Cameron Newham and Bill Rosenblatt (both published by O'Reilly & Associates) are excellent references for sh and bash, respectively.

Discussing Korn shell features is beyond the scope of this appendix; consult the book Learning the Korn Shell by Bill Rosenblatt and Arnold Robbins (O'Reilly & Associates) for a detailed discussion of this shell.

As much as possible, the examples in this appendix come from actual system scripts. Thus, while there are many useful techniques illustrated in the examples, they should not generally be viewed as recommendations of shell programming style, and many readers may quibble or disagree with them at some points.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This section reviews some basic syntactic features of the Bourne shell, in a somewhat arbitrary order.

Lines in shell scripts beginning with number signs are comments:

# Start or stop the lp scheduler

In fact, comments can begin anywhere on a line:

grep ':00*:' /etc/passwd       # Check for UID=0 accounts

The first line of a shell script usually looks like this:

#!/bin/sh

This identifies the shell that should run the script, in this case, the Bourne shell. The path location can vary.

The best practice is to begin every shell script with a line identifying the shell to be used to run it. If this line is not present, /bin/sh is assumed.

The Bourne shell offers some syntactic flexibility over other shells. For example, quotes remain in effect across physical lines, as in this example we looked at in Chapter 7:

echo "*** Non-root UID=0 or GID=0 accounts:"

grep ':00*:' /etc/passwd | \

  awk -F: 'BEGIN        {n=0}

           $1!="root"   {print $0 ; n=1}

           END          {if (n==0) print "None found."}'

Note that the arguments to the awk command extend across three lines, which is much more readable than forcing them onto a single line.

Another construct you'll see quite often is this redirection of standard output to a file and of standard error to standard output (and thus to the same file):

/usr/lib/lpshut > /dev/null 2>&1

In this case the file is /dev/null, but the concept applies whether output goes to a real disk file, to /dev/console, or gets thrown out.

Note that standard output and error can also be redirected to separate destinations:

/sbin/rc.local  1>> boot.log  2> /dev/console

In general, the form n > file redirects file descriptor n to the specified file; file may also be replaced by a second file description, as in the form n ₁

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

In this section, we begin looking at Bourne shell control structures: programming features seldom used on the command line. The first construct we will consider is if, used for conditional command execution. Here is the simplest syntax of an if statement and a simple if example:

if condition 

then 

   commands 

fi

  

if test -x /sbin/sendmail ; then 

   /sbin/sendmail $SENDMAIL_OPTIONS

fi

The if command runs the commands in condition. If they return a true value (zero exit status), the commands are executed; on a false, nonzero status, the script jumps to the command after fi.

The preceding example uses the test command to check for the file /sbin/sendmail and starts the daemon if it's present and executable. We'll look at constructing conditions more closely a little later. For now, notice the placement of the then command. then must appear to the shell as a separate command, or you'll get an error. So it must be on a new line after the if command, or it must be separated from the if command by a semicolon. The same rules hold true for the fi command that ends the if construct.

There are more complex forms of if:

strings /vmunix | grep Unix > /tmp/motd 

i=`head -1 /etc/motd | grep -c Unix` 

if [ $i -eq 0 ]  

then 

   cat /etc/motd >>/tmp/motd 

else 

   tail +2 /etc/motd >>/tmp/motd 

fi 

mv /tmp/motd /etc/motd

This example illustrates the if-then-else construct. It updates the Unix version string in the message-of-the-day file. First, it gets the current Unix version string out of the kernel file / vmunix and puts it in the file /tmp/motd. Then, it checks whether the string "Unix" appears in the first line of /etc/motd. If it doesn't, the entire contents of /etc/motdare appended to /tmp/motd by the tail command. Otherwise—when "Unix" does appear in the first line of /etc/motd—all but its first two lines are appended to /tmp/motd. Finally, the new message file replaces the current one.

Here is an example of the most complex form of if:

set `who -r`

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This section describes other important Bourne shell and bash control structures.

The while statement is one way to create a loop. It has two forms:

while condition

do

   commands

done



until condition

do

   commands

done

In the while form, the commands are executed until the condition becomes false. In the until form, they are executed until the condition becomes true. Here is an example of while:

cat /etc/fstab | 

while read DEVICE MOUNT_DIR READONLY FS DUMMY1 DUMMY2 

do 

  fsck (if required) and mount the device 

done

This loop takes each line of /etc/fstab in turn (sent to it via cat) and performs an appropriate action for the corresponding device. The while loop will end when read (described later) returns a nonzero status, indicating an end-of-file.

Here is another very similar example, taken from a recent Linux system:

while read des fs type rest; do

  case "$fs" in

    /) break;;

    *)      ;;

  esac

done < /etc/fstab

if [ -e "$des" -a "$type" != "resiserfs" ]

then

  run fsck

fi

Note that the input to the while loop is provided via I/O redirection following the done statement.

The case command is a way to perform a branching operation. Here is its syntax:

case str in 

   pattern_1)

     commands 

     ;; 

  

   pattern_2) 

     commands 

     ;; 

   ...

   pattern_n) 

     commands 

     ;; 

  

   *) 

     commands 

     ;; 

esac

The value in str is compared against each of the patterns. The corresponding commands are executed for the first match that is found. The double semicolons are used to end each section. Wildcards are allowed in the patterns, and a pattern consisting of a single asterisk can serve as a default if no other pattern is matched; it must be placed at the end of the case command.

Here is an example of the case command:

/etc/fsck -p >/dev/console 

case $? in                     Select action based on fsck return value.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

The read command reads one line from standard input and assigns the next word in the line to each successive variable specified as its arguments; extra words are assigned to its final argument. For example, these commands:

cat file.dat | \

while read x y z 

do 

   echo $x $y $z

done

produce output like this:

a b c 

d e f 

...

read can be used either for reading sequentially through a file (as in the earlier example with while) or for getting runtime input from the user. Here is an example using read for command input:

echo "fsck all disks? [y] \c" 

read ans < /dev/console

bash provides the select command for prompting the user to select an item from a menu, as in this example:

$ cat choose.bash

#!/bin/bash

  

PS3="Choose an operating system: "

select os in "aix" "hp-ux" "solaris" "tru64" "linux" "freebsd"

do                                Loop until a valid choice is entered.

  if [ $os ]; then

    echo You chose $os which was choice number $REPLY

    break

  else

    echo -e "\nInvalid choice -- try again.\n"

  fi

done

$ choose.bash

1) aix

2) hp-ux

3) solaris

4) tru64

5) linux

6) freebsd

Choose an operating system: 2

You chose hp-ux which was choice number 2

This code fragment also illustrates the bash echo command's -e option, which allows you to include backslash escape sequences such as \n.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

This section briefly describes other commands that you may encounter in system scripts.

The set command sets the values of $1 through $n to the words given as its arguments. It is often used with a backquoted command to assign the argument identifiers to the command's output. Here is an example of its use:

$ who -r 

.  run-level 2  Aug 21 16:58   2   0    S 

$ set `who -r` 

$ echo $6 

16:58

The unset command may be used to remove a defined variable.

The eval command executes its argument as a shell command. It is used to execute commands generated by multiple levels of indirection. Here is a silly example:

$ a=c; b=m; c=d; cmd=date 

$ echo $a$b$c

cmd

$ eval $`echo $a$b$c` 

Sun Jun  3 19:37:30 EDT 2001

Here is a real example that we looked at in Chapter 12:

$ eval `tset -sQ -m ":?vt100"`

This eval command runs the commands generated by tset -s. As we say, they are used to set the TERM and TERMCAP environment variables.

The command eval resize provides a similar example for xterm windows.

The printf command is used to produce formatted output strings, and you will occasionally see it used in system scripts. It takes two arguments: a format-specification string and a list of items to be printed using that format. Here is an example command used to create a record in a printer accounting file:

# pages=21; host=hamlet; user=chavez

# printf '%7.2f\t%s:%s\n' "$pages" "$host" "$user"

   21.00       hamlet:chavez

This command creates a line in which the number of pages is printed as a floating point number containing two decimal places, followed by a tab and then the hostname and username joined by a colon.

Format specification strings are comprised of field definitions and literal characters, and each successive item in the print list is formatted according to the corresponding field in the format string. In our example,

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsvorschau

Bourne shell scripts can define functions. Functions have all the same syntactic features as the scripts themselves, including their own arguments. Within a function, the argument and other shorthand forms refer to its own arguments.

The basic function syntax is:


            name (  ) 

{ 

   commands 

}

Here is a sample function from an AIX system, followed by an example of its use:

sserv(  ) 

{

# sserv: function to start a server

# args: $1=daemon pathname; $2!="" means use startsrc

# 

if [ $# = 0 ] ; then 

  echo "sserv: server name required."; return 1 

fi 

if [ ! -x $1 ] ; then return 1 ; fi 

if [ -n "$2" ] ; then 

   startsrc -s `basename $1` 

else 

$1 

fi 

} 

  

... 

  

sserv /sbin/syslogd $USE_SRC

The sserv function starts a server process on an AIX system, either conventionally from the command line or via the startsrc command (which uses the system resource controller subsystem, a general server management facility). The pathname of the server to start is specified as sserv's first argument, and whether to use startsrc is specified by the second argument (any non-null value uses it).

The function begins by making sure it was passed one argument; the function exits this is not the case. Note that return is used instead of exit in functions. Then the function makes sure the pathname it was passed is executable, and then finally it starts the daemon.

The example invocation of sserv uses an environment variable USE_SRC as its second argument. If USE_SRC is defined, then startsrc will be used; otherwise, only one argument will be passed to sserv.

bash functions may define local variables—variables whose scope is limited to the function and have no meaning in or effect on the script as a whole—via its local command, which takes the desired variable names as its arguments. Note also that any variables declared within a function are automatically local variables.

Ende der Inhaltsvorschau. Der weiterere Inhalt dieses Abschnitts ist hier nicht einsehbar.

Inhaltsverzeichnis

Section 3.1.1.1: Changing the search order

Section 13.2.1.1: The system default printer

Themen

Buchreihen

Special Interest

International Sites