UNIX: The Complete Reference (2007)

Part III: System Administration

Chapter 14: Advanced System Administration

The information in this chapter is for more experienced system administrators. It is organized around two main topics: managing information storage and managing system services. While UNIX variants may handle user processes and interfaces differently, information storage and system services management is performed in the same manner across variants.

Managing information storage requires you to understand the layout of standard files and directories in the UNIX system, how files and directories are related to file systems, and the relation between file systems and storage media (such as hard disks).

Managing system services is important for maintaining a secure, properly working computer. System services described in this chapter include the Service Access Facility (SAF) and accounting.

Managing Information Storage

Most users see stored information on a UNIX system as a collection of files and directories, largely independent of particular devices or media. An administrator must view these files and directories as a set of file systems that are connected to storage media.

Storage Media and UNIX File Systems

A variety of storage media are now available for use on UNIX systems. The most typical storage devices are floppy disks, hard disks, cartridge or nine-track tapes, and CD-ROMs or DVDs.

Floppy Disks

Using floppy disks is the slowest, most inconvenient, and most expensive way to store data. Although floppies have become cheap, it normally takes boxes of them and hours of manually changing disks to do a complete backup. Standard 3–1/2″ floppy drives are extremely cheap, around $20 each, and as a result come installed in some small computer systems. If your computer does not have one, they are relatively easy to install. Because of their ubiquity, they’re great for exchanging small amounts of data via “sneaker net” (i.e., walking a disk between machines). If you plan to do a lot of backups onto a floppy medium, you should investigate some of the newer technologies that enable you to store 120 MB of data on a single “super-disk” by using a special floppy drive.

Hard Disks

Hard disk drives have continued to get larger and cheaper at a rate that just barely exceeds the normal UNIX System user’s need for more storage. Multigigabyte drives are common on desktops and laptops as well as high-end workstations and servers. Disk arrays on servers can bring the total drive capacity into the terabyte range. With today’s large disks and the capability to have many disks attached to a single processor, file management and system backup routines are especially important.

Cartridge Tapes

Some workstations are equipped with Quarter Inch Cartridge (QIC) tape drives. The tapes are relatively fast and are a potentially good choice for backups. There are a number of different tape sizes, ranging in storage space from megabytes to about 5 GB. Generally, but not always, a tape drive can read a tape written on a smaller (less dense) tape. Also, workstations and PCs usually use different format QIC drives, and some manufacturers differ in how they write data onto the tape, causing compatibility problems. However, QIC compatible drives are readily available and often used.

Exabyte type, or eight-millimeter (8-mm), cartridge tapes use the small-size videotape standard. These drives are fast and, using compression, hold up to 7 GB, enabling an easy backup of most systems. They are the workhorse of tapes on many processors and have virtually replaced the floppy as the lowest common denominator for a distribution medium. Newer-format 8-mm tapes, called AIT (Advanced Intelligent Tape), have a capacity of up to 50 GB of compressed data.

If you want to perform backups on any of these formats of cartridge tapes, you will need to check with vendors about which tape devices and drivers (to manage the tape device) are available for your computer. While newer technologies like VXA Packet Technology allow any SCSI cartridge to be recognized as an st device under Linux, it may be necessary-if you know how-to recompile the kernel if no appropriate drivers are included with your system.

Nine-Track Tapes

Historically, most minicomputers, and therefore most UNIX System computers, were equipped with nine-track tape drives. Less than 15 years ago, a popular UNIX System administration book suggested that nine-track tapes were the best choice for backups. Today, however, they are obsolete. They are seen mainly in large, mainframe computer installations, and in the background of old movies and television shows. Nine-track tape drives are generally big, relatively expensive, hard to maintain, and relatively slow. At 1,600 bpi, a 2400-foot nine-track tape can only hold about 50 MB, and at 6,250 bpi, less than 200 MB. They process data at speeds up to 100 IPS (inches per second). So it takes about 288 seconds (a little less than 5 minutes) to read 200 MB of data. The only reason to have one is to be able to read old backup tapes. If you have these old tapes, you should be migrating them to newer media. The legacy of nine-track tape persists, anachronistically, in some UNIX System commands such as tar (tape archiver), which is used now to archive files to disk, cartridge tape, or CD-ROM/DVD.

DAT Tapes

Increasingly, computer manufacturers are providing DAT (Digital Audio Tape) drives in workstations and minicomputers. DAT tapes and drives for digital data applications are similar in appearance and function to audio DATs. These tapes use a format called DDS (Digital Data Storage). DDS2 cartridges are four-millimeter (4-mm) tape and are themselves very small; two of the cartridges are about the size of a deck of playing cards. The tapes can hold 4 GB of data in uncompressed form or 8 GB in compressed format. DDS3 cartridges hold even more data, with a compressed storage capability of up to 24 GB of data.

DLT Tapes

Users of systems that require backup of large volumes of data often use 1/2-inch DLT (Digital Linear Tape) tapes as the backup medium. DLTs use a concept of an enclosed single-reel tape that is loaded similarly to the original externally mounted tape reels but is much more reliable. These tapes are relatively fast and can store up to 70 GB of data in compressed format. Current technology allows multiple tapes to be loaded in units across a network, each of which can be loaded or unloaded via a central mechanism.

Writable CD-ROMs and DVD Writers

Writable CD-ROM devices are available in a number of formats and styles. They provide a popular way to permanently store large amounts of data. Once a CD-ROM is written using a write-capable drive, the disks can be read by any normal CD-ROM drive, and they have the same capacity as a normal CD-ROM (about 600 MB). Therefore, one reasonable approach is to equip a network of machines with one write-capable drive and with several normal CD-ROM drives for a group to use. Blank compact discs are becoming relatively inexpensive, ranging between $1 and $5 per disc. Using rewritable CDs lowers the cost of backup storage even more, since they can be written to and reformatted hundreds of times with no problems. The drives that are available today write much faster than they did a few years ago but still are much slower than the normal read capability They are most suited for archival storage of important data but are also effective for distribution of large amounts of data to a small number of users (for instance, large digitized image and audio files).

DVD writers, while more expensive than CD-ROM writers, store significantly more data (4.7 GB and up), and thus are worth the investment if you need to store large volumes of data frequently In addition, DVD players are backward-compatible and can play CD-ROM formats as well as DVD formats.

UNIX File Systems

Floppy disks, tapes, and CD-ROMs are portable media, generally used for installing software and backing up and restoring information. Although they can be used to store file systems, a system’s permanent file systems are generally stored on hard disk. Therefore, the description of the relationship between file systems and storage media will focus on hard disks.

When you receive your computer, the hard disks are probably already formatted into addressable sectors, called blocks, which are usually 512 bytes each in size. Once UNIX is installed, the disks are divided into sections or partitions, each of which contains some number of these blocks. Each file system is assigned one of these partitions as the area where information for that file system is stored.

Devices

The interface to each disk partition is through device-special files in the /dev directory General users never have to bother with a file system’s /dev interface. You should be aware of these device-special files if you are administering a system, however. Device names may be needed to do administrative tasks, such as changing disk partitioning and doing backups.

Hard disks are considered block devices: They read and write data of fixed block sizes, typically 512 bytes. However, there is usually a character (or raw) device interface as well as a block device interface. Character devices read and write information one character at a time. Some applications that access disks require a character interface. Others require a block interface.

Naming conventions for device names vary among UNIX systems. If you are not sure whether a device is a block or character device, you can use the file command, which tells you the type of file in question, such as

#file sbusmem@1, 0:slot1

sbusmem@1, 0:slot1 character special (69/1)

Block devices start with the letter b, and character devices begin with the letter c. On some UNIX systems, block and character (raw) devices for disks are separated into the /dev/ dsk and /dev/rdsk directories, respectively There is also a convention to provide more English-like names for these devices (such as disk1, ctape1, diskette1, or CDROM1) so that you don’t need to remember the more complex naming structures (such as c0t6d0s0) when accessing a device.

File System Structure

Each block in a file system, from block 0 to the last block on the partition, is assigned a role. Early UNIX systems would support one type of file system; thus, the layout of each partition would be the same across the entire system. With the growth of UNIX variants, however, different file system types are supported by the different implementations of file systems.

The Linux File System Type

Linux uses about a dozen file system types. The most common is the ext2 file system, which is the standard one. It supports both large file sizes and large filenames. Some of the more often used ones include the msdos file system (used for MS-DOS file partitions), the vfat and ntfs file systems (used for Windows 98/NT files), the proc file system (used for system processes), the NFS file system (used for remote mounting), the swap file system (used for swap partitions and swap files), and the sysv file system (used for System V files).

The s5 File System Type

Some UNIX variants (such as UnixWare) use the s5 file system. The layout of the s5 file system will help you understand how file systems are structured.

