Red Hat Linux Networking , System Administration (P28) pot

Directory and file names:--prefix=PREFIX install architecture-independent files in PREFIX --target=TARGET configure for TARGET [TARGET=HOST] Features and packages: --disable-FEATURE do n

Directory and file names:

prefix=PREFIX install architecture-independent files in PREFIX

target=TARGET configure for TARGET [TARGET=HOST]

Features and packages:

disable-FEATURE do not include FEATURE (same as FEATURE=no)

enable -enable-FEATURE[=ARG] include FEATURE [ARG=yes]

with-PACKAGE[=ARG] use PACKAGE [ARG=yes]

without-PACKAGE do not use PACKAGE (same as with-PACKAGE=no) x-includes=DIR X include files are in DIR

x-libraries=DIR X library files are in DIR enable and with options recognized:

with-pkg use software installed in /usr/pkg tree with-libedit support fancy BSD command input editing with-readline support fancy command input editingThe key options in the example output are prefix and the three optionsthat appear under the heading enable and with options recognized, with-pkg, with-libedit, and with-readline prefixenables you to specify an installation directory other than the default (indicated

in brackets, []), /usr/local For this example, the root installation directory is/tmp/bctest, specified as prefix=/tmp/bctest on configure’s com-mand line The second group of command line options enables other features.This example uses with-readline, which turns on support for the GNUreadline library The readline library enables command line editing inside the bcprogram, just as the bash shell permits editing the shell command line

After selecting the desired options, run configure with the appropriateoptions, as shown in the following example (Again, the output has beenedited to conserve space.)

$ /configure prefix=/tmp/bctest with-readline

creating cache /config.cache checking for a BSD compatible install /usr/bin/install -c checking whether build environment is sane yes

checking whether make sets ${MAKE} yes checking for working aclocal found checking for working autoconf found checking for working automake found

checking for working autoheader found checking for working makeinfo found checking for gcc gcc

checking whether the C compiler (gcc ) works yes

checking for readline in -lreadline yes checking for readline/readline.h yes Using the readline library.

updating cache /config.cache creating /config.status creating Makefile

creating bc/Makefile creating dc/Makefile creating doc/Makefile creating lib/Makefile creating config.hThe lines beginning with checking indicate that configure is testing for thepresence of a certain feature such as gcc Because the command line specified with-readline, the last two checking lines make sure the readline library

is installed (checking for readline in -lreadline yes) and that theappropriate header file, readline.h, is installed Once all of the tests arecompleted, configure uses the test results to create a number of Makefilesand a header file

T I P If you are in the habit of building software as the root user, stop! It is extremely rare to require root access to build software The only step that needs root access is the make install step, which requires write permissions to the installation directories We routinely build the kernel and major system applications as mortal users, only using su when we are ready to install.

At this point, you are ready to build bc

Building the Software Package

To build bc, type make and press Enter The following example shows the end

of the build process’s output:

gcc -DHAVE_CONFIG_H -I -I -I -I./ -I./ /h -g -O2 -Wall -funsigned-char -c stack.c

gcc -DHAVE_CONFIG_H -I -I -I -I./ -I./ /h -g -O2 -Wall -funsigned-char -c array.c

gcc -DHAVE_CONFIG_H -I -I -I -I./ -I./ /h -g -O2 -Wall -funsigned-char -c numeric.c

gcc -DHAVE_CONFIG_H -I -I -I -I./ -I./ /h -g -O2 -Wall -funsigned-char -c string.c

gcc -g -O2 -Wall -funsigned-char -o dc dc.o misc.o eval.o sta ck.o array.o numeric.o string.o /lib/libbc.a

make[2]: Leaving directory `/tmp/bc-1.06/dc’

Making all in doc make[2]: Entering directory `/tmp/bc-1.06/doc’

make[2]: Nothing to be done for `all’.

make[2]: Leaving directory `/tmp/bc-1.06/doc’

make[2]: Entering directory `/tmp/bc-1.06’

make[2]: Leaving directory `/tmp/bc-1.06’

