UNIX System Administration Handbook - Evi Nemeth [480]
• Be very careful with version x.0, from any vendor.
• Read the mailing lists for your vendor’s products to learn from the experience of the bleeding-edge crowd and to hear of any major pitfalls.
• Announce triple the downtime you expect the upgrade to take.
• Have a backout plan and know how long it will take to execute it.
• Have a schedule and a drop-dead time at which you will back out the upgrade and try again another day. Stick to your schedule.
The following story from a large telecom company illustrates some typical problems (and one way to let management know how long and hard you have worked). The site was planning an upgrade that required both an OS upgrade and a major upgrade to a particular application. After reviewing the software involved and doing some research on the net, the sysadmins indicated that three days were required to perform the upgrade. They were given from 7:00 p.m. Friday until 6:00 a.m. Monday.
The initial upgrade attempt had to be cancelled when the sysadmins learned that the OS vendor no longer recommended the use of the CD set they had; it was too buggy. A good set of CDs arrived and they began. Unfortunately, the new application and the new OS interfered with each other, turning what was typically a few hours of work into a three-day fiasco. After about 60 hours of almost nonstop work, they finally had the OS installed. Management, including one vice president, was pleased that the upgrade was completed—but also quite tired, as they had requested status calls every 3–4 hours throughout the entire three-day process.
In hindsight, this is an example of an upgrade that probably should not have been performed until there was experience in the community (or at least on the sysadmins’ desks) with the new version of the application running on the new version of the OS. It’s always a bad idea to have a production box be your first example of an OS/application pair.
Useful third-party software
Our list of useful software has a few entries that we consider so important that we would call them mandatory for all machines. Some of the other items may be necessary or useful only on selected machines. However, the price of disk space these days almost makes it easier to install everything everywhere and maintain the consistency of the local software tree. Table 27.2 shows our list of must-haves.
Table 27.2. Essential third-party software packages
a These programs are shipped with each of our example systems, but they are not necessarily installed by default on all of them. They may not be included in other vendors’ basic installations either.
Table 27.3 shows our picks of nice-but-not-essential programs; we’ve divided the table into a sysadmin section and a general user section.
Table 27.3. Useful third-party software packages
a. The BIND package includes dig and nslookup .
All of the programs listed in Tables 27.2 and 27.3 are free. Most of them are available on the web, but a few are still distributed only through FTP. Use a search engine to locate them, or see if a pointer is given in this book (check the index to see if a command is discussed elsewhere).
The Red Hat Linux archives contain a lot of third-party software bundled as RPM (Red Hat Package Manager) distribution files. You can use the rpm command to manage and install them; it’s just like the pkgadd program in Solaris. Red Hat packages are far more convenient than most software’s native compilation and installation procedures; always check to see if there’s an RPM version of a command available before going off to find the original.
FreeBSD’s /usr/ports directory contains a makefile that knows how to fetch and build several thousand different software packages. If you go to /usr/ports and type make package-name, the system will look in its makefile for the original location of the software, download it from the Internet, then compile and install it. It’s a very slick system. It does need to be updated regularly, however, since both the contents