The first block (block 0) of an s5 file system is the boot block (used for information about the boot procedure if the file system is used for booting). Block 1 contains the super block (used for information about the file system size, status, its inodes, and storage blocks). The rest of the blocks are divided between inodes (containing information about each file in the file system) and storage blocks (containing the contents of the files).

Besides the s5 file system type, two other file system types are available for UNIX variants: the bfs and ufs file system types.

The bfs file system is a special-purpose file system, containing the file needed to boot UNIX. The ufs file system is particularly suited to applications that operate more efficiently writing larger blocks of data (i.e., larger than 512 bytes).

As a result of having different file system types on the same system, every command that applies to a file system has been enhanced. For example, the mount, volcopy, and mkfs commands have been changed to accept options to specify the type of file system to mount, copy, or create. As new file system types are created, new options to commands for manipulating the file systems will be added.

The Solaris File System Type

The most commonly used file system in Solaris is the ufs file system. This file system structure is a more complex structure than the s5 file system. It is usually defined as the default file system type in the system file /etc/default/fs. File systems under Solaris are normally created using the mkfs command, but ufs file systems can also be created using the newf s command. For example, if you wish to create a ufsfile system on the raw device /dev/rdsk/c0t0d0s5, you could either use mkfs as follows:

mkfs -F ufs /dev/rdsk/c0t0d0s5

or use the newfs command:

newfs /dev/rdsk/c0t0dos5

The newfs command actually uses the mkfs command to create the file system. In the previous examples, the ufs file system will be created with system defaults for blocking, size, and other options. These options can be specified at creation time. Use the man page for the newfs command to review the options and their functions before you attempt to do this, though, to avoid creating an unusable file system.

The HP-UX File System Types

HP uses a file system structure called HFS (High-Performance File System), not to be confused with the Linux HFS (Hierarchical File System). This structure was based on System V Release 4, and thus the file system type structures look very similar. In fact, most directories that are used for systems management are used in the same way on both systems (see Chapter 3 for a comparison of tree structures). HP-UX also uses a file system called vxfs (VERITAS File System), which is a 64-bit implementation of a journaled file system, (one that tracks and logs file system activity in the event of a system crash) one that provides higher file system integrity than other file system managers, as well as quick recovery in the event of a file system failure.

CD-ROM File Systems

Many newer UNIX systems use CD-ROM-based file systems as well as disk-based ones. The standard CD-ROM file system structure conforms to the ISO 9660 standard and is used by all the variants by default. Some additional formats are supported by some of the variants, though. In particular, Solaris and Linux can handle CD-ROMs that follow the High Sierra, Joliet, and Rockridge formats. These formats are an extension of the ISO 9660 standard that resolve format, filename length, and other ambiguities in the existing standard. Other CDROM read/write formats based on ISO 9660 are being developed currently

If you are planning to use a CD-ROM as either a mass storage device or a mounted device to read information from or write information to, you should make sure that your operating system environment supports the data formats of the file systems that you plan to mount on your CD-ROM. If you want more information concerning CD-ROM compatibility, access the comp.publish.cdrom newsgroup. Many other newsgroups under this area discuss CD-ROM hardware and software compatibility. There is also a good web site that describes the ISO 9660 standard and its extensions at http://www.disctronics.co.uk/cdref/cd-rom/iso9660.htm.

DVD-ROM File Systems

DVD-ROMs use the udf (Universal Disk Format) file system. udf is another file system that conforms to the ISO 9660 standard. It was developed initially as a solution to replace the CD-ROM specifications, but it has since grown in features to make it ideal for use in DVDs as well. As the amount of data that needs to be backed up continues to grow, DVD-ROMs are increasingly becoming the media of choice on which to store backups.

A number of commercial software vendors offer packages that allow creation of data, audio, and video onto DVDs, such as Roxio and Nero. In addition, there are other versions of DVD backup software that allow UNIX systems to be backed up, such as Microlite’s BackupEDGE software that works with Panasonic’s DVD-RAM (a new technology combining DVD-ROM capability and tape backup functionality). For more information, see Microlite’s page at http://www.microlite.com/.

Managing Storage Media

In most cases, by the time the UNIX System is installed on your computer, the hard disk is already formatted, partitioned (using default sizes), and divided up among the standard file systems (such as /, /usr, /etc). In some cases, though, you can define the amount of disk space allocated to each of the file systems. Installing Linux (see Chapter 6) is an example of a ground-up definition of file system allocation. In general, it’s a good idea to think about how you are going to use the system before you assign file systems to physical devices, so that you don’t have to move file systems from disk to disk to gain more space.

The computer is also configured to mount each file system (that is, make it accessible for use) when you enter either single- or multiuser mode. When you start up the machine, the entire UNIX system directory structure will be available for you to use.

You may not need to do anything to your storage media to have a usable system. However, you may find that you want to add a new hard disk; use floppy disks, tapes, or CD-ROMs for data storage; or change the partitioning assigned to your file systems. The following sections will describe the commands that will help you format the media to accept data and create and mount file systems.

Formatting a Floppy Disk

Before it can be used to store data, a floppy disk must be formatted. Here is a Linux example of how to format a 1.44-MB floppy that is referred to as /dev/fd0 on your system:

# mkfs -t ext2 /dev/fd0 1400

The -t option specifies that the ext2 file system is to be used for the floppy. If an error occurs, the floppy may be defective. The device is a character-special device representing the entire floppy disk drive. (As noted earlier, device names can differ from one system to the next.) Once the floppy is formatted, you can mount it (see later on in this chapter). If you want to do a low-level format of a floppy in Linux, the fdformat command may be used instead:

# fdformat /dev/fd0

fdformat is also the command used to format a floppy under Solaris.

Formatting a Hard Disk

Hard disks are typically shipped from the manufacturer formatted for the system on which you intend to use them. This is done on a Solaris system, for example, via a command such as format as follows:

# format -d /dev/c1t1d0

This command will format the raw device file /dev/c1t1d0 with system defaults.

In most cases, however, before you can use a new hard disk on your system, you must add a volume table of contents (VTOC) to the disk. The VTOC describes the layout of the disk. The following is an example of a command for adding a VTOC to a new hard disk with the raw device name of /dev/rdsk/c0t0d0s0 onto your system. Once the disk is installed according to the hardware instructions, type the following command:

# fmthard /dev/rdsk/c0t6d0s0

The device is the character-special device representing the entire hard disk drive. (You may initially want to run the command with the -i option to view the results before writing the VTOC to the disk.) It is important to note that you must first run the fdisk command on a drive if you are formatting it on an X86-based computer.

In Linux, you don’t actually format the hard drive (unless you are doing a low-level format), but rather the partitions on the hard drive. Use the mkfs command like this:

# mkfs -t ext2 /dev/hda0 4000

This will define the first disk partition as an ext2 type file system with 4000 blocks. You may then define subsequent partitions similarly, depending on the size and file system format you want for each of them. Linux also supports the mkfs.ext2 command to partition an ext2 type file system.

Other variants also use the mkfs command with different options. For example, whereas Linux uses the -t option for file system type, Solaris and HP-UX use the -F option.

Labeling a File System on Floppy Disk

Once a file system is created, you must label it. The label should be the directory pathname from which the file system is accessed. In the following example, the file system on the disk in drive 1 (/dev/fd0) is labeled /mnt.

# /etc/labelit /dev/fd0 /mnt

Current fsname: /mnt, Current volname: , Blocks: 1422, Inodes: 176

FS Units: 1Kb, Date last modified: Tue May 16 11:28:25 2006

NEW fsname = /mnt, NEW volname = -- DEL if wrong!!

Linux uses the e2label command to label ext2 or ext3 type file systems, so the equivalent command would be

# e2label /dev/fd0 /mnt

Mounting File Systems

Mounting is the action that attaches a file system to the directory structure. You can mount a file system directly from the shell or have the file system mounted automatically when your computer starts up. You might be more likely to mount a disk on demand using the mount command, whereas you might want a hard disk file system to be mounted automatically The directory that is to be associated with the device that you mount is known as the mount point.

To detach the file system from the directory structure, you must unmount it, using the umount command. If the file system was mounted automatically, then it will be unmounted automatically when you bring down the system.

Mounting a File System from Floppy Disk

Before you can use a floppy disk on a UNIX system, you must explicitly mount it with the mount command to a mount point. To mount a floppy disk on drive 1 (/dev/fd0) to the directory /mydir on a Linux system for example, you type the following command:

# mount /dev/fd0 /mydir

You could then cd to the /mydir directory and create or access files and directories on the floppy disk.

Mounting File Systems from Hard Disk

You can set up file systems to mount automatically when your system starts up by adding an entry to the /etc/vfstab file, or /etc/fstab for Linux. Following is an example of an /etc/vfstab file entry that automatically mounts /dev/c1t0s0s0 onto the mount point / (root):

/devclt0s0d0 /dev/clt0sd0 / ufs 1 yes

