FreeBSD OS Upgrading Notes
I’m working on upgrading the OS on a FreeBSD server currently. The server is running version 4.9, and I want to move to version 6.1.
The docs for FreeBSD discuss migration issues. Apparently, I could get there by upgrading in place to version 5.3 or 5.4, and then do a second in place upgrade to 6.1. Somehow, though, that doesn’t sound very appealing to me. The alternative, as they say, is the “binary upgrade”: backup the old data, install the new system, and restore user data. The move is also being used to increase disk space; we’re going from an 80GB system disk to a 250GB system disk. So the install part of the binary upgrade is a cinch: just put the new system on the new disk. The user data is not even threatened.
Actually, it turns out that I have the time to do this at home, and I’m just installing the system to a 20GB scratch disk I have handy. I will clone it to the 250GB disk later, a process that I expect to take less than an hour. To do that, one makes a minimal install of the FreeBSD system, setting up the disk partitioning as desired, then uses dump and restore to transfer the contents of the smaller disk to the larger one. Exchange cables after that, and one is in business.
OK, but what about figuring out the software that needs to be installed on the new system in order to have the functionality of the old system? I’ve done a couple of upgrades before where it was only after the change was done that I came to realize that something had been left out of the install. I’m looking for a better way to approach this, and I think I’ve found it. FreeBSD has a handy utility called “pkg_version” that will list all the installed software packages on the system. I ran that on the old system and with the aid of a couple of Perl scripts created a shell script to actually go and install every package via the ports system.
If you haven’t heard of FreeBSD’s port system, here’s the idea. There’s a directory tree under /usr/ports that organizes available ported software packages into functional categories like “www”, “databases”, and “textproc”. What exists in the directory is not the software itself, but rather the instructions needed to go out and get the software from the Internet, configure it for FreeBSD, make the software (usually involves compiling the source code and installing any needed other packages that the current package depends upon, if they aren’t already in the system), apply any patches to it, and register it with the packages database. The whole thing takes less than 100MB to start with. You can choose to “clean” after an install to keep space usage down, or keep the source code around. I usually do the latter, so a check of ports on the old system shows it is using about 3GB of hard disk space. That translates into about 5 CD-ROMs of data, or less than fits comfortably on a single DVD.
Anyway, the idea is to have the new system run the script that will go out and try to install every package that I had installed on the old system. There are the occasional requests for input from the user for choices of configuration for individual packages, so I’m looking over at the console monitor to see if the process has paused every few minutes. I started the process about 11 AM on Saturday, and it is currently working on about the one hundredth package out of 246 or so. It might have been already done if I were using a speedier machine to do the job, but I commonly use an old 500MHz HP e-Vectra for base installs of FreeBSD simply because of the ease of swapping out system disks in the thing and the small form factor. So I expect the process to be done by sometime on Monday.
After that, I’ll need to transfer over configuration data and user data. I plan to do this in two steps. First, I will have the system set up as a second server, and copy user data over. This will include doing “mysqldump” to offload the old databases in a form that can be transferred to a different version of the mysql software. Second, I’ll set up the configuration to match the old system: login data for user accounts and configuration files for system services like the Apache web server and the Samba file sharing service. The result should be a system that acts like the old server, but with the new software basis. Once that is confirmed, a final round of transfers will be done to bring the new server up to date on databases, email lists, and other files. The old system disk will be removed, and the new one put in. The machine configuration for name and IP address will be made to identify it as the production server, and the process will be done.