make[1]: Leaving directory `/tmp/bc-1.06’

Depending on the size and complexity of the program you are building,make’s output might be extensive In the example shown, you see the finalcompiler invocations and, most importantly, no errors Accordingly, the nextstep is to test the build

Testing the Build

Many programs, especially those from the GNU projects, include some sort oftest suite to validate the program The idea is to make sure that the programworks properly before installing it In some cases, you execute the make testcommand to run the test suite In other cases, as with bc, a special subdirec-tory of the build tree, conveniently named test or Test, contains the testsuite Each package handles testing slightly differently, so read the packagedocumentation In the case of bc, the test suite lives in a subdirectory namedTest, and a shell script named timetest performs the actual test In thiscase, timetest evaluates how long it takes bc to perform certain mathemat-ical calculations, but it also serves to ensure that bc built properly The follow-ing commands invoke bc’s test suite:

$ cd Test

$ /timetest

timetesttakes at least 10 minutes to run, so have a cup of coffee or yourfavorite beverage while the test runs If no errors occur during the test, you areready to install it

Installing the Software

In the case of bc, as with many, many other programs installed from source,installing the built and tested program is simply a matter of executing thecommand make install in the build tree’s base directory (/tmp/bc-1.0.6,

in this case) Programs that are more complex might have additional mands, such as make install-docs to install only documentation, thatbreak up the installation into more steps or that perform only part of the instal-lation Still other packages might use scripts to perform the installation.Regardless of the process, however, the goal is the same: Install program exe-cutables and documentation in the proper directories, create any needed sub-directories, and set the appropriate file ownership and permissions on theinstalled files

com-In the case of the bc package, the installation command is a simple makeinstall, as shown in the following code:

make install-man1 make[3]: Entering directory `/tmp/bc-1.06/doc’

/bin/sh /mkinstalldirs /tmp/bctest/man/man1 mkdir /tmp/bctest/man

mkdir /tmp/bctest/man/man1 /usr/bin/install -c -m 644 /bc.1 /tmp/bctest/man/man1/bc.1 /usr/bin/install -c -m 644 /dc.1 /tmp/bctest/man/man1/dc.1

The output, edited to conserve space, shows the creation of the installationdirectory, /tmp/bctest (recall the prefix=/tmp/bctest command lineoption passed to configure), a subdirectory for the binary (/tmp/bctest/bin)and the subdirectory for the manual pages, /tmp/bctest/man/man1 Theoutput also shows the invocation of the install program that actually per-forms the installation The -c option is ignored because it is used for compati-bility with install programs used on proprietary UNIX systems The -m optionsets the file permissions using the octal permission notation So, -m 644 makesthe files bc.1 and dc.1 (which are manual pages) read/write for the file ownerand read-only for the file group and all other users

N OT E For more information about the install program, read the manual page (man install) or the TeX-info page (info install).

At this point, package installation is complete Although this example ofbuilding and installing a package from a source tarball is simple, the basic pro-cedure is the same for all packages: unpack the source archive, configure it asnecessary, build it, test the program, and then install it One final exhortationbefore proceeding to the next section: Read the documentation! Most softwareyou obtain in source code form includes one or more files explaining how tobuild and install the software; we strongly encourage you to read these files tomake sure that your system meets all the prerequisites, such as having theproper library versions or other software components The documentation isthere to help you, so take advantage of it and save yourself some frustration-induced hair loss!

Summary

This chapter covered a lot of territory You learned how to use each of RPM’smajor operating modes, including querying the RPM database; installing,upgrading, and removing RPMs; and maintaining the RPM database You alsolearned methods for obtaining the version information of installed software.The chapter listed some popular software repositories and how to use them.Finally, you learned how to build and install software from source using boththe traditional tools (tar, gcc, make, install) and RPM’s higher-level inter-face to these tools

Backing Up and Restoring

the File System

IN THIS CHAPTER

■■ Creating a Backup Plan

■■ Choosing Media for Backups

■■ Understanding Backup Methods

■■ Tape Rotation

■■ Using Backup Tools

In this chapter, you learn how to make backups of your files and restore aged file systems from backups It is important to make backups of the file sys-tem to avoid the loss of important information in the case of catastrophichardware or software failure An efficient backup and restoration process canminimize downtime and prevent the need to recreate lost work In this chap-ter, you learn how to choose a backup medium and how to use backup tools.Red Hat Enterprise Linux provides several packages for dealing with thebackup and restoration of the file system The tar and dump commands pro-vide low-level interfaces to system backups In addition, sophisticated backuptools, such as AMANDA, can do automatic backups of multiple machines