It is common for most of the normally used file systems to be automatically mounted at system startup (boot) to allow your users to access resources on them immediately In addition to commonly used disk file systems, you can mount other media, such as floppies, tapes, and CD-ROMs.

Mounting File Systems from CD-ROM

If you have a UNIX System workstation with a SCSI CD-ROM reader installed, you can manually mount the CD-ROM read/write as in the following example, which is for Solaris:

# mount -F hsfs -r rw /dev/dsk/cxtyd0sz /cdrom/cdrom0

where x is the CD-ROM drive controller number, y is the CD-ROM drive SCSI ID number, and z is the slice partition on which the CD-ROM is located.

File naming conventions differ across systems, so check your computer manual for the filename that corresponds to the CD-ROM drive on your machine. For example, the equivalent mount statement on Linux is

mount /mnt/cdrom

since the mount directory /mnt/cdrom is reserved for CD-ROM file systems on Linux.

System administrators may wish to write to CD-ROMs as the repository of system backup information. It is helpful to understand how file systems are created and managed on writable CD-ROMs. One of the most helpful ways to do this on Linux is to use the loopback device capability This block-device service enables you to mount a file as a file system, which then can be administered just like any other file system. You can write the information that you wish to write to the CD to this file system first. You can then view the structure of the file system before writing it to the CD-ROM. You can even perform encryption using a loopback file system.

Unmounting a File System from Floppy Disk

You can unmount a file system from a floppy disk on a Linux system, using the previous floppy mounting example, by unmounting either the raw device, as follows:

# umount /dev/fd0

or the mount point name, as follows:

umount /mydir

The file system will no longer be available to your computer. You can remove the disk. (Note that you cannot unmount a file system that is in use. A file system is in use if a user’s current directory is in that file system, or if a process is trying to read from or write to it.)

Unmounting a File System from Hard Disk

A file system that was set up in the /etc/vfstab or /etc/fstab to mount automatically will be unmounted when the system is brought down. However, if you want to temporarily unmount a hard disk file system, you can use the file system name to unmount the file system. For example, if the device /dev/c1t0d4s0 is mounted at mount point /dev/rdsk/c1t0d4s0 with the file system name /home, you can type

# umount /home

The umount command will get the information it needs about the device and its mount point from the /etc/vfstab or /etc/fstab file.

UNIX System Directory Structure

The locations of many standard administrative facilities have been changed in newer UNIX implementations as part of the change from a single-computer orientation to a networked orientation. This networked administration concept is described in the discussion of the UNIX file system in Chapters 15 and 17. Some of the basic file systems you should know about as a UNIX System administrator include /, /stand, /var, /usr, /etc, and /home.

The following sections contain general information about each of these typical file systems and a listing of important directories typically contained in each of them. You should list the contents of the directories described here and refer to your specific system administration manual to help answer any questions you may have about any of the administrative components. If you use Linux or Solaris, you may find that the file system structures are slightly different. While Solaris was based on System V Release 4, it sometimes places some system administration files (and-in some cases-user files) in different directories. However, the uses of these directories are the same. Linux uses a file system standard called the Linux FSSTND (File System Standard) (see “How to Find Out More” at the end of this chapter).

The root File System

The root file system (/) contains the files needed to boot and run the system. The following list shows some of the more important directories in the root file system.

A standard convention in UNIX is to limit information in /etc to information that is specific to the local computer. Each computer should have its own copy of this directory and would normally not share its contents with other computers.

These are some of the subdirectories of /etc and their contents:

§ /etc/cron.d contains files that control cron actives.

§ /etc/cups contains printer configuration files on Linux systems.

§ /etc/default contains files that assign certain default system parameters, such as limits on su attempts, password length, and aging.

§ /etc/init.d is a storage location for files used when changing system states.

§ /etc/lp contains local printer configuration files on non-Linux systems.

§ /etc/mail contains local electronic mail administration files.

§ /etc/rcX.d is an actual location for files used when changing system states; the X is replaced by each valid system state (e.g., rc3.d).

§ /etc/saf contains files for local SAF (Service Access Facility) administration for nonLinux systems.

§ /etc/save.d is the location used by the sysadm command to back up data onto floppies.

The /home File System

This is the default location of each user’s home directory. It contains the login directory and subdirectories tree for each user.

The /stand File System

This is the mount point for the boot file system, which contains the stand-alone (bootable) programs and data files needed to boot your system. This file system is not used for Linux, Solaris, and AIX systems.

The /usr File System

The /usr file system contains commands and system administrative databases that can be shared. (Some executables may only be sharable with computers of the same architecture.)

The /var File System

This file system contains files and directories that pertain only to the local computer’s administration and, therefore, would probably not be shared with other computers. In general, this file system contains logs of the computer’s activities, spool files (where files wait to be transferred or printed), and temporary files. These subdirectories are typically found under /var for most UNIX variants (Linux subdirectories may be different):

§ /var/adm contains system login and accounting files.

§ /var/cron contains the cron log file.

§ /var/lp contains log files of printing activity

§ /var/mail contains each user’s mail file.

§ /var/news contains news files.

§ /var/options contains a file identifying each utility package installed on the computer.

§ /var/preserve contains backup files for the vi and ex file editors.

§ /var/sadm contains files used for backup and restore services.

§ /var/saf contains log files for the Service Access Facility

§ /var/spool contains temporary spool files. Subdirectories are used to spool cron, 1p, mail, and uucp requests.

§ /var/tmp contains temporary files.

§ /var/uucp contains log files and security-related files used by Basic Networking Utilities (uucp, cu, and ct commands).

Managing Disk Space

Moore’s law says that available processing (CPU) power doubles every 18 months. There should be a similar law regarding the need for disk space. Early UNIX system computers were luxuriously appointed with 40 MB of hard disk space; in 1995 a large university announced the receipt of a 2-TB storage facility to use as a file server. In 2006, desktop computers typically have at least 40–100 GB drives, and many servers have 400 or more gigabytes. You can never have too much disk space. To make sure your system has enough disk space, you need to monitor file system usage, clean out unnecessary files, and anticipate when you’ll need more disk space.

Checking File System Usage

The UNIX System provides several commands that provide useful information about disk utilization. You can use them manually to keep an eye on disk usage, or include them in scripts that help automate disk space management.

The df (disk free) command reports how much disk space is available, how much is used, and how much is free. The specific format of the output varies among systems. For instance, the -b option (display blocks) is used in HP-UX to display output similar to that of the examples. On Solaris, the command df -k (display kilobytes) will display the usage and availability in kilobytes. Both locally and remotely mounted systems are listed by default:

# df

Filesystem Type blocks use avail %use Mounted on

/dev/root efs 1939714 1939648 66 100% /

/dev/dsk/c0t1d0 efs 2041377 1882315 159062 92% /disk2

/dev/dsk/c0t2d0 efs 2039847 2039847 0 100% /cdrom

Notice that this is a badly clogged system; root (/) has almost no space available, and most of the main disk is used. As expected, c0t2d0-a CD-ROM reader-has no space available.

The du command (disk usage) provides a report of the disk usage of a directory and all its subdirectories. The -s option provides the summary for every directory and the total, ignoring subdirectories:

# du -s /home/*

59598 /home/dwb

18423 /home/rosk

17 /home/boy

7867 /home/edna

4905 /home/lee

90810 ·

Clearly, user dwb is using most of the disk space on this machine.

File System Housekeeping

Since disk storage capability is much larger that it was in the early UNIX days, users tend not to think about how much space they are using on the system. You can prevent users (or more likely, runaway programs) from creating large files by using the limit command to restrict the size of files a user can create. For example,

# limit filesize 2m

will prevent a user from creating a file larger than 2 MB. You can also restrict the size of core dumps. This rarely affects nonprogramming users, since they don’t typically dump core and may not even realize that they have a core file in their directories. The command

# limit coredumpsize 0

will prevent all core dumps. Users of ksh and bash shells can use the command ulimit. For example,

# ulimit -c 1

will restrict core size to 1 block.

File systems can also grow via the proliferation of junk files: files created by some program, but which no longer serve a useful purpose. If someone is using the vi editor when either the system or the program comes down, the files being edited are placed in /var/preserve for later recovery. Users don’t usually know they are there, and the files remain until you clean them out. Since the space consumed by these files can become large over time, you should monitor them and periodically delete them. The following command line can be used to delete files in /var/preserve that haven’t been modified in seven days:

find /var/preserve -mtime +7 -exec /bin/rm {} 2>/dev/null \;

The UNIX System C compiler gives a default name of a.out to its output file. Most programmers rename the a.out file. When a program crashes, it may leave a core file useful for debugging. Both the a.out and core files should be periodically deleted:

find . \( -name a.out -o -name core \) -atime +3 \

- exec /bin/rm {} 2> /dev/null \;

Backup files created by various programs, or by users themselves, are often not needed for long, but they may persist. This command will delete backup files that have not been accessed in 72 hours:

