This chapter is from the book
This chapter is from the book
This chapter is from the book
Installing Software
Software comes in many forms, including operating systems, applications, administration tools, patches, configuration scripts, and common everyday utilities. Each of these types of software can be installed in a variety of ways, but your goal as an administrator should be to use the fastest, the most efficient, and the most automated installation methods possible.
It is becoming an old joke among Unix system administrators that you won't find a Windows administrator without his or her handy CD-ROM case close at hand. Though CD-ROMs might be the most convenient installation method for large partitioned networks, they aren't the only way to install software on a Unix system (or a Windows system, for that matter). By understanding the many installation options available to you, you're better able to choose the installation method that's best for your system and environment. In this section, you learn about the following methods for installing operating systems and applications on your Unix systems:
CD-ROM installation
Floppy disk installation
Network installation
Which method you use to install your software depends on a number of factors, including:
Operating system support
Availability of software on specific media
Potential for automation
Speed
This section explains how external factors affect your installation procedures, which in turn will help you decide which method of installation is right for you.
Updating Your Log Book with Software Installation Procedures
You should have begun keeping a log in a notebook or binder when you were installing hardware. This record is even more important when installing software, because the process leaves no physical evidence. For example, there is no easy way to tell if you installed an operating system over the network rather than using a CD-ROM. This information might be important if you later find out about a bug on the CD-ROM or some other critical factor. You should consider logging the following information about OS software:
Versions and patch levels of operating systems installed on each server
Installation procedures for each operating system, including any problems you encountered and their workarounds
Additional software installed on a system that is not covered by your standard installation procedures
Configuration changes you made after installation
Be sure to keep this information up-to-date so others can maintain your systems if you are not available.
Installing from a CD-ROM
The most common installation mechanism is via CD-ROM. A CD-ROM installation is a fairly straightforward process for operating systems, usually as simple as inserting the disc into the drive and powering on the server. For applications, most Unix distributions will automatically mount a CD-ROM you insert into a drive as a local file system, and you install the application by running a script in that file system.
There are three requirements for CD-ROM installations:
Media on CD-ROM
A CD-ROM drive
For operating system installs, firmware (BIOS or equivalent) support for booting from CD-ROM
CD-ROM Speed
CD-ROM installations used to be painfully slow with old single- and double-speed drives in the mid-1990s, but now with 24x-, 32x-, and even 48x-speed drives, CD-ROM drive speed is no longer a factor.
Installing an operating system from CD-ROM can be difficult to automate because it requires the insertion of a disc into each system being loaded. The only simple way to automate a CD install is to use a separate disc for each system. Unfortunately, media licensing costs and copy protection might prohibit this solution, especially if the OS installation requires more than one disc. For applications, usually only the file system on the CD-ROM is necessary—you can copy the contents of the disc onto a file system and copy it to another server or share it with all of your servers. See the section titled "Installing from the Network" later in this chapter for more details.
Installing from a Floppy Disk
The floppy disk is an almost obsolete technology today, but it is still supported by most operating systems and hardware. Floppy disks are useful for installations when installing an operating system on an older machine that does not have or does not support booting from a CD-ROM drive. Unfortunately, most Unix vendors do not offer a floppy disk installation option these days, but Linux distributions do. There are two reasons for Linux making an exception:
Linux runs on old Intel 386-based hardware, some of which do not support booting from CD-ROM.
Most PC hardware cannot boot from the network natively and requires booting from a floppy initially.
A Linux distribution, however, simply cannot fit on a reasonable number of floppy disks; the boot disk provides only the minimum functionality required to boot off of other higher capacity media such as a CD-ROM or the network.
Installing Red Hat Linux with a Floppy
With a single floppy disk, you can boot most modern PC hardware into a Red Hat Linux installer and install Red Hat Linux on the machine over the Internet.
Installing from the Network
Another mechanism that is being used more often is network installation, especially for operating system installations, which can be very labor-intensive. Network installs boot from a common image on a floppy disk, CD-ROM, or even on a remote server on the network, starting installation programs that read the operating system data and configurations from a remote server. This section will detail two of the most popular network installation mechanisms, as follows:
Solaris Jumpstart
Red Hat Kickstart
Network installations have many advantages over other installation mechanisms.
Minimal physical media are required, if any.
You can remotely load a system.
Installation procedures can be automated.
You can create your own custom configurations for different machines.
You can perform many simultaneous installations on servers that support booting from the network.
Over 100Mb Ethernet or Gigabit Ethernet, it is the fastest method of installation available.
Using Install Images
Some administrators advocate the use of install images, which are images of an operating system installation that can be written directly to a disk. Install images offer a very fast way to copy an operating system to a new server and their use is common in Windows desktop environments. This practice isn't recommended for servers (Windows or Unix) due to the vastly different hardware and software requirements of each server. For each server configuration, you would have to maintain a separate install image that could be several gigabytes in size.
Automation is the greatest benefit of network installations. However, complete automation of this process may not be right for your site, depending on the level of customization you need. For example, if you are bringing in a consultant in a week to install an Oracle database and you are unaware of the space needed for the application and the data, you may want to hold off on setting up those file systems until the consultant arrives. But you can still perform other parts of the installation that do not affect Oracle.
If you run into these situations often, you may want to consider creating a base configuration that acts as the lowest common denominator, installing software and configurations that are common to all of your servers. From the base configuration, you can add software and make custom changes that are appropriate for each individual machine (such as installing Oracle on a database server).
If you have enough variation in your server hardware, most network installation systems will allow you to create custom configurations based on the hardware, IP address, and other characteristics of each server on which you are installing the operating system. For example, you could allocate 8GB to the /usr partition on a server with one 20GB disk, but only 4GB on a server with one 10GB disk. Both Jumpstart and Kickstart allow you to create custom configurations, as you will see in the following sections.
That said, network installations may not be for you. Organizations with very few servers may be better off just using CD-ROMs, since there is no economy of scale achieved by implementing this system for just three or four servers. Additionally, sites that do not acquire new hardware very often will generally not install operating systems very often. Unless the initial load involves too many machines for you and your staff to handle in a reasonable amount of time, it may not be worth the time and effort to set up the network installation infrastructure for a one-time use.
Using Solaris Jumpstart
One of the most powerful network installation packages is Sun's Jumpstart for Solaris. Jumpstart is particularly attractive because of Sun's support for network booting in its firmware. After the support infrastructure is set up, you can install Solaris on a freshly loaded machine just by plugging in a power cable, a network cable, and turning on the machine; no CD-ROM or other media is necessary.
There are three types of hosts involved in a Jumpstart installation, as follows:
The client is the machine on which the operating system is to be installed.
The boot server is a server in the client's broadcast domain (usually the same VLAN or subnet) that provides an operating system image to the client to facilitate booting. The boot server first provides network configuration details to the client via BOOTP (IP address, gateway, etc.); it then provides a rudimentary subset of Solaris—enough to boot the client and contact the install server—to the client via TFTP.
The install server is the host that does all the work. It contains all of the available Solaris packages, patches, and configuration information that determine what gets installed on each client and how the clients should be configured pre- and post-install.
Fortunately, the install and boot servers can be consolidated on a single machine, which is handy on smaller or more budget-conscious networks. In larger, subnetted networks with multiple physical locations, administrators commonly have a boot server for each subnet (required for BOOTP) and one or two central install servers. Install servers export the Solaris distribution via NFS (Network File System), which the clients mount after booting to proceed with the installation.
Definition of NFS
NFS is the Network File System, a technology introduced by Sun Microsystems in the late 1980s that allows a server to "mount" file systems shared by remote servers into its own local file system tree. You can then access files on the remote server just as if they were stored on the machine's local file system.
What makes Jumpstart so nice is the logic it uses to decide what to install on the client machine. You can create classes of installations, called profiles, that utilize different partitioning schemes, packages, and post-installation tasks, and assign those profiles to different clients based on rules. Rules are logical combinations of various machine characteristics, including the following:
Disk size
Memory size
Hardware model
IP address
Kernel architecture
Currently installed version of Solaris
With this information, you could tell Jumpstart to partition an 18GB disk differently than a 36GB disk, or give a machine with 512MB of RAM more swap space than one with 256MB of RAM. You could also tell Jumpstart never to install X Windows on any Enterprise 420R servers. The possibilities are endless. See Listing 3.1 for a sample rules file.
In Listing 3.1, machines on network 1.2.3.0/24 are desktop workstations, machines on network 1.2.4.0/24 are compute servers, and everything else is loaded using the generic configuration class. Every rule runs the set_root_pw script after installation, which lets the administrator set the root password manually.
Jumpstart Installs Get Even Easier
All Sun servers now come preconfigured to boot from the network using Jumpstart. This preconfiguration means that if you already have a rule set representing a Netra t1 105 with 1GB of RAM and one 18GB hard drive, you could order 10 Netras, connect them to the network, plug them all in, and have Jumpstart install a preconfigured Solaris distribution automatically, without ever touching a keyboard.
Listing 3.1 A Sample Solaris Jumpstart Rules File
# Example Solaris Jumpstart Rules File network 1.2.3.0 - desktop_workstation set_root_pw network 1.2.4.0 - compute_server set_root_pw any - - generic_server set_root_pw
The most significant limitation to Jumpstart is its network requirements. At least one boot server must be present on every subnet for Jumpstart to be available across your network, because Jumpstart clients (the servers you are loading) broadcast requests to the network looking for bootservers; broadcast traffic is usually limited to local subnets. This can become a significant cost barrier to organizations with many different subnets and a management nightmare as well, since you would be managing not one, but several boot servers. The install servers, however, can be located anywhere on your network, though most people prefer to perform both functions on the same system.
Consolidate Boot Servers
You can consolidate boot servers on multiple subnets in the same physical location by installing multiple network interfaces on a single boot server. Each interface could be connected to a different subnet, providing access from all of your subnets.
Using Red Hat Kickstart
Red Hat Kickstart can install the Red Hat Linux operating system Red Hat on any machine from scratch. Kickstart shares many Jumpstart features, including partitioning, package selection, and post-installation scripts. But, like Jumpstart, Kickstart has its own strengths and weaknesses.
On the upside is Kickstart's large number of data transfer options. With Jumpstart, NFS is your only option. With Kickstart, you can transfer packages and configurations to your client via NFS, FTP, CD-ROM, or another partition on the client's hard disk. The FTP option alone is worth it; with a high-bandwidth connection, you could easily install an entire distribution of Red Hat Linux over the network, using one of the many Red Hat site mirrors on the Internet. All you have to do is provide a URL to the proper configuration file.
Site Mirrors
A site mirror is a site on the Internet that contains a copy of all or part of another site. Its purpose is to spread copies of heavily accessed data, such as software distributions, across the Internet so not everyone overloads a single site with requests for that data. Red Hat has many different site mirrors across the Internet; visit http://www.Red Hat.com/mirrors.html for a comprehensive list.
The Kickstart configuration file can contain a great deal of hardware configuration information, because Linux must support an extraordinary amount of third-party hardware. The Kickstart config file also contains common directives for partitioning, network configuration, and software packages to be installed. Listing 3.2 shows a typical Kickstart configuration file.
Listing 3.2 A Sample Red Hat Kickstart Configuration File
# Installation Language lang en_US # Use DHCP to obtain a network address network --bootproto dhcp # Install over the network from an NFS share nfs --server installer.example.com --dir /usr/local/Red Hat/i386 # Use US keyboard configuration keyboard us # zero out the master boot record zerombr yes # format all existing partitions clearpart --all # partition information # /home will grow to use the rest of the disk, up to 8000 MB part /boot --size 35 part swap --size 128 part / --size 200 part /usr --size 4000 part /home --grow --maxsize 8000 # perform the installation install # use a generic 3-button PS/2 mouse mouse generic3ps/2 # set our timezone timezone --utc EST5EDT # skip X configuration since this is a server skipx # set the root password rootpw changeme # reboot after installation reboot # use shadow passwords with MD5 encryption auth --useshadow --enablemd5 # install boot loader in master boot record bootloader --location=mbr # install packages (groups of packages begin with '@') %packages @ Base @ Mail/WWW/News Tools @ Networked Workstation @ Network Management Workstation @ C Development @ Development Libraries python ncftp bind-utils
Kickstart's Graphical Interface
If you're uncomfortable editing an arcane configuration file, Kickstart has an alternative configuration option. Red Hat now ships with the Kickstart "configurator"—a graphical interface to the Kickstart configuration tool.
Kickstart has drawbacks, too. Kickstart, unlike its Solaris counterpart Jumpstart, requires that you boot from a floppy, CD-ROM, or hard drive; that limitation is a serious disadvantage to this installation package. If you haven't hard-coded the boot options, you must type them in manually to start Kickstart.
This limitation is an unfortunate curse on Linux; its superior hardware compatibility forces it to accommodate the least common denominator—Intel-based x86 desktops. Unlike Sun's OpenBoot (Sun's BIOS), the BIOS on most commodity PC hardware cannot boot off of the network alone, but requires separate software. As a result, you have to insert a boot CD-ROM or floppy into each machine to load Red Hat. As you learned earlier, manually inserting a disc or floppy prohibits efficient hands-free automation of the installation process.
Make Multiple Copies of Boot Media
To avoid constantly swapping floppies or CD-ROMs from machine to machine as you load them, simply make multiple copies of your boot media and give each machine its own copy.
Another major weakness with Kickstart is its lack of machine rules. The server has no way of changing the configuration based on a client's hardware configuration. You have to change the Kickstart configuration file you provide to the client at boot time in order to use a different configuration. This extra step usually isn't too tedious for a single server, but try performing it with 50 servers at once!
These problems aside, Kickstart is still a very powerful way to install Red Hat Linux, and it should be seriously considered in larger environments.
Installing Applications
You can install applications on Unix platforms in a number of ways, depending upon the application and its installation package. Some are packages that install in predetermined locations, while other packages are more configurable. Some application installation packages are built from source code; you can install those apps anywhere you want them. Other installation packages are single files that you just copy to a well-known directory on a server.
Considering the variety of methods of software installation, it's very easy to lose track of what's installed, their dependencies, and how to remove the software. Tracking this information isn't a problem with commercial applications; they usually have well-defined installation and removal procedures. Public-domain and in-house software, however, can be more problematic; each installation procedure can behave differently from the next. The following sections will focus on methods for managing your applications in a consistent manner to reduce the problems caused by different installation and removal procedures.
Log Installation Details
Don't forget to log every piece of software you install. You should keep a separate section in your log book for each system, so you don't have to read the entire log to find out what is installed on a single machine. Some of the details you should record include application name, version number, patches applied, vendor name and Web site, configuration and compilation options (if compiled from source), directory where installed, post-install configurations, and known bugs or problems.
Managing Unpackaged Software Installations
When you install software on your system, you must be able to track the installation and where it deposits all of the application files. The type of application building and installation process you use determines how much effort you must invest in managing the files. You will generally receive applications in one of the following three ways:
Source code
Tar balls (archives created with tar) of the actual programs and configuration files that you must install manually
Packages that are installed by your operating system's package management software
Installing an application through a prepackaged binary distribution requires the least amount of work on your part; the package creates appropriate directories and the application files within them. But there are several reasons you might want to build the application installation from source instead.
You might need to alter the functionality of the application.
The application might install in a suboptimal directory and you might be unable to change it.
You might want to audit the source for security reasons.
You might need to improve performance of the application with more aggressive compiler optimizations.
Some applications are distributed only as source code.
When building from source, it's your responsibility to figure out where to put the software and how to manage the files it contains. As you develop experience in working with these application installations, you'll devise your own systems for managing the process. But building and managing a software repository is an effective approach that many system administrators use for tracking software installations. A software repository is a directory tree where you install all of your software; it keeps everything in one place, making software files easy to find.
The GNU C Compiler
The most popular compiler on Unix is GCC, the Gnu C Compiler. While GCC doesn't always produce executables as optimized as those from your operating system's compiler, the compiler is free and is almost guaranteed to successfully compile most third-party applications. You can download GCC at http://www.gnu.org/software/gcc/gcc.html.
Keep the repository separate from any other software installation locations on your systems. You don't want to mix and match your applications with critical system infrastructure. For example, /usr may not be the best place to put your new software because system software is stored in /usr/bin, system man pages are in /usr/man, and critical system libraries are in /usr/lib. You also should avoid something as common as /usr/local, because a lot of packaged software installs in that location. Ultimately, you should consult the file system standards for your operating system, which define the purpose of each directory on the file system and where certain types of software should be installed. You should be able to find this information in your operating system's documentation.
Make your software repository truly unique to your systems, so it won't be clobbered by system software or third-party packages. One technique for storing your repository is to create a special directory in /usr named after your organization. If your company's name is XYZ, Inc., you may want to name this directory /usr/xyz, and place your files in /usr/xyz/bin, /usr/xyz/man, /usr/xyz/lib, and wherever else you install software files.
GNU Configure Installs Applications Where You Want Them
Most software allows you to specify where it is installed, and the popular GNU configure interface provided with many open-source distributions is well suited to this storage solution. The following GNU configure directive, when executed in a directory containing source code, will ensure that all files are installed using a prefix of /usr/xyz:
/configure --prefix=/usr/xyz
You can read more about GNU configure at http://www.gnu.org/software/autoconf.
Many administrators have found that even when installing software into a separate repository, such as /usr/xyz, they still can't tell which file belongs to which package. Not even the best kept log book can tell you the purpose of every file in your repository. Even more confusing is the versioning dilemma; how can you easily tell which version of software is installed in the repository? One solution to this problem is to partition your repository to further separate it into application and possibly even version directories.
With a partitioned repository, you could, for example, install Perl 5.6.1 in /usr/xyz/perl/5.6.1 instead of /usr/xyz. And you can keep an old version of Perl 5.005_03 in /usr/xyz/perl/5.005_03. Though this solution helps you find all of your apps, many users will have difficulty remembering to type /usr/xyz/perl/5.6.1/bin/perl just to run a Perl interpreter. Symbolic links are the answer to this problem. If you link /usr/xyz/bin/perl to ../perl/5.6.1/bin/perl (repeat for each file in /usr/xyz/perl/5.6.1/bin), it will look like you installed Perl in /usr/xyz/bin, yet the actual application is stored in its own version-specific directory.
Even better, the symbolic links are self-documenting. You can immediately see what package each file belongs to, and swapping in a new version of a program is as easy as relinking the symbolic links. The following truncated listing is an example of the links that would appear in /usr/xyz/bin for a typical Perl distribution:
lrwxrwxrwx GET -> ../perl/bin/GET lrwxrwxrwx HEAD -> ../perl/bin/HEAD lrwxrwxrwx POST -> ../perl/bin/POST lrwxrwxrwx a2p -> ../perl/bin/a2p lrwxrwxrwx c2ph -> ../perl/bin/c2ph lrwxrwxrwx dbiproxy -> ../perl/bin/dbiproxy lrwxrwxrwx dbish -> ../perl/bin/dbish lrwxrwxrwx find2perl -> ../perl/bin/find2perl lrwxrwxrwx h2ph -> ../perl/bin/h2ph lrwxrwxrwx h2xs -> ../perl/bin/h2xs lrwxrwxrwx lwp-download -> ../perl/bin/lwp-download lrwxrwxrwx lwp-mirror -> ../perl/bin/lwp-mirror lrwxrwxrwx lwp-request -> ../perl/bin/lwp-request lrwxrwxrwx lwp-rget -> ../perl/bin/lwp-rget lrwxrwxrwx perl -> ../perl/bin/perl lrwxrwxrwx perl5.00502 -> ../perl/bin/perl5.00502 lrwxrwxrwx perlbug -> ../perl/bin/perlbug lrwxrwxrwx perlcc -> ../perl/bin/perlcc lrwxrwxrwx perldoc -> ../perl/bin/perldoc lrwxrwxrwx pl2pm -> ../perl/bin/pl2pm lrwxrwxrwx pod2html -> ../perl/bin/pod2html lrwxrwxrwx pod2latex -> ../perl/bin/pod2latex lrwxrwxrwx pod2man -> ../perl/bin/pod2man lrwxrwxrwx pod2text -> ../perl/bin/pod2text lrwxrwxrwx pstruct -> ../perl/bin/pstruct lrwxrwxrwx ptked -> ../perl/bin/ptked lrwxrwxrwx ptksh -> ../perl/bin/ptksh lrwxrwxrwx s2p -> ../perl/bin/s2p lrwxrwxrwx splain -> ../perl/bin/splain lrwxrwxrwx widget -> ../perl/bin/widget
File sharing is a given in today's world of high-speed networks, and your software repository provides a powerful tool for sharing software with multiple clients. Creating a single software repository leaves you with only one place to install software, as opposed to installing each piece of software on every machine in your infrastructure. And software repositories make upgrades much easier, because you only have to upgrade in one place.
Different sites use different sharing mechanisms, but most common are NFS and AFS (the Andrew File System, popular in academia). The rule of thumb for deploying these application file servers, especially for NFS, is to use at least one per physical site. That way, you don't have to shuffle large amounts of program data over potentially narrow bandwidth links like a T1.
Using Solaris and Linux Software Package Managers
Most operating system vendors today have some form of packaging that provides a uniform interface for managing software on their systems. Solaris and Linux offer two good examples of these software management packages. Both provide robust software package systems that can install and uninstall software in single atomic operations.
Atomic Operations
An atomic operation is one in which a task is either completed 100% or not at all; the operation never leaves a task partially completed. This guarantee is important for procedures like application installations, where you do not want a half-installed program on your system if you decide to interrupt the installation process. Most package managers attempt to be atomic and will do their best to clean up after themselves if interrupted.
Well-behaved installation packages clean up after themselves, removing all traces of their existence from system configuration files and temporary directories. Another benefit of using these package management systems is dependency checking. Dependency checking prevents an application from installing on a system lacking any necessary dependency applications. Dependency checking also prohibits the removal of an application when that app is depended upon by another one on the system. These dependency guarantees save a lot of trouble down the road as you install and remove more and more software on your servers.
The Solaris package manager is a bare-bones management system, allowing you to create, install, uninstall, and query packages on a system. The Solaris package manager also works hand-in-hand with Jumpstart, so it's easy to install software during Solaris installation. The pkgadd, pkgrm, and pkginfo commands are the primary windows into the Solaris package world, used to install, remove, and query packages respectively. Here is an example of the variety of systems and application software packages installed on a typical Solaris server (viewed by typing pkginfo):
bash$ pkginfo | head system FJSVhea SunOS Header Files for FUJITSU platform specific system FJSVvplr Fujitsu platform links system FJSVvplu Fujitsu usr/platform links application NSCPcom Netscape Communicator application SMCgcc gcc system SMEvplr SME platform links system SMEvplu SME usr/platform links system SUNW1251f Russian 1251 fonts system SUNW1394h Sun IEEE1394 Framework Header Files system SUNW1394x Sun IEEE1394 Framework (64-bit)
And here is more information about a specific package on the example server (viewed by using the –l option to pkginfo):
bash$ pkginfo -l SUNWcar
PKGINST: SUNWcar
NAME: Core Architecture, (Root)
CATEGORY: system
ARCH: sparc.sun4u
VERSION: 11.8.0,REV=2000.01.08.18.12
BASEDIR: /
VENDOR: Sun Microsystems, Inc.
DESC: core software for a specific hardware platform group
PSTAMP: on28-patch20010601062415
INSTDATE: Aug 06 2001 20:50
HOTLINE: Please contact your local service provider
STATUS: completely installed
FILES: 104 installed pathnames
34 shared pathnames
38 directories
53 executables
15999 blocks used (approx)
The most widely used package management system in the Linux world is the Red Hat Package Manager, more affectionately known as RPM. Like the Solaris package manager, RPM has the ability to install, remove, and query for information about packages on a system.
The RPM query interface is robust; it can list the packages installed on a system, their dependencies, the files contained in a package, and even ask what package a particular file belongs to. The rpm command does the work; for example, to query the packages on a system, you can use the –qa option:
bash$ rpm -qa | head filesystem-2.0.7-1 glibc-2.1.92-14 mktemp-1.5-5 libtermcap-2.0.8-25 anacron-2.3-9 mingetty-0.9.4-13 info-4.0-15 sed-3.02-8 fileutils-4.0x-3 popt-1.6-4
RPM can also be more verbose, which is useful for displaying characteristics about a package such as its description, when it was installed, and who created it.
bash$ rpm -qi sed-3.02-8 Name : sed Relocations: /usr Version : 3.02 Vendor: Red Hat, Inc. Release : 8 Build Date: Wed 12 Jul 2000 08:36:22 PM EDT Install date: Fri 13 Jul 2001 05:00:39 AM EDT Build Host: porky.devel.Red Hat.com Group : Applications/Text Source RPM: sed-3.02-8.src.rpm Size : 69413 License: GPL Packager : Red Hat, Inc. <http://bugzilla.Red Hat.com/bugzilla> Summary : A GNU stream text editor. Description : The sed (Stream EDitor) editor is a stream or batch (non-interactive) editor. Sed takes text as input, performs an operation or set of operations on the text and outputs the modified text. The operations that sed performs (substitutions, deletions, insertions, etc.) can be specified in a script file or from the command line.
RPM really excels in its dependency engine—though that excellence has some conditions. Although RPM's dependency checking works well, it works only if all of a package's dependencies were installed with RPM. In other words, RPM knows only about things it's worked with before. If you install Perl by hand (without RPM), and a new RPM package requires Perl, RPM won't see it in its database. In that situation, RPM tells you that the dependency check failed, even though Perl is installed on your machine. This limitation can be very frustrating; fortunately, you can force the installation of packages even when the dependency checks fail, although this does circumvent a lot of RPM's consistency checking.
To better understand dependencies, consider sed, the Unix stream editor. On Red Hat 7.0, it has nine different dependencies; each of these dependencies must have been installed by RPM for the dependency checking to work properly:
bash$ rpm -qR sed-3.02-8 /sbin/install-info /bin/sh rpmlib(PayloadFilesHavePrefix) <= 4.0-1 ld-linux.so.2 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) rpmlib(CompressedFileNames) <= 3.0.4-1
Use Source RPMs to Tweak Software Code
RPM can either install binary packages or build and install from source. If you download a source RPM, you get the original source code, which you can tweak to your heart's content. RPM will take care of compiling and installing everything for you. All of the Red Hat software is available in source RPM format to boot. And you can turn around and build your own custom RPMs that include running scripts at the end, so you can take something you fussed through on one machine and automate it on other machines that need the same setup. You can also build your own RPMs, with or without source code. The process can be quite lengthy, but the "HOWTO" document at http://www.rpm.org/RPM-HOWTO describes it very well.
Installing Operating System Patches on Solaris and Red Hat Linux
As anyone with experience in system administration will tell you, applying patches is a tedious, boring, yet necessary evil. You might be familiar with Windows Service Packs, which are giant collections of patches for Windows and various applications. They're fairly easy to install, but difficult to back out of if there's a problem. Microsoft also provides individual patches on its Web site, but these are sometimes difficult to find, and the frequency of new patch releases makes Service Packs worth using. The same difficulty in keeping up with patch applications exists in the Unix world.
Most operating system vendors provide access to individual patches and "jumbo" patch collections—some are free, and others come with a service fee. Because each operating system has its own patching mechanism, streamlining the application of patches across large heterogeneous networks can be difficult.
Red Hat Linux has no official patching mechanism; it relies on RPM upgrades or source code patch files for its patches. You needn't worry about being up to a certain "patch level," as each patch is distributed individually as RPM packages. For the purposes of installing patches, however, RPM does the trick quite well.
Solaris' patching mechanism, on the other hand, is well organized and separate from other Solaris package management systems. Each patch is assigned a numeric ID, based on the package it is patching, and even the patches themselves have revision numbers. For example, the primary Solaris 8 kernel patch is patch number 108528, and the latest revision of that patch as of this writing is 108528-12.
The showrev command can show you what patches are installed on a system, what Solaris packages they apply to, whether they replace other obsolete patches, and what dependencies they have, as follows:
bash$ showrev -p | head Patch: 109134-10 Obsoletes: Requires: 109318-06, 110386-01 Incompatibles: Packages: SUNWwbapi, SUNWwbcor, SUNWwbcou, SUNWmgapp Patch: 109134-16 Obsoletes: 110618-04, 110627-01 Requires: 109318-06, 110386-01 Incompatibles: Packages: SUNWwbapi, SUNWwbcor, SUNWwbcou, SUNWwbmc, SUNWmga, SUNWdclnt, SUNWmgapp Patch: 110378-05 Obsoletes: 110198-01, 110550-01 Requires: 109279-09, 109472-05, 109740-04, 109742-03 Incompatibles: Packages: SUNWmipr, SUNWmipu Patch: 109889-01 Obsoletes: 109353-04 Requires: Incompatibles: Packages: SUNWkvmx, SUNWkvm, SUNWctu, SUNWhea, SUNWmdb, SUNWpstl, SUNWpstlx Patch: 110370-01 Obsoletes: Requires: Incompatibles: Packages: SUNWkvmx, SUNWkvm, SUNWhea, SUNWmdb, SUNWpstl, SUNWpstlx Patch: 110376-01 Obsoletes: Requires: Incompatibles: Packages: SUNWkvmx, SUNWkvm, SUNWhea, SUNWmdb, SUNWpstl, SUNWpstlx Patch: 108528-05 Obsoletes: 108874-01, 109153-01, 109656-01, 109291-06, 109663-01, 109309-02, 109345-02, 109313-02, 109880-01, 108966-06, 108979-10, 109236-01, 109296-05, 109348-05, 109350-06, 109571-02, 109801-02, 110096-05, 110118-02, 110134-02, 110121-01, 110132-02, 110133-03, 110141-02, 110201-01, 110225-01, 110231-01 Requires: 110383-01 Incompatibles: 109079-01 Packages: SUNWkvmx, SUNWkvm, SUNWcsu, SUNWcsr, SUNWcslx, SUNWcsl, SUNWcarx, SUNWcar, FJSVhea, SUNWarc, SUNWarcx, SUNWcpr, SUNWcprx, SUNWcstl, SUNWcstlx, SUNWcsxu, SUNWdrr, SUNWdrrx, SUNWhea, SUNWidn, SUNWidnx, SUNWmdb, SUNWmdbx, SUNWpmu, SUNWpmr, SUNWpmux, SUNWsrh, SUNWtnfc, SUNWtnfcx Patch: 110369-02 Obsoletes: Requires: Incompatibles: Packages: SUNWkvmx, SUNWcsr, SUNWcarx Patch: 110372-02 Obsoletes: Requires: Incompatibles: Packages: SUNWkvmx, SUNWcsr, SUNWcarx Patch: 110373-01 Obsoletes: Requires: Incompatibles: Packages: SUNWkvmx,SUNWcsr, SUNWcarx
Applying patches in Solaris is a simple process. Patches are available on the Web at http://sunsolve.sun.com and are distributed in Zip format. After unzipping the patch file, the patchadd command will apply a patch; patchrm will remove a patch if possible (you can remove a patch only if you asked patchadd to save old files in a "save space"). As an example, Sun recently released a patch to address a buffer overflow bug in the login program (patch 111085-02). Here's how it was applied:
# ls -l total 56 drwxr-xr-x 3 root other 4096 Sep 21 14:32 108434-03 drwxr-xr-x 3 root other 4096 Sep 21 14:38 108435-03 drwxr-xr-x 7 root other 4096 Sep 5 19:24 108693-07 drwxr-xr-x 5 root other 4096 Aug 15 01:50 109189-03 drwxr-xr-x 3 root other 4096 Feb 27 2001 110896-01 drwxr-xr-x 5 root other 4096 Mar 1 2001 110901-01 drwxr-xr-x 3 root other 4096 Dec 13 14:47 111085-02 # patchadd 111085-02 Checking installed patches... Verifying sufficient filesystem capacity (dry run method)... Installing patch packages... Patch number 111085-02 has been successfully installed. See /var/sadm/patch/111085-02/log for details Patch packages installed: SUNWcsu
Sun also distributes clusters of patches. One such cluster is the recommended patch set, available on the SunSolve site listed previously. This patch set is a Zip file of all of the patches Sun recommends installing on all Solaris systems. These patches usually address bugs and security issues, and not new functionality. A script in the cluster, called install_cluster, handles the installation of all of the patches for you, in order of their dependencies.
A similar cluster called a Maintenance Update is also provided by Sun (both at SunSolve and on CD-ROM for support customers). Maintenance updates look exactly like the recommended patch clusters and are installed in a similar fashion (with install_mu instead of install_cluster), but they are much more comprehensive than the recommended patches. Maintenance updates bring the system up to a known patch level that you can identify to Sun support engineers, as in, "Oh yeah, I'm running Solaris 8 with Maintenance Update 4."
Prepare for Downtime When Applying Patches
Patches replace running applications, libraries in use, and even the kernel. When applying patches, therefore, you run the risk of corrupting data that is in use, or of pulling a file out from under a running program. To avoid these problems, always patch servers in single-user mode, to guarantee that nobody else is logged onto the system and no applications are running. If this isn't possible in high-availability environments, it may be acceptable to you to shut down all unnecessary services, have everybody log out of the system, and then back up application data and apply the patches. In either case, when applying patches to system files, libraries, or the kernel, you usually need to reboot the system, so be prepared for some amount of downtime.
When patching a large number of systems, you may want to store those patches on your application file server and share the patch files among all of your machines. This makes it easy to install patches from one central location rather than copying hundreds of megabytes of patches to individual systems.
Test Your Patches
Patching many systems at once can also cause a massive outage if something goes wrong. You should test patches first on test servers, commonly called sandbox environments. You can read more about sandboxes in Chapter 7, "Patches, Upgrades, and Decommissions."