Appendix A. Software Sources

Much of this software requires root privileges and could contain dangerous code. Be sure you get your code from reliable sources. Considerable effort has been made to provide canonical sources, but no guarantee can be made for the trustworthiness of the code or the sources listed here. Most of these programs are available as FreeBSD ports or Linux packages. I have used them, when available, for testing for this book.

A.1. Installing Software

I have not tried to describe how to install individual tools in this book. First, in my experience, a set of directions that is accurate for one version of the software may not be accurate for the next version. Even more likely, directions for one operating system may fail miserably for another. This is frequently true even for different versions of the same operating system. Consequently, trying to develop a reasonable set of directions for each tool for a variety of operating systems was considered unfeasible. In general, the best source of information, i.e., the only information that is likely to be reliable, is the information that comes with the software itself. Read the directions!

Having said this, I have tried to give some generic directions for installing software. At best, these are meant to augment the existing directions. They may help clarify matters when the included directions are a little too brief. These instructions are not meant as replacements.

Installing software has gotten much easier in the last few years, thanks in part to several developments. First, GNU configure and build tools have had a tremendous impact in erasing the differences created by different operating systems. Second, there have been improvements in file transfer and compression tools as well as increased standardization of the tools used. Finally, several operating systems now include mechanisms to automate the process. If you can use these, your life will be much simpler. I have briefly described three here -- the Solaris package system, the Red Hat package manager, and the FreeBSD port system. Please consult the appropriate documentation for the details for each.

A.1.1. Generic Installs

Here is a quick review of basic steps you will go through in installing a program. Not every step will be needed in every case. If you have specific directions for a product, use those directions, not these! (Although slightly dated, a very comprehensive discussion can be found in Porting Unix Software by Greg Lehey.)

Locate a reliable, trustworthy source for both the software and directions. Usually, the best sources are listed on a web page managed by the author or her organization.
If you can locate directions before you begin, read them first. Typically, basic directions can be found at the software's home page. Frequently, however, the most complete directions are included with the software distribution, so you may need to retrieve and unpack the software to get at these.
Download the tool using FTP. You may be able to do this with your web browser. Be certain you use a binary transfer if you are doing this manually.
Uncompress the software if needed. If the filename ends with .tgz or .gz, use gunzip. These are the two most common formats, but there are other possibilities. Lehey's book contains a detailed list of possibilities and appropriate tools.
Use tar to unpack the software if needed, i.e., if the filename ends with .tar. Typically, I use the -xvf options.
Read any additional documentation that was included with the distribution.
If the file is a precompiled binary, you need only move it to the correct location. In general, it is safer to download the source code and compile it yourself. It is much harder to hide Trojan horses in source code (but not impossible).
If you have a very simple utility, you may need to compile it directly. This means calling the compiler with the appropriate options. But for all but the simplest programs, a makefile should be provided. If you see a file named Makefile, you will use the make command to build the program. It may be necessary to customize the Makefile before you can proceed. If you are lucky, the distribution will include a configure script, a file that, when executed, will automatically make any needed changes to the Makefile. Look for this script first. If you don't find it, look back over your directions for any needed changes. If you don't find anything, examine the makefile for embedded directions. If all else fails, you can try running make without making any changes.
Finally, you may also need to run make with one or more arguments to finish the installation, e.g., make install to move the files to the appropriate directories or make clean to remove unused files such as object modules after linking. Look at your directions, or look for comments embedded in the makefile.

Hopefully each of these steps will be explained in detail in the documentation with the software.

A.1.2. Solaris Packages

In Solaris, packages are directories of the files needed to build or run a program. This is the mechanism Sun Microsystems uses to distribute software. If you are installing from a CD-ROM, the files will typically be laid out just the way you need them. You will only need to mount the CD-ROM so you can get to them. If you are downloading packages, you will typically need to unpack them first, usually with the tar command. You may want to do this under the default directory /var/spool/pkg, but you can override this location with command options when installing the package.

Once you have the appropriate package on your system, you can use one of several closely related commands to manage it. To install a package, use the pkgadd command. Without any arguments, pkgadd will list the packages on your system and give you the opportunity to select the package of interest. Alternately, you can name the package you want to install. You can use the -d option to specify a different directory.

Other commands include the pkgrm command to remove a package, the pkginfo command to display information on which packages are already installed on your system, and pkgchk to check the integrity of the package.

For other software in package format, you might begin by looking at http://sunfreeware.com or searching the Web for Sun's university alliance software repositories. Use the string "sunsite" in your search.

A.1.3. Red Hat Package Manager

Different versions of Linux have taken the idea of packages and expanded on it. Several different package formats are available, but the Red Hat format is probably the most common. There are several programs for the installation of software in the RPM format. Of these, the Red Hat Package Manager (rpm) is what I generally use. Two other package management tools that provide GUIs include glint and gnorpm.

First, download the package in question. Then, to install a package, call rpm with the options -ivh and the name of the package. If all goes well, that is all there is to it. You can use the -e option to remove a package.

A variety of packages come with many Linux distributions. Numerous sites on the Web offer extensive collections of Linux software in RPM format. If you are using Red Hat Linux, try http://www.redhat.com. Many of the repositories will provide you with a list of dependencies, which you'll need to install first.

A.1.4. FreeBSD Ports

Another approach to automating software installation is the port collection approach used by FreeBSD. This, by far, is the easiest approach to use and has been adapted to other systems including OpenBSD and Debian Linux. The FreeBSD port collection is basically a set of directions for installing software. Literally thousands of programs are available.

Software is grouped by category in subdirectories in the /usr/ports directory. You change to the appropriate directory for the program of interest and type make install. At that point, you sit back and watch the magic. The port system will attempt to locate the appropriate file in the /usr/ports/distfiles directory. If the file is not there, it will then try downloading the file from an appropriate site via FTP. Usually the port system knows about several sites so, if it can't reach one, it will try another. Once it has the file, it will calculate and verify a checksum for the file. It next applies appropriate patches and checks dependencies. It will automatically install other ports as needed. Once everything is in place, it will compile the software. Finally, it installs the software and documentation. When it works, which is almost always, it is simply extraordinary. The port collection is an installation option with FreeBSD. Alternately, you can visit http://www.freebsd.org. The process is described in the FreeBSD Handbook.

When evaluating a new piece of software, I have the luxury of testing the software on several different platforms. In general, I find the FreeBSD port system the easiest approach to use. If I have trouble with a FreeBSD port, I'll look for a Linux package next. If that fails, I generally go to a generic source install. In my experience, Solaris packages tend to be hard to find.