find . \( -name '*.B' -o -name '#*' -o -name '.#*' -o \

-name '*.CKP' \) -atime +3 -exec /bin/rm {} 2> /dev/null \;

Be careful when doing this. It may be dangerous to make assumptions about how long users will expect their backups to persist.

Often users will create temporary files and leave them around. One convention suggested in this book for such temporary files is to use a common prefix or suffix (e.g., ps or .tmp) followed or preceded by the process number to get a unique filename, for example, ps1035 or 1035.tmp. The following command line searches for such files and deletes those that have not been accessed in seven days:

find . \( -name '*.tmp' -o -name 'ps*^' \) -atime +7 \

-exec /bin/rm {} 2> /dev/null \;

Before you use any of these commands, you should let users know about these naming conventions and the system housekeeping policy Before you run such commands, be sure that they will work the way you expect them to work. An important memo on our basic business named core would be deleted by one of the previous script, as would a file named psaltery in the previous one. One way to make sure these scripts will do what you expect is to replace the -exec command with the -ok command:

find . -name core -ok /bin/rm {} 2> /dev/null \;

This alteration makes the command line interactive. The generated command line is printed with a question mark, and it is only executed if you respond by typing y.

Once you’re satisfied with the actions of the scripts you have created, you can bundle these and similar commands together in a single shell script that is run as a cron job each day (see Chapter 11). Some administrators think that it is inappropriate to delete files that belong to someone else, unless you need to recover system space because your file systems are becoming full. As an alternative, you may wish to leave others’ files alone and enforce disk quotas (to be discussed later in this chapter). Excessive disk use is restricted, but users, themselves, decide which files to keep.

Handling System Log Files

If you’re monitoring disk usage, you’ll notice that system log files use up a lot of space. There are several of them, and they grow naturally with use of the operating system. For example, on a typical system, the files in /var/adm or /var/log alone can consume over several thousand blocks. It’s tempting to simply delete these log files and free up the space, but you shouldn’t do it. Log files provide you with the only audit trail for hardware, software, and security problems. If you suspect an intruder, you can enable loginlog (in /var/log in Linux) to capture unsuccessful login attempts. Rather than deleting these files, move them periodically and save them for a month or two before deleting them completely:

# ls -s /var/adm

total 6404 560 lastlog 2 sa 2 utmp

48 Osulog 304 lastlogin 520 spellhist 20 utmpx

2 acct 2 log 2 streams 4 wtmp

0 active 2 loginlog 14 sulog 26 wtmpx

14 dtmp 4 mailall.log 1520 syslog

0 fee 2 mailchk 3016 syslog.old

2 hola 336 pacct 2 usererr

# mv syslog.old syslog.old2

# mv syslog syslog.old

# cat /dev/null > syslog

# compress syslog.old*

Dealing with Disk Hogs

As with most publicly shared resources, people who grab more than their fair share will benefit more when compared to the rest of the group. When disk space is a free resource, some users decide they can’t archive or delete anything, and worse, decide to save copies of every interesting article they find on the Internet. Some of these users simply need to be reminded that they are using more than their share of disk space. The following script checks all the users with logins in /home and sends a gentle message to any that are using more than 80,000 blocks:

# find disk hogs

users='ls −1 /home'

limit=80000

for user in $users

do

diskuse='du -s /home/$user awk '{print $1}'

if [ $diskuse -gt $limit]

then

/usr/bin/mail $user <<!

Dear $user,

It is expected that users on this system keep

their disk usage below $limit blocks. You are

currently using $diskuse. Please delete any

unnecessary files and directories.

I can help you archive old files if you wish.

If you don't reduce your disk usage, your access to

the system may be reduced. Your Friendly System Administrator

!

fi

done

For people who ignore the hint, some administrators use a touch of public embarrassment. If you list the disk hogs in the message of the day, /etc/motd, their colleagues may pressure them to clean up their act and their disk space. The following alteration of the diskhog script will publish user logins of disk hogs:

# find disk hogs

# publish their logins in the

# system message of the day

users='ls −1 /home'

limit=80000

date='date'

echo "The following users are Disk hogs on today, $date," >> /etc/motd

echo "Each is using more than $limit blocks of disk space." >> /etc/motd

echo " " >> /etc/motd

for user in $users

do

diskuse='du -s /home/$user | awk '{print $1}' -'

if [ $diskuse -gt $limit]

then

echo $user >> /etc/motd

fi

done

Each user will see a message of the day such as this:

The following users are Disk hogs on today, Mon Jul 10 14:22:25 EDT

2006,

Each is using more than 80000 blocks of disk space.

krosen

jmf

If publication of the logins doesn’t exert enough pressure, change diskhog to provide the user’s name:

# find disk hogs

# publish their names and identities

# in the system message of the day

users='ls −1 /home'

limit=80000

date='date'

echo "The following users are Di skhogs on today, $date," >> /etc/motd

echo "Each is using more than $limit blocks of disk space." >> /etc/motd

echo " " >> /etc/motd

for user in $users

do

diskuse='du -s /home/$user awk '{print $1}' -'

if [ $diskuse -gt $limit]

then

whois $user >> /etc/motd

fi

done

The message of the day then looks like this:

The following users are Di skhogs on today, Mon Jul 10 14:22:25 EDT 2006,

Each is using more than 80000 blocks of disk space.

Name - K.ROSEN

Directory - /home/krosen

UID - 104

Name - J.FARBER

Directory - /home/jmf

UID - 103

If such embarrassment doesn’t work, you may have to take more intrusive action. You can enter the user’s directories and compress all files that haven’t been accessed in 30 days:

find . -atime +30 -exec /usr/bin/compress {} 2> /dev/null \;

Alternatively, you can lock the user out of the system by blocking the login in ways discussed earlier. Both of these actions are pretty extreme and should only be taken if the user is a genuine scofflaw. Altering someone’s files or locking their login may have terrible consequences for the user.

Using File Quotas

If gentle reminders, peer pressure, and police action don’t keep users behaving responsibly, you may want to implement disk quotas to enforce limits on the user’s use of disk space. Quotas allow you to establish limits on the number of disk blocks and inodes allowed to each user. (Inode limits roughly restrict the number of files a user may have.) Quotas are enabled on a per-file system basis.

The quota and repquota commands are used to display quota settings.

# quota -v rrr

will display the user’s quotas on all mounted file systems, if they exist.

# repquota filesystem

prints a summary of all the disk usage and quotas for the specified file system. Each quota is specified as both a soft limit and a hard limit. When a user exceeds his soft limit, he gets a warning but can continue to use more storage. While the soft limit is exceeded, the user receives a warning each time he logs in. The hard limit can never be exceeded. For example, if saving a file in an editing session would cause the hard limit to be exceeded, the save will be denied. At this point, little useful work can be done until the user cleans up. To prevent users from disregarding the soft limit warnings, the user only has a fixed number of days (the default is three days) for which to exceed the soft limit. After that time, the system will not allocate any more storage. Again the user must clean up files to a level that is below the soft limit in order to get any work done.

Setting File Quotas The parameters for the quota system are kept in the quotas file in the root of each file system. quotas is a binary file that is periodically updated by the UNIX System kernel to reflect file system utilization. To alter existing quotas for user rrr, you use the edquota command:

# edquota rrr

The edquota command creates a temporary ASCII file and invokes an editor on it. The $EDITOR environmental variable is checked, and vi is used as a default. Hard and soft quota limits are displayed on a single line for both disk blocks and inodes. In an initial setup for a user, both block and inode limits will be set to 0, meaning there is no quota. Edit the value to whatever limits are appropriate for disk blocks and inode numbers. The -p (prototypical user) option for edquota allows you to duplicate quotas across several users. The command

# edquota -p abc rrr khr jmf lsb jed

uses the quota settings for user abc as a prototype for the other users in the command line. This provides an easy way to provide consistent quotas for different groups of users. Exit the editor, and edquota adds your entry to the quotas file. To make sure that your settings are consistent with current usage, run the command

# quotacheck filesystem

quotacheck examines the file system named by filesystem, builds a table of current disk usage, and compares it to data in the quotas file.

Enabling File Quotas Most current UNIX systems are shipped with quotas already installed. On these systems, you can enable or disable quotas on a specific file system with the command

# quotaon filesystem

The command quotaon -a will enable quotas on all file systems in /etc/mnttab (or /etc/mtab for Linux) marked read/write with quotas.

In similar fashion, the command

# quotaoff filesystem

will disable the quotas on filesystem. quotaoff -a will disable quotas on all file systems in /etc/mnttab (or /etc/mtab for Linux).

Linux administrators can set quotas as part of the Linux PAM (Pluggable Authentication Modules), so that users have predefined quotas when their user logins are created. See Chapter 12 for more information on setting user restrictions.

Backup and Restore

Backup and restore procedures are critically important. They protect you from losing the valuable data on your computer.