dam-Creating a Backup Plan

Determining what to back up on a particular machine depends largely onwhat data the machine contains and how the machine is used However, thereare some general guidelines that can be useful in determining what to back up.Generally, temporary and cached files need not be backed up The contents

of the /tmp directory, for instance, are usually deleted when the machine is

C H A P T E R

31

rebooted Therefore, it is all right to not back up these files Also, the cachedirectory used by Mozilla and found in users’ mozilla directory is auto-matically regenerated by Mozilla if it is deleted You may find it worthwhile toinvestigate whether any other packages installed on the machine generate sig-nificant amounts of ignorable temporary data.

Depending on the situation, it may or may not be advisable to back up themachine’s system files If the machine is a standard installation of Red HatEnterprise Linux without any customizations or extra packages installed, thesystem files can be restored by reinstalling Red Hat Linux The tradeoff is thatreinstalling and reconfiguring a system probably takes more time and atten-tion than restoring the file system from backup However, this tradeoff may beworthwhile because of the amount of backup media that can be saved In theparticular case that a single Red Hat installation is copied verbatim onto manymachines, it may be appropriate to back up the system files of just one of themachines If the system files are identical across machines, a single backupshould restore all of them In any case it is probably wise to back up at least the/etcdirectory of each machine Probably the machines have at least some dif-fering configuration information, such as network and hostname settings.One other thing needs to be backed up and indeed needs to be backed upvia a special method: database files Doing a straight tar from database fileswon’t save you from a database crash, because the database files will all be

in different states, having been written to backup when opened Oracle,Informix, Sybase, and so forth all allow the administrator to export the tabledata in text or other delimited file as well as put the database tablespaces inbackup mode In backup mode, the data to be written goes to a memory cacherather than the file, and transaction logs are updated only when the cache isflushed This procedure slows things down but makes certain that the data-base will survive a crash

The other aspect of the file system, other than the system files that need to

be backed up, is the user files Generally, all user files are stored in ries of the /home directory You should find it easy, therefore, to back up alluser files at one time Even when the entire file system — both system and userfiles — is being backed up, you should still back them up separately Systemand user files can have different relative priority depending on the situation.The user files are important because they may be irreplaceable, whereas many

subdirecto-of the system files generally can be replaced by reinstalling Red Hat Linux Onthe other hand, restoration of the system files is necessary for the machine tofunction and provide services, whereas the machine can be totally functionalwithout restoration of the user files Such priority considerations must bemade when designing a backup strategy

Give special thought to resources that do not easily fall into the system anduser categories Information stored in SQL databases, for instance, is often

technically owned by root or by a special system user, but also often containsirreplaceable content entered by users This kind of data can often be the mostimportant to back up You may find it beneficial to investigate which of theinstalled packages use this kind of data Other examples besides databases areWeb servers and mailing list archivers.

Choosing Media for Backups

A variety of backup media are available on the market today Which backupmedia you use depends on a number of factors and the particular needs of thesituation You should consider how often files are backed up, how long thebackups need to last, how redundant the backups need to be, and how muchmoney can be allocated to purchasing backup media Table 31-1 provides acomparison of backup media

Table 31-1 Comparison of Backup Media

Magnetic tape High High Cheap Slow Writable CDs Medium Medium Cheap Fast Hard drive High High Expensive Fast

Zip disks Medium Low Medium Slow Flash ROM Medium High Expensive Fast Removable hard High High Expensive Fast drive (FireWire)

Removable hard High High Expensive Medium drive (USB)

Understanding Backup Methods

To save time and money in creating backups and restoring corrupted file tems and in purchasing backup media, it is important to institute a methodologyfor creating scheduled backups The number of different backup methodologies

sys-is unlimited How you should perform backups depends on the particular needs

of your institution and computing infrastructure The scheduling and type ofbackups depends on the type of backup media being used, the importance of thedata, and the amount of downtime you can tolerate.

