Red Hat Linux Networking , System Administration (P28) pot

Directory and file names: prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [same as prefix] Host type: build=BUILD configure for building on BUILD [BUILD=HOST] host=HOST configure for HOST [guessed] target=TARGET configure for TARGET [TARGET=HOST] Features and packages: disable-FEATURE do not include FEATURE (same as enable- FEATURE=no) 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 editing The key options in the example output are prefix and the three options that appear under the heading enable and with options recognized, with-pkg, with-libedit, and with-readline. prefix enables 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 GNU readline library. The readline library enables command line editing inside the bc program, just as the bash shell permits editing the shell command line. After selecting the desired options, run configure with the appropriate options, as shown in the following example. (Again, the output has been edited 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 774 Chapter 30 38_599496 ch30.qxd 8/30/05 7:36 PM Page 774 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.h The lines beginning with checking indicate that configure is testing for the presence 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 the appropriate header file, readline.h, is installed. Once all of the tests are completed, configure uses the test results to create a number of Makefiles and a header file. TIP 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: $ make gcc -DHAVE_CONFIG_H -I. -I. -I -I./ -I./ /h -g -O2 -Wall -funsigned-char -c dc.c gcc -DHAVE_CONFIG_H -I. -I. -I -I./ -I./ /h -g -O2 -Wall -funsigned-char -c misc.c gcc -DHAVE_CONFIG_H -I. -I. -I -I./ -I./ /h -g -O2 -Wall -funsigned-char -c eval.c Installing and Upgrading Software Packages 775 38_599496 ch30.qxd 8/30/05 7:36 PM Page 775 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 final compiler invocations and, most importantly, no errors. Accordingly, the next step is to test the build. Testing the Build Many programs, especially those from the GNU projects, include some sort of test suite to validate the program. The idea is to make sure that the program works properly before installing it. In some cases, you execute the make test command 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 test suite. Each package handles testing slightly differently, so read the package documentation. In the case of bc, the test suite lives in a subdirectory named Test, and a shell script named timetest performs the actual test. In this case, 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 timetest takes at least 10 minutes to run, so have a cup of coffee or your favorite beverage while the test runs. If no errors occur during the test, you are ready to install it. 776 Chapter 30 38_599496 ch30.qxd 8/30/05 7:36 PM Page 776 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 the command 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 com- mands, such as make install-docs to install only documentation, that break 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 the installed files. In the case of the bc package, the installation command is a simple make install, as shown in the following code: $ make install /bin/sh /mkinstalldirs /tmp/bctest/bin mkdir /tmp/bctest mkdir /tmp/bctest/bin /usr/bin/install -c bc /tmp/bctest/bin/bc 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 installation directory, /tmp/bctest (recall the prefix=/tmp/bctest command line option passed to configure), a subdirectory for the binary (/tmp/bctest/bin) and the subdirectory for the manual pages, /tmp/bctest/man/man1. The output 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 option sets the file permissions using the octal permission notation. So, -m 644 makes the files bc.1 and dc.1 (which are manual pages) read/write for the file owner and read-only for the file group and all other users. Installing and Upgrading Software Packages 777 38_599496 ch30.qxd 8/30/05 7:36 PM Page 777 NOTE 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 of building 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 as necessary, build it, test the program, and then install it. One final exhortation before proceeding to the next section: Read the documentation! Most software you obtain in source code form includes one or more files explaining how to build and install the software; we strongly encourage you to read these files to make sure that your system meets all the prerequisites, such as having the proper library versions or other software components. The documentation is there 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’s major operating modes, including querying the RPM database; installing, upgrading, and removing RPMs; and maintaining the RPM database. You also learned 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 both the traditional tools (tar, gcc, make, install) and RPM’s higher-level inter- face to these tools. 778 Chapter 30 38_599496 ch30.qxd 8/30/05 7:36 PM Page 778 779 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 dam- 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 catastrophic hardware or software failure. An efficient backup and restoration process can minimize 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 the backup and restoration of the file system. The tar and dump commands pro- vide low-level interfaces to system backups. In addition, sophisticated backup tools, such as AMANDA, can do automatic backups of multiple machines. Creating a Backup Plan Determining what to back up on a particular machine depends largely on what data the machine contains and how the machine is used. However, there are 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 CHAPTER 31 39_599496 ch31.qxd 8/30/05 7:13 PM Page 779 rebooted. Therefore, it is all right to not back up these files. Also, the cache directory used by Mozilla and found in users’ .mozilla directory is auto- matically regenerated by Mozilla if it is deleted. You may find it worthwhile to investigate 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 the machine’s system files. If the machine is a standard installation of Red Hat Enterprise Linux without any customizations or extra packages installed, the system files can be restored by reinstalling Red Hat Linux. The tradeoff is that reinstalling and reconfiguring a system probably takes more time and atten- tion than restoring the file system from backup. However, this tradeoff may be worthwhile because of the amount of backup media that can be saved. In the particular case that a single Red Hat installation is copied verbatim onto many machines, it may be appropriate to back up the system files of just one of the machines. If the system files are identical across machines, a single backup should restore all of them. In any case it is probably wise to back up at least the /etc directory 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 up via a special method: database files. Doing a straight tar from database files won’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 table data in text or other delimited file as well as put the database tablespaces in backup mode. In backup mode, the data to be written goes to a memory cache rather than the file, and transaction logs are updated only when the cache is flushed. 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 subdirecto- ries of the /home directory. You should find it easy, therefore, to back up all user files at one time. Even when the entire file system — both system and user files — is being backed up, you should still back them up separately. System and user files can have different relative priority depending on the situation. The user files are important because they may be irreplaceable, whereas many of the system files generally can be replaced by reinstalling Red Hat Linux. On the other hand, restoration of the system files is necessary for the machine to function and provide services, whereas the machine can be totally functional without restoration of the user files. Such priority considerations must be made when designing a backup strategy. Give special thought to resources that do not easily fall into the system and user categories. Information stored in SQL databases, for instance, is often 780 Chapter 31 39_599496 ch31.qxd 8/30/05 7:13 PM Page 780 technically owned by root or by a special system user, but also often contains irreplaceable content entered by users. This kind of data can often be the most important to back up. You may find it beneficial to investigate which of the installed packages use this kind of data. Other examples besides databases are Web servers and mailing list archivers. Choosing Media for Backups A variety of backup media are available on the market today. Which backup media you use depends on a number of factors and the particular needs of the situation. You should consider how often files are backed up, how long the backups need to last, how redundant the backups need to be, and how much money can be allocated to purchasing backup media. Table 31-1 provides a comparison of backup media. Table 31-1 Comparison of Backup Media MEDIUM CAPACITY RELIABILITY COST SPEED Magnetic tape High High Cheap Slow Writable CDs Medium Medium Cheap Fast Hard drive High High Expensive Fast Floppy disks Low Low Cheap Slow DVD High High Medium Slow 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 sys- tems and in purchasing backup media, it is important to institute a methodology for creating scheduled backups. The number of different backup methodologies is unlimited. How you should perform backups depends on the particular needs Backing Up and Restoring the File System 781 39_599496 ch31.qxd 8/30/05 7:13 PM Page 781 of your institution and computing infrastructure. The scheduling and type of backups depends on the type of backup media being used, the importance of the data, and the amount of downtime you can tolerate. The simplest backup methodology is creating a full backup. A full backup copies the entire file system to the backup medium. This methodology can be good 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 where historical snapshots of the system at different points in time are useful. Performing frequent full backups has several disadvantages. Full backups take a long time to perform if there is a lot of data to back up or if the backup medium 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 backup process takes place. If backups take a long time, the downtime might be pro- hibitive. Full backups have no disadvantages when it comes to restoring an entire 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 a full file system restoration in the worst case. Full backups also take signifi- cantly more space to archive than incremental backups. This situation is not too much of a disadvantage if you reuse the same backup media; you can just overwrite the old backup with the new one. However, it is often advisable to keep 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. On the other hand, if the file system is backed up once a week, any files lost between backups cannot be recovered. Keeping multiple full backups also has a disadvantage. If a full backup is made every day, the amount of archive media necessary to store it quickly becomes prohibitive. The alternative to doing full backups is to do incremental backups. An incre- mental backup archives only the files that have changed or been added since the last backup. Incremental backups solve all of the disadvantages of full backups. Incremental backups are fast. In fact, the more often you do them, the faster 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 is used, so either less backup media needs to be bought or a longer history can be kept in the same amount of backup media. In the latter case, backups are more robust against lost or damaged files that are not discovered for a while. 782 Chapter 31 39_599496 ch31.qxd 8/30/05 7:13 PM Page 782 Using incremental backups has disadvantages as well. While incremental backups are faster for retrieving individual files, they are slower for restoring entire 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. The rest of the week, you make an incremental backup. If a file system is erased accidentally on the last day of the week (right before a new full backup is to be made), 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 on the particular data stored on the machines, the way the machines are used, and how much money can be allocated to buying backup media. After you have decided on a backup methodology, you must configure your tools to use this methodology. Full and incremental backups can be implemented in scripts on top of the primitive backup tools such as tar. More advanced tools such as dump and AMANDA have built-in support for backup levels and scheduling of various kinds of backups. AMANDA even has a complex configuration lan- 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 files should be excluded from backup (such as private or temporary files). 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 are necessary to minimize downtime. One strategy for backing up critical machines is to create a separate volume group on mirrored disks solely for backups and use it as an intermediate area to copy files to prior to writing them 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 on disk, the tape archive is only used as a last resort if the disk archive fails. This strategy is similar to the one that the AMANDAautomated backup utility uses to take into account faulty backup devices or media. Even if the tape drive fails, the backup on disk can be written to tape when the problem has been solved. Tape Rotation Another consideration after you select a backup method is a proper tape rota- tion schedule. A well-thought-out schedule can lower your media costs and increase the life of your tapes, while ensuring that every file is protected. Sev- eral popular tape rotation methods are currently in use. Backing Up and Restoring the File System 783 39_599496 ch31.qxd 8/30/05 7:13 PM Page 783 [...]... 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 number to the cdrecord command, in that order, as part of the dev option A sample cdrecord command is as follows: cdrecord -v dev= 1,0 ,0 -data /tmp/cd.image This command does not generally produce a bootable CD For a CD to be bootable, the... 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 the cdrecord package installed It contains several commands such as cdrecord, devdump, isodump, isoinfo, isovfy, and readcd These commands are useful utilities for creating and managing writable CDs The disadvantage to making backups on CD is that... AMANDA, you can configure your Red Hat Linux machine to be a centralized backup server for the other machines in the network, including Windows systems AMANDA is included with Fedora Core and Red Hat Enterprise Linux To use AMANDA, install the following packages: ■ ■ amanda ■ ■ amanda-client ■ ■ amanda-server ■ ■ Gnuplot You need to install the amanda-server and gnuplot packages only on the machine that... prompt when bad blocks are encountered None Restoring the File System To restore a damaged or erased file system, you must first recreate the directory or partition that has been lost If, for instance, you want to recreate the /home directory, which existed by itself on the /dev/hdb1 partition, you could use the following commands: mkfs /dev/hdb1 mount /dev/hdb1 /home Note that this command erases all of... as 1,0 , 0, which is the SCSI device number (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... backup is a monthly full backup, the father is a weekly full backup, and the son is a daily incremental backup It is usually a good 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 destroyed your on-site backups, for example, you would be able to restore your data from tapes stored off-site T I P For a detailed... file systems that need to be backed up None w List individual files that need to be backed up None 0–9 Specify a dump level of 0 through 9 None C AU T I O N Using dump on a live file system can be dangerous and unreliable For more information on this topic, see redhat.com/archives/ext3-users /2003-January/msg00034.html Sample dump Command If you want to see a sample of the output from the dump command,... 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’... been added, modified, or deleted since the last backup, those changes are lost Restoring individual files is covered in the section “Using Restore Interactively.” Also, if mkfs is accidentally run on a different partition than the one meant to be restored, all of the data on the partition on which it is mistakenly run is irrevocably erased The restore command must be run inside the directory that is going... System Table 31-4 (continued) COMMAND MEANING quit Exits the restore program No other actions are taken by restore setmodes Rather than extracting the files, this sets the permissions on the files in the file system so that they match the permissions of the files in the dump archive that are marked for extraction verbose Switches verbose mode on or off Using tar Fedora Core and Red Hat Enterprise Linux . 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,. file system, other than the system files that need to be backed up, is the user files. Generally, all user files are stored in subdirecto- ries of the /home directory. You should find it easy, therefore,. customizations or extra packages installed, the system files can be restored by reinstalling Red Hat Linux. The tradeoff is that reinstalling and reconfiguring a system probably takes more time and