Backup is a procedure for copying system data or partitioning information from the permanent storage medium on your computer (usually from a hard disk) to another medium (usually a removable medium such as a floppy disk or a tape). Partitioning information describes the different areas on the disk on which different kinds of data are stored. Restore is a procedure for returning versions of the files, file systems, or partitioning information from the backup copy to the system.

A good backup strategy will ensure that you will be able to get back an earlier version of a file if it is erased or modified. It will also enable you to restore system configuration files if they are damaged or destroyed.

You can be very selective about what you back up and how you do backups. For example, you can back up a single file, a directory, a file system, or a data partition. Depending on how often data on your system changes, how important it is to protect your files, and other factors, you can run some form of backup every day once a week, or once in a while.

Approaches to Backup/Restore

Several different approaches are taken to doing backups and restores. This section describes two of them.

The first is to do occasional backups. The amount or type of information on your system may not require backups at regular intervals. Instead, you may want to create backup copies of individual files, a directory structure of files, or an entire file system on occasion. The cpio and tar commands are used to gather files and directories by name and copy them to a backup medium. The volcopy command can be used to make a literal copy of an entire file system to a backup medium.

The second approach is to set up a regular schedule of backups. Though this has typically been done using the commands outlined in the preceding paragraph, most UNIX variants offer a backup and restore facility that is intended to help structure regular backups. That facility is described later.

cpio Backup and Restore

The cpio command was created to replace tar (tar is an early UNIX system command created for archiving files to tape). cpio’s major advantage over tar is its flexibility

The cpio command accepts its input from standard input and directs its output to standard output. So, for example, you can give cpio a list of files to archive by listing the contents of a directory (ls), printing out a file containing the list (cat), or by printing all files and directories below a certain point in the file system (find). You can then direct the output of cpio, which is a cpio archive file, to a floppy, a tape, or another medium, including a hard disk.

cpio Modes of Operation

The cpio command operates in three modes: output mode (cpio -o), input mode (cpio -i), and passthrough mode (cpio -p).

Output Mode (Backup) You give cpio -o a list of files (via standard input) and a destination (via standard output). cpio then packages those files into a single cpio archive file (with header information) and copies that archive to the destination.

Input Mode (Restore) You give cpio -i a cpio archive file (via standard input). cpio then splits the archive back into the separate files and directories and replaces them on the system. (You can choose to restore only selected files.)

Passthrough Mode The cpio -p command form works like the output mode, except that instead of copying the files to an archive, it copies (or links) each file individually to another directory in the UNIX System file system tree. With this feature, you can back up files to another disk or to a remote file system mounted on your system. To restore these files, you can simply copy them back using the cp command.

cpio Examples

The following illustrates a few examples of cpio that you may find helpful. The examples show how to use cpio to copy to a floppy disk, copy from a floppy disk, and pass data from one location to another. See your System Administrator’s Reference Manual for a complete listing of cpio options.

cpio Backup to Floppy This example uses the find command to collect the files to be copied, gives that list of files to cpio, and copies them to the floppy disk loaded into disk drive 1, here /dev/fd0. For example,

# cd /home/mcn

# find . -depth -print cpio -ocv > /dev/fd0

This command line says to start with the current directory (.), find all files below that point (find command), including those in lower directories (-depth), print a list of those files (-print), and pipe the list of filenames to cpio (|). The cpio command will copy out (-o) those files, package the files into a single cpio archive file with a portable header (-c), print a verbose (-v) commentary of the proceedings, and send it to the disk in drive 1.

Note that the find was done using a relative pathname (.) rather than a full pathname (/home/mcn). This is important, since you may want to restore the files to another location. If you give cpio full pathnames, it will only restore the files to their original location.

cpio Restore from Floppy To restore files from a floppy disk, as an example from the previous backup to floppy disk, you can change to the directory on which you want them restored and use the cpio -icommand. For example,

# cd /home/mcn/oldfiles

# cpio -ivcd < /dev/fd0

This will copy in the cpio archive from the disk in drive 1, print a verbose (-v) commentary of the proceedings, tell cpio that it has a portable header (-c), and copy the files back to the system, creating subdirectories as needed (-d).

cpio in Pass Mode The following example uses cpio -p to pass copies of files from one point in the directory structure to another point. In this case, all files below the point of a user’s home directory will be copied to a remote file system that is mounted from the /mnt directory on your system using Remote File Sharing:

# cd /home/mcn

# find . -depth -print | cpio -pmvd /mnt/mcnbackup

Exact copies of all files and directories below /home/mcn are passed to the /mnt/mcnbackup directory, the time the files were last modified is kept with the copies (-m), a verbose listing is printed (-v), and subdirectories are created as needed (-d).

As you become familiar with cpio, you should refer to the cpio(1) manual pages in the your System Administrator’s Reference Manual for other options to cpio.

tar Backup and Restore

The tar command name stands for tape archiver. Because of its widespread use before cpio existed, tar has continued to evolve into a powerful, general backup and restore utility that is still supported in most UNIX variants. (The use of tar in anonymous ftp is described in Chapter 9.)

Like cpio, tar can back up individual files and directories to different types of media. As discussed previously, you can mount a directory to which you want to back up data, perform a backup using tar, and later restore those files from the directory that you mounted to back them up. The examples in this section, however, show how to back up files to cartridge tape. Cartridge tapes are the most effective media for backups, since they can be removed from the machine they are backing up and stored at another site.

tar Backup to Tape

The following example shows how to back up from the file system to a 4-mm cartridge tape that is defined as /dev/rmt0 by using tar:

# cd /home/mcn

# tar -cvf /dev/rmt0

In the example, tar reads files from the current directory (.) and all subdirectories, prints a verbose (-v) commentary of the proceedings, packages the files into a single tar archive file, and sends it to the cartridge tape (/dev/rmt0).

tar Restore from Tape

The following example shows a restore to the system from a tar archive on the same 4-mm cartridge tape used in the previous example:

# cd /home/mcn/oldfiles

# tar -xvf /dev/rmt0

Here, tar restores the files from the tar archive on the cartridge tape in /dev/rmt0 to the current directory (.). It creates subdirectories as needed and prints a verbose commentary (-v). Note that since the files were stored using a relative pathname (the dot standing for the current directory), they can be restored in any location you choose.

Refer to the tar manual page in your System Administrator’s Reference Manual for other options to tar.

Backup and Restore Facility

The backup and restore facility was designed to structure backup and restore methods. In earlier UNIX versions, each administrator would set up individual cpio, tar, or volcopy command lines with various options to run backups at different times. The new strategy for backups centers around the use of backup tables.

Each entry in a backup table identifies a file system to be backed up (originating device), the location it will be backed up to (destination media), how often the backup should be done (rotation), and the method of backup (full or incremental type). When the backup command is run interactively, in the background, or using cron, it picks up those entries that are ready for backup and runs them.

The restore facility helps administrators restore the backup files to the system as required. The facility also includes a method of handling user requests for restores. You can request several different types of backup with the new backup and restore facility

Full File Backup With this type of backup, you will back up all files and directories from a particular file system.

Full Image Backup With a full image backup type, you will back up everything on a file system byte for byte. This is faster than a full file or incremental backup; however, you have to replace it on an extra disk partition of the same size to restore files from this type of backup.

Incremental File Backup Using incremental file backup, you are only backing up files and directories that have changed since the previous backup. A set of backups for a particular period will consist of a full backup and zero or more incremental backups that would modify that full backup over that time period.

Full Disk Backup This method copies the complete contents of the disk. With a backup of this method, you will be able to restore an entire disk, if need be, including files needed to boot the system.

Full Data Partition Backup This method is valuable if you are backing up a data partition that does not store its data as a file system. To restore this type of file system, you would have to replace the full data partition, instead of individual files and directories.

Migration Backups You may find it convenient to run one type of backup originally and then migrate that backup to another medium later. This is called a migration backup.

Backup Plan

Successful backups require that you develop a backup plan, create backup tables to define which backups to run and when, and actually run the backups. Though the example procedure that follows may not suit your needs exactly, the approach outlined here should serve as a guide to setting up your backup procedure. You should become familiar with the backup and restore operations for your particular system before attempting to build any mechanized facility to do so.

Backing Up Data Using ufsdump

The following sections describe a system backup using ufsdump under Solaris as an example. System backups for other UNIX variants can be performed using similar techniques and strategies. For this procedure, a backup plan for a computer with one hard disk and a cartridge tape drive was executed. A tape drive (QIC, DLT, or DAT), or at least a write-capable CD-ROM, is necessary for all except the smallest incremental backups. Floppy disks are satisfactory only for small systems, or for minor backups.

Evaluate the System

The first step is running the df -t command. The output from this command is a listing of the file systems on the computer, the amount of data in each file system, and the number of files in each file system. The total line for each shows the total number of blocks and files available for the file system. For example,

#df -t

/ (/dev/root ): 3620 blocks 1117 files

total: 17008 blocks 2112 files

