RHEL Migration

Posted Sat Sep 3, 2005 in

My main linux workstation, shelob.ce.ttu.edu, ran RedHat Linux 9.0 for three years. (Shelob has been running RedHat linux since 1995.) I maintained the license so the security and maintenance updates would be posted to shelob, but did not upgrade the operating system. RedHat 9.0 is no longer fully supported—RedHat has moved on to its Enterprise solution.

Although I received new media last year when I updated my subscription, I found the prospect of upgrading the system, which requires a bare-metal install, too daunting to begin. I knew some work would be required. I didn’t have a lot of personal resources. Depression will do that to you.

I’m much better now, and I’ve been planning a new install off-and-on over the summer months. But work was too intense to give me the day I needed. Finally, pending replacing my other linux box, balrog, I decided that yesterday would be the day to upgrade shelob. I must have experience with the new system before bringing a production system on line.

I prepared for the move by writing a migration plan. I can’t stress the importance of a written plan too strongly. I suppose that if you do this work day-in and day-out, a written plan is not necessary. But operating system migration is a significant process and a missed step could result in lost data—not good! After writing the plan, I let it age for a couple of days and reviewed it. I could think of nothing else that needed to be done.

Because there are only two users (one is me), notifying my users of the move was trivial. I taught my classes for Friday, worked on necessary things for a couple of yours, then headed home for a bite to eat and a trip to CompUSA for a couple of spare parts needed when I popped the box. I finally started at 1600.

I shut down the httpd and sendmail processes and made tarballs of the /home/"user" files, which really included just me and the httpd directory. The other user had no files in her workspace. Those tarballs were secure-copied (scp) over to a staging area on balrog. Then I shutdown shelob, tore it down, and cleaned it out. It was time for a good dusting. I marked off those tasks.

I pulled the old ATA drives (one of them was manufactured in 1998!) and installed a SATA card and a single SATA drive. I put the box back together and started the install. Linux would boot from the install CD, but died after finding the SATA card. After a couple of attempts, I decided I had a hardware incompatibility, pulled the SATA card/drive, and reinstalled the ATA drives, which were known good.

I’ve decided I want hardware RAID in shelob. Now I need to find the required hardware and ensure that it’s supported by RHEL.

The system booted from the install CD, found all of the drives in the system, then offered to repartition the drives for me. I reviewed the partition layout, made some changes to the list of software to be installed, and punched the “go-ahead” button. The install took about 30 minutes and went off without a hitch. I marked off that task.

While the install bobbed along, I remembered I had an emergency Pepsi in the refrigerator! The A/C was shut down at 1600 (university cost-saving program) so the cold drink was welcome!

When I rebooted shelob, the boot process hung on startup of the XFree86 window system. I attempted to secure shell (ssh) into shelob from balrog with no success. I hard-booted shelob to test again but the system hung on startup of XFree86 again. I couldn’t ssh from balrog again.

I put the install CD in the drive and booted from it, started the rescue process, and set shelob to boot at init 3, the text-based interface. Then the next problem showed up—I mistyped the root password during installation. No wonder I couldn’t ssh from balrog! So, another boot from the install CD was required; I reset the root password so I could get into the system. While at it, I set the default boot state to init 3 (text only) to prevent the system from starting (or trying to start) the XFree86 system.

I spent the next hour or so trying to reconfigure XFree86 to recognize the ATI Radeon 7500. I’ve had problems with Radeon configurations before. A web search turned up others’ problems with Radeon installs, but no solutions.

It pays to have a spare computer hooked to the ‘net while working on a system like this. I find I’m researching solutions to problems every time I do an install like this (regardless of operating system).

After an hour of beating my head on that problem, I remembered I had a Matrox G550 in the parts cabinet, so I shut shelob down, tore open the box, pulled the Radeon, and installed the G550. Linux Matrox support has been rock solid since day one. I ran a Matrox Millennium in shelob for years without problems. (I think I still have that card!) I reran the XFree86 configuration utility, tested the resulting configuration file—got a gray screen and black “X”—so I had a working configuration. When I ran startx from an xterm, the GUI came up so I’d solved that problem. It pays to have a few spare parts in the cabinet.

Rather than reboot or re-@init@ the system again, I left XFree86 running from the startx and let up2date run and download the updates from the past year. That was a 650MB download. The up2date system hung a couple of times during the transfer and had to be restarted. Fortunately up2date caches its downloads so it doesn’t start the download process over from scratch if it crashes. That would be b-a-a-a-d…

While up2date was doing its thing. I created a user for myself, changed my password, and restored the files for my directory and the httpd directory from the staged tarballs. I marked off that task.

While the downloads were still coming down the pipe, I reconfigured the Apache web server (httpd) to work with my preferred directory layout and custom 404 page. I hit a small wrinkle in that effort, but my backup copy of the old httpd.conf file saved the day. I restarted the daemon, tested the results, and marked off that task. When I finished, up2date was still downloading.

I started working on sendmail. Sendmail installs always give me gas. RedHat configures sendmail to handle local mail only out-of-the-box. I can never remember the series of steps required to get a new RedHat sendmail install to talk to the rest of the world. Google is my friend, however, and I found the required information—it’s one line in the sendmail.mc file. However, sendmail still wasn’t listening (netstat <del>nl) to port 25.

What followed was a couple of hours spent trying to track down the problem. I finally found it after multiple false starts. The sendmail configuration was correct, the firewall settings were correct-it was a “YES” for a “yes” that was wrong in a configuration file in the sysconfig directory. (I finally found this error about 2300 after driving home with everything else completed. It was a “D’Oh!” moment…)

Finally, up2date finished downloading and installing all of the updates from the last year. I rebooted shelob with a new kernel (and a new OS), checked that things were working, called home, put everything away that was strewn over my conference table, packed up, and headed home about 2230. The process took me about 6-1/2 hours. It was a little longer than I’d planned, but I ran into a couple of wrinkles in the process that required some research and some thought. Everything was marked off that stage of my migration plan. Now we’ll see if the system is stable.

Update: I found two problems remaining to be solved this morning. First, RSA authentication for ssh logins wasn’t working. Second, procmail wasn’t processing inbound emails. I tracked the problems down to a combination of nmh installed in the wrong directory (/usr/local/nmh instead of /usr/local/bin) and the permissions of the .ssh directory and .procmailrc file were incorrect. Once rectified, everything seems to be working as expected.