The simplest backup methodology is creating a full backup A full backupcopies the entire file system to the backup medium This methodology can begood for small systems in which there is not much data to back up or systems

in which the data is very important, where it is changing rapidly, and wherehistorical snapshots of the system at different points in time are useful.Performing frequent full backups has several disadvantages Full backupstake a long time to perform if there is a lot of data to back up or if the backupmedium is slow To get a clear snapshot of the system, you may need to sus-pend the execution of processes that modify the file system while the backupprocess takes place If backups take a long time, the downtime might be pro-hibitive Full backups have no disadvantages when it comes to restoring anentire file system from backup However, there is a disadvantage when restor-ing a partial file system from backup If a sequential medium, such as mag-netic tape, is used, it must be searched sequentially to find the files that need

to be restored This process can cause a partial restoration to take as long as afull file system restoration in the worst case Full backups also take signifi-cantly more space to archive than incremental backups This situation is nottoo much of a disadvantage if you reuse the same backup media; you can justoverwrite the old backup with the new one However, it is often advisable tokeep multiple generations of backups Sometimes problems with the file sys-tem, such as corrupted or erased files, are not detected or reported immedi-ately If the file system is backed up once a day on the same backup tapes and

an accidentally erased file is not found for two days, it cannot be recovered Onthe other hand, if the file system is backed up once a week, any files lostbetween backups cannot be recovered Keeping multiple full backups also has

a disadvantage If a full backup is made every day, the amount of archivemedia necessary to store it quickly becomes prohibitive

The alternative to doing full backups is to do incremental backups An mental backup archives only the files that have changed or been added sincethe last backup Incremental backups solve all of the disadvantages of fullbackups Incremental backups are fast In fact, the more often you do them, thefaster they are because there is less to back up Since the backups are smaller,searching from a given backup for a particular file is faster, thus making par-tial restorations faster if you need to restore from a particular known incre-mental backup archive Because less is backed up each time, less media isused, so either less backup media needs to be bought or a longer history can bekept in the same amount of backup media In the latter case, backups are morerobust against lost or damaged files that are not discovered for a while

incre-Using incremental backups has disadvantages as well While incrementalbackups are faster for retrieving individual files, they are slower for restoringentire file systems To explain this problem, imagine that you have a week-long backup cycle On the first day of the week, you make a full backup Therest of the week, you make an incremental backup If a file system is erasedaccidentally on the last day of the week (right before a new full backup is to bemade), you have to start at the last full backup and then load in a whole week

of tapes to entirely restore the file system If you made a full backup every day,you would have to load only the full backup, then you would be done restor-ing the file system

When to use full backups and when to use incremental backups depends onthe particular data stored on the machines, the way the machines are used, andhow much money can be allocated to buying backup media After you havedecided on a backup methodology, you must configure your tools to use thismethodology Full and incremental backups can be implemented in scripts ontop of the primitive backup tools such as tar More advanced tools such asdumpand AMANDA have built-in support for backup levels and scheduling

of various kinds of backups AMANDA even has a complex configuration guage that lets you specify all kinds of details about the various types of back-ups you might want to do, the length of your backup cycle, and what filesshould be excluded from backup (such as private or temporary files)

lan-Another thing to consider is the criticality of the system If the system must

be up at all times and downtime is a critical situation, then full backups arenecessary to minimize downtime One strategy for backing up criticalmachines is to create a separate volume group on mirrored disks solely forbackups and use it as an intermediate area to copy files to prior to writingthem to tape A compressed tar file can be created on disk and then be writ-ten to tape faster than a normal tar file can Also, since a backup exists ondisk, the tape archive is only used as a last resort if the disk archive fails Thisstrategy is similar to the one that the AMANDA automated backup utility uses

to take into account faulty backup devices or media Even if the tape drivefails, the backup on disk can be written to tape when the problem has beensolved

Tape Rotation

Another consideration after you select a backup method is a proper tape tion schedule A well-thought-out schedule can lower your media costs andincrease the life of your tapes, while ensuring that every file is protected Sev-eral popular tape rotation methods are currently in use

rota-Grandfather-father-son (GFS) is probably the most common tape rotationscheme The grandfather backup is a monthly full backup, the father is aweekly full backup, and the son is a daily incremental backup It is usually agood idea, and more secure, to store at least the full monthly backups off-site.

