UNIX System Administration Handbook - Evi Nemeth [479]
Managing software across systems
The management of your local software and vendor patches can become very complex as the size and diversity of your site increase. A number of tools are available to help, both commercial configuration management systems and cleverly applied standbys such as rdist , rsync , and make .
See page 515 for hints on distributing files.
A site usually has several different combinations of hardware architectures and operating systems. In most cases, one machine’s configuration is similar to that of other machines of the same type and software release, with some individual customizations sprinkled on top. At a small site you can organize your localizations poorly and not even notice, but at a large site, you need to be able to do the work once and somehow distribute it to all systems that need it.
There are two fundamental issues:
• The organization of the directory hierarchy of software being maintained
• The distribution mechanism for getting software from the prototype machine onto other hosts
Some sites use the automounter or amd to hide the real location of software packages from users and present a consistent view (directory path) to everyone. Others have a central repository and consistent directory tree for each architecture. Throwing everything in /usr/local/bin does not work; programs from different packages often present naming conflicts.
See page 504 for more information about automounters.
Two packages developed by sysadmins to cope with this complexity and reduce manual labor are cfengine and SEPP. cfengine , by Mark Burgess at Oslo College in Norway, is a high-level language for describing machine configurations. It puts all the config data in one spot. cfengine does diff s and then synchronizes client systems to the master. cfengine is distributed by the GNU project and runs on each of our four example systems. It’s available from www.iu.hioslo.no/cfengine.
SEPP, by Tobi Oetiker of the Swiss Federal Institute of Technology (ETH), is a packaging system for installing and sharing software. SEPP is also distributed under the GNU GPL and is available from www.ee.ethz.ch/sepp. You can obtain more details on both of these packages from the references at the end of the chapter.
Many vendors provide a way to automate and standardize the installation of operating system or add-on software. We do not cover them here, but Table 27.1 provides pointers to additional information.
Table 27.1. Software installation tools by vendor
Upgrades
Upgrading is painful and disruptive, but it is often necessary. Don’t put off the upgrade too long, especially if you need it because you underestimated the number of hits on your web server by a few orders of magnitude. Find a balance; you don’t want to apply every upgrade that your vendor supplies, because each upgrade usually breaks something. On the other hand, the longer you wait between upgrades, the more things you will have to fix manually.
Upgrades of the operating system or of major software packages should first be installed on the sysadmin’s desk. Test new releases for a period of weeks or months before moving them to the production environment. Invite your developers to try the new system out on your desktop so that they can make sure the tools they use are installed and working. Test each commercial application to make sure that licensing issues have been addressed.
The most important rule of upgrading is to be sure you have a complete, readable backup of the existing system before you begin the upgrade. It’s also good to have a backout plan if the upgrade should fail. Backing out is easiest if you have a hot spare machine running the old code and data, or at least a spare disk with the old system on it. We have been burned7
before, so