The command to create a package is make package. This will install the program on the local machine and create a package in that port's directory. Simply copy this package to other systems and run pkg_add to install it.

You can even set up an anonymous FTP server (see Chapter 12) and have a local master package repository. Remember the PACKAGESITE environment variable? Set that to a path on your anonymous FTP server and put your custom packages there. You can then use pkg_add −r on your other machines, and they will automatically grab the customized packages.

Changing the Install Path

If you have dozens, or even hundreds, of FreeBSD systems, all with mostly identical configurations, you might find the default port or package installation path of /usr/local problematic. In many large server farms, /usr/local is reserved for programs that are unique to the individual machine, and other software packages that are used by every system in the server farm are expected to be installed elsewhere.

A common alternative to /usr/local is /usr/pkg, which you can set for your system with the PREFIX variable:

...............................................................................................

# make PREFIX=/usr/pkg install clean

...............................................................................................

When the port is installed, it will go into your chosen location.

Setting Make Options Permanently

If you get sick and tired of typing the same options repeatedly when building ports, you can list your options in make.conf to have them automatically used whenever you install a port. See the section on make.conf in Chapter 9 for details.

Note While we're at it, /etc/make.conf is scanned any time you run make. This means that any options you set there are applied to ports. While features like CPUTYPE might not make a difference for you, it's possible that they will. In any event, it's a possible source of confusion, and you should at least be aware that it exists.

[4]SKIP is Sun's Secure Connectionless Internet Protocol (the acronym stands for Simple Key−management for Internet Protocols). It is a wonderful virtual private network (VPN) protocol that has unfortunately fallen into disfavor in the face of IPSec. This is yet another example of the market bludgeoning cool technology into the grave.

Upgrading Ports and Packages

The software−upgrade process can be very simple or a complete nightmare, but with a bit of preparation you can avoid many common pitfalls. The following list of suggestions assumes that you're upgrading an Internet server and that you have actual users depending on it. (If you're upgrading your laptop, you can consider your user notified before you start.)

245

1.The first thing to do when upgrading is to be sure that you have a package of the older version of the software available. If things go wrong on a production system, you'll want to be able to fall back to the older version very quickly. If you've installed the software from CD−ROM, check that you still have that disk; if you installed via FTP, download the same package and keep it handy.

2.If at all possible, test the upgraded software on a nonproduction system. Production server upgrades can give even seasoned administrators white hair and worse tempers. Successfully upgrading once makes further upgrades much easier and faster.

3.Make sure you have a system backup. See Chapter 3 for details on how to do this with either a tape or a filesystem.

4.Get your upgraded software, preferably via a package you have built on your test machine. (That way, you know that the port actually builds and installs.) Otherwise, build the software from a port using make build. Don't do the actual make install, just make build to confirm that you can actually compile the program cleanly.

5.Notify your users that you will be upgrading the service at such−and−such a time, and that the program or machine will be unavailable.

6.At the scheduled time, do a make deinstall or pkg_delete on the old package, then a make install on the new port. Be ready to fall back to the older version if this doesn't work!

The most frequent problem people have when upgrading is determining which software on their system needs upgrading. My general rule is that things that work should not be upgraded just because a newer version is available. This holds true especially for large, complicated software packages, such as some of the newer desktop window managers.

Still, you may find that even though everything is working just fine, a newer version of a piece of software addresses a problem you have or provides needed functionality. You can make your life easier by upgrading your ports tree to allow you to easily install that newer piece of software.

Upgrading the Ports Collection

The FreeBSD upgrade process also handles upgrading your ports tree. You can use CVSup and the ports−supfile configuration to upgrade your ports to the latest version—or, indeed, to any version you choose.

To begin, you'll need to install CVSup as described in Chapter 6, and edit the ports−supfile to use a particular CVSup mirror. When you're done, run it with this command:

...............................................................................................

# cvsup ports−supfile

...............................................................................................

CVSup will crawl over your ports tree, comparing each file with the version on the CVSup mirror you've chosen, and make changes in your files as needed. When it finishes, you'll have the latest version of the ports tree.

Once you've finished upgrading your ports collection, you should upgrade your index and your readme files. To do so, go to /usr/ports and type this:

246

...............................................................................................

# make index && make readmes

...............................................................................................