In the event of a catastrophe at your location, a fire that damaged or destroyedyour on-site backups, for example, you would be able to restore your datafrom tapes stored off-site

T I P For a detailed explanation of tape rotation methods, a good place to look is the Seagate Web site: seagate.com/products/tapesales/backup

/A2g1.html.

Using Backup Tools

Fedora Core and Red Hat Enterprise Linux provide numerous tools for doingfile system backups There are tools for interacting with backup media, such asftapefor manipulating tapes drives and cdrecord for writing to CD drives.Command line tools such as tar and dump allow for low-level control of filesystem backups and also easy automation through scripting Using only shellscripts and periodic scheduling through cron jobs, you can develop a robustautomated backup solution for many situations Graphical tools also exist to cre-ate a more user-friendly interface for performing manual backups Advancedbackup tools that can be configured to fully automate the process of backing upmultiple machines do exist

Command Line Tools

Fedora Core and Red Hat Enterprise Linux provide a number of commandline tools for performing backups and restoring from backups The tools forinteracting directly with backup media are mt-st and cdrecord The stan-dard tools for creating archives are tar and dump for tape archives andmkisofsfor CD archives Each command provides a different interface and anumber of options

Using mt-st

The mt-st package is a collection of command line tools for accessing and aging magnetic tape drives (the mt part of the package) and also includes themodule that is used to control the SCSI tape drive (the st part of the package),

man-or an IDE drive in SCSI emulation mode This package is installed by default

on Fedora Core and Enterprise Linux and is intended to control tape drivesconnected to a SCSI bus You can check to be sure the package is installed byentering the following at a command line interface.

rpm -q mt-st

The command will return mt-st <version number> if the package isinstalled and nothing if the package is not installed In the event that the pack-age is not installed, find it on the installation CDs and install it using the fol-lowing command:

rpm -Uvh mt-st<version number>(Be sure to use the proper version number)

To be able to communicate with your tape drive, the st module must beloaded You can determine whether the st module is loaded by entering thefollowing command:

/sbin/modinfo st

If the module is installed you will see output similar to this:

filename: /lib/modules/2.6.10-1.770_FC3/kernel/drivers/scsi/st.ko author: Kai Makisara

description: SCSI Tape Driver license: GPL

parm: buffer_kbs:Default driver buffer size for fixed block mode (KB;

32) parm: max_sg_segs:Maximum number of scatter/gather segments to use (256)

parm: try_direct_io:Try direct I/O between user buffer and tape drive (1)

parm: try_rdio:Try direct read i/o when possible parm: try_wdio:Try direct write i/o when possible vermagic: 2.6.10-1.770_FC3 686 REGPARM 4KSTACKS gcc-3.4 depends: scsi_mod

(scsi0:A:6): 10.000MB/s transfers (10.000MHz, offset 15) Vendor: COMPAQ Model: DLT4000 Rev: D887 Type: Sequential-Access ANSI SCSI revision: 02 st: Version 20040403, fixed bufsize 32768, s/g segs 256

Attached scsi tape st0 at scsi0, channel 0, id 6, lun 0 st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA 1048575

From this output, you can see the SCSI tape drive is identified as st0 Tocommunicate with this drive you would use /dev/st0 There are actuallyeight device nodes associated with the tape device Four of the nodes indicateautorewind nodes and four indicate no rewind nodes The autorewind nodesare indicated by st0*, and the nonrewind nodes are indicated by nst0* Youcan see a listing of these different nodes by running the ls -ld command forthe devices For example, to see the autorewind nodes do this:

ls /dev/st0*

You will see this output:

/dev/st0 /dev/st0a /dev/st01 /dev/st0m

To see the no rewind nodes, enter ls /dev/nst0*, and you will see the following:

/dev/nst0 /dev/nst0a /dev/nst01 /dev/nst0m

When you are communicating with the tape device, you use /dev/st0*when you want to rewind the tape and /dev/nst0* when you do not want torewind the tape You will see some examples later in the section on the mt andtarcommands