/proc (/proc ): 0 blocks 182 files

total: 0 blocks 202 files

/stand (/dev/dsk/c1d0s3 ): 2431 blocks 41 files

total: 5508 blocks 48 files

/var (/dev/dsk/c1d0s8 ): 3332 blocks 896 files

total: 10044 blocks 1248 files

/usr (/dev/dsk/c1d0s2 ): 17980 blocks 7697 files

total: 96064 blocks 12000 files

/home (/dev/dsk/c1d0s9 ): 6368 blocks 755 files

total: 6640 blocks 800 files

You could decide to do a full backup of the root (/) file system when the software is installed, and then back up only the /var, /usr, and /home file systems on a regular basis. Once the system is installed, you will want to be able to restore a working copy of the root file system, in case parts of it are damaged. (It is easiest to just do a full backup one time using the cpio command as described previously in this chapter, and bypass this facility)

Other file systems, /var, /usr, and /home, may change frequently as users do their work. So a full backup of these systems once a week and an incremental backup every day would be best.

Define a Backup Strategy

How often should you back up your system? The answer depends on how often significant changes are made in files on your system-changes that you would not want to lose in the event of a crash.

For a lightly used, single-user system, the following backup strategy may be sufficient: On the first day of the week, make a full system backup (starting at /). At the beginning of each day make a backup of only those files that have been modified on the previous day If your system crashes on Thursday, you could recover by restoring the complete system from the Monday backup, and the modified files from the Tuesday and Wednesday backups. For most users, the complete backup would involve a tape cartridge, but the incremental backups could be done to a single floppy each day If you wish to use only one media type, use a cartridge tape for both weekly and daily backups. On the first day of the second week, do a full backup to a new tape, plus the daily modified backups. On the third week, recycle the first tape for a new full backup and recycle the first set of modified backup disks or tapes as well.

A more permanent strategy, one that allows weekly and monthly archiving, can be created with a few more tapes. On the first day of each week make two full backups, and remove one to off-site storage. If you have a flood or fire, you’ll have one safe copy Each day of the week, make backups of the modified files. After two weeks, reuse the modified backup tapes. After two months, retain the first full backup of the month off-site, and reuse the tapes from the second, third, and fourth weeks of that month. Over time, your off-site archive should contain a full monthly backup for every month, and one full weekly backup for the last month’s worth of files. On site you’ll have a full weekly backup and daily modified file backups for the current week only

Create a Backup Table

Solaris provides the capability to create backup table entries. The contents of a backup table consist of a number of lines identifying the mount point(s) of the file system(s) to be backed up, as well as a flag used to identify the last file to be backed up in a full backup procedure.

The ufsdump Command

ufsdump backs up all files specified (normally either a complete file system or files within a file system modified after a certain date) to a specified backup medium (magnetic tape, diskette, disk, CD-ROM, etc.)- When running ufsdump, the file system must be inactive; otherwise, the output from ufsdump may be inconsistent and restoring files correctly using ufsrestore may be impossible. A file system is considered inactive when it is unmounted or the system is in single-user mode. The ufsdump command (normally located in /usr/sbin) is in the format

# ufsdump [options [arguments]] files

The options consist of a string of one-character letters (or number for the dump-level) that define things such as the type of dump, the medium to dump to, the size of the dump in 512-byte blocks, and other qualifying details. If an option has an argument, the argument value is ordinal, meaning values follow the string of options according to the order the options are given. The last item, files, is the list of files or file system to be backed up. For example, to perform a full backup (level 0) of the root file system on c0t3d0, onto a 150 MB cartridge tape, unit 0, update the dump record (in /etc/dumpdates), and verify the results against the original input, you would use the following command:

# ufsdump 0cfuv /dev/rmt/0 /dev/rdsk/c0t3d0s0

If no options or arguments are given to ufsdump, the default command format becomes

# ufsdump 9fu /dev/rmt/0 files

This would do an incremental dump (level 9) of the files or file system specified in files, update the dump record in /etc/dumpdates, and write the dump to the device /dev/rmt/0, the 150-MB cartridge tape, unit 0.

It may be useful to know how large your backup is going to be, so that you can plan on having the appropriate number (and right type) of media on hand. To see the size of the file or file system file to be backed up, use the command

#ufsdump S file

The S option will list out the size in bytes. You can then use this number to calculate the required media. For example, if the number returned were 72264750, you could calculate that the roughly 70 MB this represents would fit comfortably on a 150-MB QIC cartridge tape.

For a complete set of options for ufsdump, their meanings and usage, refer to the Solaris System Administrator’s Guide. You can also find information on the web under the term “ufsdump.”

Restore Plan

Every system administrator hopes that the backup process is precautionary, and that incremental and full backups will ensure that nothing will compromise the integrity of stored data. However, if something happens to that data, you now are faced with the reality that your backups are your only source of restoring critical data. Just as you have a backup plan and backup strategy, you should have a restore plan and a restore strategy This will ensure that you recover the correct amount of data from the appropriate backup. The system administrator should have a well-maintained library of backup media that are properly labeled, as well as an up-to-date /etc/dumpdate file. Using these two together will allow the administrator to decide what media are appropriate to correct the data loss problem.

Restoring Data Using ufsrestore

The ufsrestore command is used to restore files from a backup medium that has been created using ufsdump. The ufsrestore command is of the format

# ufsrestore [options [arguments]] filename …

where options are a combination of required options and other additional options, arguments can be given to the additional options in an ordinal manner similar to ufsdump, and filename is the name of the file or directory to be restored from the backup medium. The required options are listed in Table 14–1. One (and only one) of these options may be used for each invocation of the ufsrestore command.

When invoked with the interactive (i) option, ufsrestore allows the administrator to interactively decide which files to add or delete from the restore operation by looking at the contents of the media in real time, so that the command

#ufsrestore i /dev/rmt/0

will open up an interactive command session to administer the contents of the mounted cartridge tape /dev/rmt/0, from which you are trying to restore files. Once in the interactive command mode, you can enter help to see a list of the commands that are available.

The additional, nonrequired options provide file location, conversion, and reporting capabilities for ufsrestore. One of these options, the s option, is very useful after you have run ufsrestore with the t option to determine what files are on the medium. If you need to restore just a particular file, and it is the nth file from the beginning of the medium, you can run ufsrestore as follows:

#ufsrestore xfs /dev/rmt/0 5

This command will skip to the fifth file on the restore medium /dev/rmt/0 and extract (restore) the file at that position on the medium. To restore all of the files on the cartridge tape (full restore) and display all of the files being restored using the verbose (v) option, type

#ufsrestore rvf /dev/rmt/0

For a complete set of options for ufsrestore, their meanings and usage, refer to the Solaris System Administrator’s Guide. You can also find information on the web under the term “ufsrestore.”

Restore Strategy

One of the most difficult decisions you will need to make in restoring data is exactly how much data to restore. If you choose to restore everything, you may be wasting time. If you choose to restore specific files, you have to make sure that you have all of the affected ones. The best thing to do is to sit down and analyze the problem. What were the symptoms leading up to the decision to restore? Was there a power outage? Did you or a user accidentally remove a file or files, or-worse yet-an entire file system? Can you determine when this happened? The goal is to identify the best point from which to restore your data. In a heavily used system, you may only need to go back to the last incremental daily backup. In other cases, you may need to go back to the last full backup. One thing that you don’t want to happen is that you restore too many files with older data than is necessary It takes time to get a feel for all of this. Using other resources available to you as a system administrator in defining your restore strategy will help you as much as having a backup plan did when you first backed up your data.

Managing System Services

Most of the basic software services available on UNIX systems, such as the print service, networking services, or user/group management, require some form of administration. Two important areas of administrative system services described here are the Service Access Facility and accounting utilities. The Service Access Facility came about to help standardize how services available to terminals, networks, and other remote devices are managed on each system and across different packages of software services. Accounting utilities are used to track system usage and, optionally charge users for that usage.

Service Access Facility

The Service Access Facility (SAF) was designed to provide a unified method for monitoring ports on a UNIX system and providing services that are requested from those ports.

A port is the physical point at which a peripheral device, such as a terminal or a network, is connected to the computer. The job of a port monitor is to accept requests that come into the computer from the peripherals and see that the requests are handled.

The port monitor that is used most frequently is called ttymon. To see if this or other port monitors are installed on your system, you can use the sacadm command. Type the following command to see results like these:

# sacadm −1

PMTAG PMTYPE FLGS RCNT STATUS COMMAND

ttymon1 ttymon - 2 ENABLED /usr/lib/saf/ttymon #ttymon1

ttymon3 ttymon - 2 ENABLED /usr/lib/saf/ttymon #ttymon3

This example shows that there are two instances of ttymon on the system.

Terminal Port Monitor