Note Both of these commands (make index and make readmes) take quite some time to complete. By using the &&, you tie them together; when the first command completes successfully, the second command will run. This saves you the trouble of going back in half an hour and typing the second command.

The ports collection upgrade doesn't remove old work directories. If you have installed ports and haven't run make clean, the work directories and older source code will still be around, together with the status−tracking hidden files. If you run make in these ports, the hidden files will show that the port is built and will refuse to run, and you'll need to run make clean to build these ports.

Ports Collection Upgrade Issues

The problem with upgrading the ports collection is that any collection of software is intended to be used as a cohesive whole. If you have an older version of a commonly used tool that your new software requires, you might have to upgrade it as well as programs that depend upon it. The danger is that a simple upgrade can quickly become a cascading series.

Of course, FreeBSD is not the only operating system that suffers from this problem. Every software package on every operating system platform has it. (In Windows you frequently see this manifest as DLL conflicts, unexplained program crashes, or any other weird and unpleasant behavior.) Excellent software design can minimize but not eliminate this problem. Unfortunately, excellent software design is rare.

Checking Software Versions

On a single−purpose machine, the daisy−chain upgrade isn't that difficult; after all, a Web server doesn't generally have hundreds of software packages installed. However, a workstation does, and even my laptop usually has over 200 entries in /var/db/pkg! (You know, I should really go through and uninstall what I don't use anymore; do I really need that little daemon that follows my mouse?) So what do you do if your system has complex software dependencies?

FreeBSD has a software−version−checking tool called pkg_version(1). Pkg_version compares the version of the software you have installed with the version number in /usr/ports/INDEX and, if your INDEX file is up to date, you're all set. (You did follow my advice in the last section and update your index and readmes, didn't you? Of course you did. You're not the type of person that would go drop some hard−earned cash on a computer book and then ignore it, are you? Of course not.)

A basic version check might look like this:

...............................................................................................

247

...............................................................................................

Reading down the list of comments next to each piece of software, it's easy to see that most of the software on this system is the latest version. But take a look at the entry for ispell−1.2.10. The message shows that the port is out of date, and at some point you might want to update that program. You need to decide on your own if the package is important enough for you to spend the time needed to upgrade it.

Now, since I personally installed every piece of software on this system, I'm familiar with it, and I know how important everything is. I know that ispell is a spell−checker and that its importance in the grand scheme of Web serving is minimal at best. I'm not going to worry about it. On the other hand, the sudo−1.6.3.7 package is a security tool used to control user privileges; correct operation of this program is absolutely vital. If a newer version is available I must investigate and probably upgrade.

The entry for cvsup−bin−16.1 with the message of "orphaned: net/cvsup−bin" tells us that there is no entry for this piece of software in /usr/ports/INDEX, and hence no port for this package. I installed this port from a package; no port is available.

Automatically Checking Software Versions

You can add an automated software−version check to your weekly status email. Just add the following line to /etc/periodic.conf:

...............................................................................................

weekly_status_pkg_enable="NO"

...............................................................................................

Create /etc/periodic.conf if you don't have one. For full details on /etc/periodic.conf, see Chapter 9.

Hints for Upgrading

Most of the software−maintenance process is based upon knowing what your server is supposed to do. If you are the only administrator of a machine, things are very simple. Once you start having multiple administrators, however, you'll find that keeping track of this information becomes very difficult. I cannot stress highly enough the importance of keeping a server log for every system on your network! Even a text file, /etc/changes, where you jot down things like "mwlucas, 5−15−01: Installed sftp for client bufar@absolutebsd.com" can save you hours of pain later as you try to figure

248

out why some trivial change is causing things to go haywire. It can also keep another administrator from calling you up at 3 AM and asking why the heck the system doesn't work with the default settings.

When you decide to upgrade on a production system, map out your changes. You can use pkg_info −aR to see which packages require other packages.

The general rule of thumb is to upgrade your dependencies first. Those packages that are required by other packages should be the first to be upgraded and tested. After all, if something's wrong with lower−level software, everything that depends on it will fail.

You can use pkg_delete −f to remove dependencies, and then install the newer versions from ports or packages. Then follow the chain upward, upgrading newer versions as required. Again, you can try to run a software package with a newer version of a dependency, but it might not work.

The /usr/ports/sysutils/portupgrade tool is worth considering, because it can handle some of these tasks automatically. Still, you need to understand and be able to deal with conflicts and dependencies yourself.

249