The mt command is used to perform many tape control functions, such asscanning, rewinding, and ejecting magnetic tapes Take a look at some examples.You must be root to access the tape drives As root, you can test a new mag-netic tape by inserting it into the tape drive and using the following command:

mt -f /dev/st0 statusThis command will return output similar to the following:

drive type = Generic SCSI-2 tape drive status = 318767104

sense key error = 0 residue count = 0 file number = 0 block number = 0 Tape block size 0 bytes Density code 0x13 (DDS (61000 bpi)).

General status bits on (45010000):

BOT WR_PROT ONLINE IM_REP_EN

In addition to giving you status information about the tape, it will rewind it

to the beginning If you run the same command but use /dev/nst0 instead,you would receive the status information, but the tape does not rewind Thereare many options available to you with the mt command The best source ofinformation is the mt manual page, which you can access by typing man mt at

a command line

Using the cdrecord Package

To make backups on CDs under Red Hat Enterprise Linux, you need thecdrecord package installed It contains several commands such as cdrecord,devdump, isodump, isoinfo, isovfy, and readcd These commands areuseful utilities for creating and managing writable CDs

The disadvantage to making backups on CD is that you must first create a

CD image on the file system and then copy the CD image to the actual CD all

in one step This process requires that you have empty space on a single filesystem partition that is large enough to hold a CD image (up to 650 MB) Youcreate a CD image with the mkisofs command:

mkisofs -o /tmp/cd.image /home/terry

N OT E You can also use mkisofs to send content to stdout and then feed directly into cdrecord Using this method does run the risk of the output being larger than the CD capacity and possibly buffer underruns on slow systems that don’t use burnproof or a similar technology A good idea is to run the du -s command for each directory you want to back up to determine if it will fit on

a CD/DVD.

This command makes a CD image file in the /tmp directory calledcd.image The CD image file contains all the files in the /home/terry direc-tory You must have enough space to make the image file on the partition hold-ing the /tmp directory You can determine how much is free with the dfcommand You can determine how much space the image file is going to take

up with the du /home/terry command By default, mkisofs preserves theownership and permissions from the file system in the CD image

To burn the image file to an actual CD, you must determine which devicehas the CD drive and its device number, logical unit number, and device ID.You can find this information with the following command:

The output of the cdrecord command follows The line that shows the CDdrive type and manufacturer is the one you are interested in At the beginning

of the line is the SCSI ID information shown as 1,0,0, which is the SCSI devicenumber (1), the logical unit number (0), and the device ID (0)

cdrecord-Clone 2.01-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling

Note: This version is an unofficial (modified) version with DVD support Note: and therefore may have bugs that are not present in the original.

Note: Please send bug reports or support requests to http://bugzilla.redhat.com/bugzilla

Note: The author of cdrecord should not be bothered with problems in this version.

scsidev: ‘ATA’

devname: ‘ATA’

scsibus: -2 target: -2 lun: -2 Linux sg driver version: 3.5.27 Using libscg version ‘schily-0.8’.

cdrecord: Warning: using inofficial libscg transport code version (schily - Red Hat-scsi-linux-sg.c-1.83-RH ‘@(#)scsi-linux-sg.c 1.83 04/05/20 Copyright

1997 J Schilling’).

scsibus1:

1,0,0 100) ‘HL-DT-ST’ ‘RW/DVD GCC-4243N’ ‘1.07’ Removable CD-ROM 1,1,0 101) *

1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) * 1,6,0 106) * 1,7,0 107) *

You supply the SCSI device number, the device ID, and the logical unit ber to the cdrecord command, in that order, as part of the dev option A sam-ple cdrecord command is as follows:

num-cdrecord -v dev=1,0,0 -data /tmp/cd.imageThis command does not generally produce a bootable CD For a CD to bebootable, the image file being recorded onto the CD needs to follow a specificformat Also, your BIOS must support booting from your particular CD-ROM

To produce a bootable image file, you need to follow several steps First, youneed to obtain a boot image If you have a bootable CD-ROM in the disk drive,the boot image can be written to a file with the following command:

dd if=/dev/fd0 of=boot.img bs=10k count=144

T I P One handy boot image is the diskboot.img, which is on disk one of the Fedora Core and Red Hat Enterprise installation disks