The ttymon port monitor listens for requests from terminals to log in to the system. In the previous example, each instance of a ttymon port monitor command (/usr/lib/saf/ttymon) has a separate tag identifying it (ttymon1 and ttymon3) and is started separately by the Service Access Controller (sacadm daemon) when the system enters a multiuser state.

Each port monitor instance will run continuously, listening for requests from the ports it is monitoring and starting up processes to provide a service when requested. To see what services are provided and what ports are being monitored by a particular port monitor instance, type

# pmadm −1 -p ttymon1

PMTAG PMTYPE SVCTAG FLGS ID <PMSPECIFIC>

ttymon1 ttymon 11 u root /dev/term/11- - /usr/bin/login

- 9600 - login:-tvi925

ttymon1 ttymon 12 u root /dev/term/12 - - /usr/bin/login

- 9600 - login: -tvi925

ttymon1 ttymon 13 u root /dev/term/13 - - /usr/bin/login

- 9600 - login: -tvi925

ttymon1 ttymon 14 u root /dev/term/14 - - /usr/bin/login

- 9600 - login: -tvi925

The ttymon1 port monitor monitors all four ports on the ports board in slot 1 on the computer (/dev/term/11 through /dev/term/14). The service registered with ttymon1 is the login service (/bin/login). When a user turns on the terminal connected to port 11, the user receives the “login:” prompt and terminal line settings are defined by the 9600 entry in the /etc/ttydefs file.

The ttymon port monitor replaces the previous getty and uugetty commands from earlier versions of UNIX. Unlike the getty and uugetty commands, a single ttymon monitors several ports, so you do not need a separate process running for each port. Also, ttymon lets you configure the types of services you can run on each terminal line, using pmadm -a. These can include, for example, adding STREAMS modules to STREAMS drivers and configuring line disciplines for each port.

Service Access Controller

The process that starts SAF rolling is called the Service Access Controller. By default, it is started in each system from this line in the /etc/inittab file:

sc:234:respawn:/usr/lib/saf/sac -t 300

The sac process starts when you enter the multiuser state; it reads the SAF administrative file to see which listener processes to start (see the sacadm −1 command shown previously for an example of the contents of this file) and starts those processes.

Configuring Port Monitors and Services

The SAF provides a robust set of commands and files for adding, modifying, removing, and tracking port monitors and services. These SAF features enable you to create your own port monitors and add services to suit your needs. Since creating port monitors and device drivers can be quite complex, you should read the network administration sections in your administration manual to help create your own SAF facilities.

Configuration Scripts Typically three types of configuration scripts can be created to customize the environment for your system, a particular port monitor, or a particular service, respectively:

§ One per system The /etc/saf/_sysconfig configuration script is delivered empty It is interpreted when the sac process is started and is used for all port monitors on the system.

§ One per port monitor A separate /etc/saf/pmtag/_config file can be created for each port monitor (replace pmtag with the name of the port monitor) to define its environment.

§ One per service A separate doconfig file can be created for each service to override the defaults set by other configuration scripts. For example, you could push different STREAMS modules onto a STREAM.

Administrative File There is one administrative file per port monitor. You can view the contents of the files using the pmadm −1 command, as shown earlier.

Services You can manipulate services by

§ Adding a service to a port monitor (pmadm -a)

§ Enabling a service for a port monitor (pmadm -e)

§ Disabling a service for a port monitor (pmadm -d)

§ Removing a service from a port monitor (pmadm -r)

Port Monitors You can manipulate port monitors by

§ Adding a port monitor (sacadm -a)

§ Enabling a port monitor (sacadm -e)

§ Disabling a port monitor (sacadm -d)

§ Starting a port monitor (sacadm -s)

§ Stopping a port monitor (sacadm -k)

§ Requesting port monitor information (sacadm −1)

§ Removing a port monitor (sacadm -r)

Other options enable you to perform additional administration on the port monitor. See your system administration and network administration manuals for these on your system.

Accounting

Accounting is a set of add-on utilities available on many computers running UNIX. Its primary value is that it provides a means for tracking usage of your system and charging customers for that usage.

The basic steps that the process accounting subsystem goes through are

§ Collecting raw data You can select how often the data are collected.

§ Once-a-day reports You can produce cumulative summary and daily reports every day using the runacct command.

§ Once-a-month reports You can produce cumulative summary and monthly reports once a month (or more often) using the monacct command.

The kind of data you can collect includes

§ How long was a user logged in?

§ How much were terminal lines used?

§ How often did the system reboot?

§ How often is process accounting started/stopped?

§ How many files does each user have on disk (including the number of blocks used by the user’s files)?

For each process on the system, you can see

§ Who ran it (UID/GID)?

§ How long did it run (the time it started and the real time that elapsed until it completed)?

§ How much CPU time did it use (both user and system CPU time)?

§ How much memory was used?

§ What commands were run?

§ What was the controlling terminal?

Based on the data collected, you set charges and bill for these services. You can also define extra charges for special services you provide (such as restoring deleted files).

Setting Up Accounting

Since process accounting is very complex and powerful, it is not appropriate to describe all ways of gathering data and producing reports. Instead, an example of the process will be given.

To collect process accounting data automatically, you should have a file named /var/spool/ cron/crontabs/adm. The following are recommended entries for the adm file:

0 * * * * /usr/lib/acct/ckpacct

30 2 * * * /usr/lib/acct/runacct 2> /var/adm/acct/log

30 9 * 5 * /usr/lib/acct/monacct

The preceding entries in the adm file will run ckpacct every hour to check that process accounting files do not exceed 1,000 blocks. It will run runacct every morning at 2:30 A.M. to collect daily process accounting information. It will run monacct at 9:30 A.M. on the fifth day of every month to collect monthly accounting information. You should also have the following entry in the /var/spool/cron/crontabs/root file:

30 22 * * 4 /usr/Lib/acct/dodisk

This will run the disk accounting functions at 10:30 P.M. on the fourth day of every month.

Samples of the output from process accounting are shown in the following. The Daily Report shows terminal activity over the duration of the reporting period:

Jul 16 02:30 2006 DAILY REPORT FOR trigger Page 1

from Fri Jul 14 02:31:22 2006

to Sat Jul 15 02:30:25 2006

1 runacct

1 acctcon

TOTAL DURATION IS 1440 MINUTES

LINE MINUTES PERCENT # SESS # ON # OFF

term/11 25 3 7 4 4

term/12 157 16 6 3 3

TOTALS 183 -- 13 7 7

.

.

.

The preceding report shows the duration of the reporting period, the total duration of time in which the system was in multiuser mode, and the time each terminal was active. It then goes on to show other records that were written to the /var/adm/wtmp accounting file. The Daily Usage Report here (Figure 14–1) shows system usage on a per-user basis.

Mar 16 02:30 1999 DAILY USAGE REPORT FOR trigger Page 1

LOGIN CPU (MINS) KCORE-MINS CONNEC (MINS) DISK # OF # OF # DISK FEE

UID NAME PRIME NPRIME PRIME NPRIME PRIME NPRIME BLOCKS PROCS SESS SAMPLES

0 TOTAL 9 7 2 16 131 51 0 1114 13 0 0

0 root 7 6 1 11 0 0 0 519 0 0 0

3 sys 0 0 0 0 0 0 0 00 0 0 0

4 adm 0 0 0 1 0 0 0 00 0 0 0

5 uucp 0 0 0 0 0 0 0 00 0 0 0

999 mcn 2 1 1 2 111 37 0 269 1 0 0

7987 gwn 0 0 0 0 0 0 0 00 0 0 0

Figure 14–1: The Daily Usage Report

The report shows, for each user, the user ID and login name, the minutes of CPU time consumed (prime and nonprime time), the amount of core memory consumed (prime and nonprime time), the time connected to the system (prime and nonprime time), the disk blocks consumed, the number of processes invoked, the number of times the user logged in, how many times the disk sample was run, and the fee charged against the user (if any).

Process Scheduling

Chapter 11 gives you an overview of process scheduling and describes how users can change processor priorities temporarily on a running system. This section describes how an administrator can change processor priorities on a permanent basis.

Process Scheduling Parameters

Several operating system tunable parameters affect the process scheduling on your system. The following list describes the location of each tunable parameter and the default value, and it gives a short description of how the value is used.

The examples given are specific to the configuration files for a particular computer running some UNIX variants. You can change tunable parameter values by editing the file (using any text editor) and rebuilding the system. Other variants do not use the three files that follow but use a form of them with the same intent of managing tunable parameters.

The /etc/master.d/kernel File

This file contains all of the kernel configuration parameters. The following are those parameters specific to process scheduling.

§ MAXCLSYSPRI (default=99) This parameter sets the maximum global priority of processes in the system class. The priority cannot be set below 39, to ensure that system processes get higher priority than user processes.

§ INITCLASS (default=TS) This parameter sets the class at which system initialization processes will run (i.e., those started by the init process). Setting this to TS (time sharing) ensures that all login shells will be run in time-sharing mode.

