Server upgrade

I upgraded my server from Fedora Core 4 to Fedora Core 5 using yum. After going through all the .rpmnew and .rpmsave files and fixing configuration files, most things are working. A couple of annoyances:

  • It no longer puts items in /etc/fstab for usb storage devices, so I have to find what device the disk has been assigned and mount it manually. I’m hoping I can find a solution to that.
  • Can somebody please tell me why the people who wrap the PostgreSQL binaries in an RPM can’t figure out how to do a pg_dumpall in the %pre at the beginning of the process, and a restore of the backup in the %post at the end? The init.d script refuses to start up if you have an 8.0.x database on an 8.1.x PostgreSQL, so after the upgrade you have to go “oh, shit, the last backup I made was …” and restore it. If you’re not the sort of person who dumps the database every night to a file on your USB disk, you’re screwed.
  • WordPress was refusing to clear out comment spam because of some index issue, and then claimed that the table had “crashed”. I had to fumble around with mysql_upgrade, mysqlcheck, and myisamchk to get that straightened out.

So far, knock wood, those are the only issues. The PostgreSQL one is, to me, indicative that the Fedora Core team don’t really care about preserving data. I haven’t tried, but I bet you anything the Debian people don’t just say “oh well, if you didn’t back up you’re screwed.”

3 thoughts on “Server upgrade”

  1. Debian allows concurrent installs of multiple postgresql versions, so you can upgrade at your own pace.

  2. I see two problems with pg_dumpall being done by the RPM. First of all, who should pg_dumpall log in to the database as? It’s definitely not unheard of for my postgres user to have a password, or only be trusted for template1. Second, where should it dump to? It seems to me the result of a pg_dumpall might be very large, and the final size of the resulting dump probably cannot be determined beforehand. It probably wouldn’t do to fill up a filesystem in the middle of something like a yum upgrade (especially not when going from one distribution to another).

    James says that Debian lets you install multiple versions of PostgreSQL at once. That sounds like a pretty good idea. The only other idea I can think of is a potentially interactive PostgreSQL RPM: it can ask you if you want to do a dump, ask for DB login information, or just abort once you realize that you’ll have to dump the database before upgrading. On a side note, I believe I’ve seen Debian packages give me nice curses dialogs for options and other information when installing or upgrading packages; I’ve seen few-if-any RPMs do something similar, though I don’t think there’s anything that prevents an RPM from prompting the user for input (finding out if you’re being run non-interactively possibly being the hardest part&em;and that’s probably not very hard).

    I’ll also note that the FC5 release notes (you read those, right? 🙂 ) remind you that, if upgrading from a prior release of PostgreSQL (specifically FC4) you’ll need to follow the PostgreSQL upgrade procedures, which include a pg_dumpall.

    As for your /etc/fstab problem, I think I’ve run into a similar issue. I have a particular USB thumb drive that I want mounted at a particular point on the filesystem, and with particular options. If I don’t configure anything, Gnome ends up mounting the disk under /media (and world readable for my VFAT disk, I think; that seems dumb). Perhaps you’re using a headless FC5, so you don’t get anything mounted automatically. Anyway, the solution for me was using /dev/disk/by-uuid/DEAD-BEEF for the device in /etc/fstab, where DEAD-BEEF is the UUID for that particular VFAT filesystem. I’m betting one easy way to determine the UUID for your USB disk is to connect it and then ls -l /dev/disk/by-uuid and look for the link that points to your USB disk’s device. I’m not sure if this is helpful, but your issue seemed to stem from the fact that the device name might change each time you connect a USB disk; using the by-uuid device for the disk means you have a device name that’s not going to change over time.

  3. FWIW, the Debian PostgreSQL packages have (a) warned you of the incompatibility, (b) asked if you wanted it to try an automatic upgrade (ie, their scripted dump’n’restore) and (c) given you both tools and instructions on how to manually upgrade later, for as long as I can remember (ie, at least the last 5-6 years). Even before it was possible to install multiple versions along side each other there were utility packages of enough to dump’n’reload from the previous version to the new version available in Debian.

    I have Debian systems with PostgreSQL database which have been through three Debian stable releases, without requiring manual attention on my part to upgrade them.

    Ewen

Comments are closed.