§ SYS_NAME (default=SYS) This parameter identifies the name of the system scheduler class.

The /etc/master.d/ts File

This file contains parameters relating to the process scheduling time-sharing class.

§ TSMAXUPRI (default=20) This parameter sets the range of priority in which user processes can run. With a default of 20, users can change their priorities from –20 to +20. (See the description of the priocntl command in Chapter 11.)

§ ts_dptbl parameter table This table contains the values that are used to manage timesharing processes. It is built into the kernel automatically There are six columns in the ts_dptbl file: The glbpricolumn contains the priorities that determine when a process runs; the qntm column contains the amount of time given to a process with the given priority The other columns handle processes that sleep (i.e., are inactive while waiting for something to occur) and change priorities.

§ ts_kmdpris parameter table This table contains the values that are used to manage sleeping time-sharing processes. It is built into the kernel automatically The table assigns priorities to processes that are sleeping. Priorities are based on why the processes are sleeping (e.g., a process waiting for system resources would get higher priority than one waiting for input from another process).

The /etc/master.d/rt File

This file controls process scheduling relating to the real-time class. Note that some UNIX variants (e.g., Solaris 10) do not support the real-time class.

§ NAMERT (default=RT) This parameter identifies the name of the real-time scheduler class.

§ rt_dptbl parameter table This table contains the values that are used to manage realtime processes. It is only built into the kernel if the /etc/system file contains the line “INCLUDE:RT.” Two columns are in the rt_dptbl file: the rt_glbpri column contains the priorities that determine when a process runs and the rt_qntm column contains the amount of time given to a process with the given priority

Display Scheduler Parameters

You can display the current scheduler table parameters on Solaris using the dispadmin command. To display the classes that are configured on your system, type the following command to see the typical output shown:

dispadmin −1

CONFIGURED CLASSES

==================

SYS (System Class)

TS (Time Sharing)

FX (Fixed Priority)

IA (Interactive)

To display the current scheduler parameters for the time-sharing class, type the following command to see a report like the one shown:

dispadmin -c TS -g

# Time Sharing Dispatcher Configuration

RES=1000

# ts_quantum ts_tqexp ts_slpret ts_maxwaitts_lwait PRIORITY LEVEL

1000 0 10 5 10 # 0

1000 0 11 5 11 # 1

1000 1 12 5 12 # 2

1000 1 13 5 13 # 3

1000 2 14 5 14 # 4

1000 2 15 5 15 # 5

1000 3 16 5 16 # 6

1000 3 17 5 17 # 7

1000 4 18 5 18 # 8

1000 4 19 5 19 # 9

800 5 20 5 20 # 10

800 5 21 5 21 # 11

800 6 22 5 22 # 12

.

.

.

Under Solaris 10, you could replace TS with FX to see fixed-priority parameters, IA to see interactive parameters, or SYS to see system parameters.

Summary

This chapter discussed in detail two topics of major importance to system administrators:

§ Management of the file system

§ Management of system services

To administer a UNIX system effectively, it is important to have a basic understanding of the major file systems and the media on which they are stored. A sound understanding of directory structure and backing up and restoring data is also essential. While the directories and actual commands vary across the major variants, the concepts are still the same. Proper use of backup and restore capabilities enables you to guarantee that users have required data, as well as that the system has the appropriate resources. System services, such as the Service Access Facility, accounting, and scheduling, are described. The Service Access Facility (SAF) manages services available to hardware devices. Accounting utilities enable the administrator to monitor usage on the system. Through process scheduling (see Chapter 11), the system administrator can assign different priorities to processes running on the system.

How to Find Out More

There are many good books on system administration. Here are just a few for beginners (and for some more experienced system administrators as well):

· Bauer, Kirk. Automating UNIX and Linux Administration. Berkeley, CA: Apress, 2003.

· Calkins, Bill. Solaris 10 System Administration Exam Prep 2. Indianapolis, IN: Que, 2005.

· Feiler, Jesse. Mac OS X: The Complete Reference. Berkeley CA: McGraw-Hill/Osborne, 2001.

· Frisch, Æleen. Essential System Administration. 3rd ed. Sebastopol, CA: O’Reilly & Associates, Inc., 2002.

· Levi, Bozidar. UNIX Administration: A Comprehensive Sourcebook for Effective Systems & Network Management. Boca Raton, FL: CRC Press, 2002.

· Maxwell, Steven. UNIX System Administration: A Beginner’s Guide. Berkeley, CA: McGraw-Hill/Osborne, 2002.

· Michael, Randal K. AIX 5L Administration. Berkeley, CA: McGraw-Hill/Osborne, 2002.

· Negus, Christopher, and Thomas Weeks. Linux Troubleshooting Bible. Indianapolis, IN: John Wiley & Sons, 2004.

· Nemeth, Evi, Garth Snyder, Scott Seebass, and Trent Hein. UNIX System Administration Handbook. 3rd ed. Englewood Cliffs, NJ: Prentice Hall, 2000.

· Petersen, Richard. Red Hat Enterprise Linux and Fedora 4: The Complete Reference. 3rd ed. Berkeley, CA: McGraw-Hill/Osborne, 2005.

· Poniatowski, Marty. HP-UX 10.X System Administration. Englewood Cliffs, NJ: Prentice Hall, 1995.

· Poniatowski, Marty. HP-UX 11i System Administration. Englewood Cliffs, NJ: Prentice Hall, 2003.

· Winsor, Janice. Solaris System Administrator’s Guide. Mountain View, CA: Sun Microsystem Press, 1998.

Web Sites with Useful Information on System Administration

Numerous web sites offer valuable system administration information for each of the variants discussed in this chapter. Here are just a few for each of the variants discussed throughout this book.

Linux has an online Linux System Administrator’s Guide 0.9, by Lars Wirzenius. It is one of the better guides and includes many tips and tricks. You can get it at http://www.tldp.org/LDP/sag/html/index.html. There is a good online entry on Linux Administration Made Easy (LAME), part of the Linux Documentation Project, at http://www.tldp.org/LDP/lame/LAME/linux-admin-made-easy/.

Sun Microsystems has a site with System Administration info and FAQs about the Solaris 10 environment at http://www.sun.com/bigadmin/products/sol10.html.

HP has a site with useful information about administration of HP-UX 11.0 systems at http://docs.hp.com/en/oshpux11.0.html. HP also has a similar site for HP-UX 10.0 systems at http://docs.hp.eom/en/oshpux10.x.htmt. There is a site for registration for HP-UX 11 administration courses at http://www.mindiq.com/itt/hpux/hp200.php.

For AIX users, there is a discussion of unique issues regarding AIX system administration at http://www.unet.univie.ac.at/aix/aixbman/admnconc/sys_mgmt.htm. There is also course registration information for AIX system administration at http://www.mindiq.com/ilt/aix/ap200.php.

MacOS users can find a short description of basic system administration functions at: http://campus.umr.edu/cis/desktop/documentation/mac/osx/basic_system_adm In addition there are some very useful system administration tech tips and recipes at this URL: http://www.tech-recipes.com/mac_system_administration.html.

Newsgroups to Consult for Information on System Administration

You can gain a lot of insight into the issues of system administration simply by following the discussion in the USENET newsgroup comp.unix.admin. You will probably also want to read the newsgroup(s) devoted to the specific machine or version of UNIX you are using. The following newsgroups address questions dealing with administration and general use for particular operating systems. Usually, if you lack relevant or useful documentation, you will get useful information back when you post questions to the appropriate newsgroups. Some useful newsgroups are

· comp.os.linux.admin

· comp.sys.sun.admin

· comp.sys.hp.hpux

· comp.unix.aix

· comp.unix.solaris

· comp.mac.sys.*

· comp.unix.questions

Journals and Publications on System Administration

There are a number of journals and publications on System Administration for UNIX variants. For Linux, here are a few good journals:

· http://www.tinuxjournal.com/-Linux Journal (also available in print at newsstands)

· http://www.linuxmagazine.com/-Linux Magazine (also available in print at newsstands)

· http://www.linuxtoday.com/-Linux Today

· http://www.linuxplanet.com/linuxplanet/-Linux Planet

· http://linuxgazette.net/-Linux Gazette

· http://www.linuxfocus.org/-Linux Focus

For Solaris:

· http://www.adminschoice.com/-Admin’s Choice (technical tips, articles, discussions)

For HP-UX:

· http://www.hpl.hp.com/hpjournal/journal.html-The HP Journal online

For AIX:

· http://www.eservercomputing.com/ME2/Default.asp-eServer Magazine (covers AIX)

For MacOS:

· http://www.mactech.com/index.html-Mac Tech: The Journal of MacIntosh Technology

· http://www.macworld.com-Mac World: The Mac Product Experts

· http://www.macaddict.com/-Mac Addict (A better machine, a better magazine)

For all of the preceding variants:

· http://www.samag.com/-Sys Admin: The Journal for UNIX/Linux Administrators