I recently upgraded a couple of servers over at slicehost from Ubuntu 9.04 to 9.10 via the command line upgrade. There were only a couple problems.
During the install, I kept my php and svn config files, since the diff showed no major changes to the ones in the package (other than my configurations, of course).
The first problem was that the Postgresql 8.3 databases needed to be updated to 8.4, and the installer doesn’t do that. I made sure to run these before the installer removed the 8.3 package (it asks before doing so at the end of the install script), though I don’t know if that is strictly necessary. The upgrade was relatively simple:
#see what clusters you currently have
pg_lscluster
#drop the empty new 8.4 cluster the installer created
sudo pg_dropcluster 8.4 main
#upgrade your existing cluster
sudo pg_upgradecluster 8.3 main /var/lib/postgresql/8.4/main
The upgrade command SHOULD take care of copying the data, upgrading it to the new format, stopping the old cluster, and starting the new cluster on the same port. On one of my machines the process of stopping the old cluster failed, but doing it manually with pg_ctlcluster worked.
Once I upgraded the Postgres databases, I allowed the script to remove the old packages and reboot the machine. Then I selected the kernel upgrade in the slicehost control panel (which rebooted the machine again) and let it come up. Almost everything worked perfectly.
The other issue I encountered was that after the upgrade, memcached no longer started on reboot. After a bit of poking around, I discovered that the upgraded package that comes with 9.10 comes with a new file in /etc/default/memcached which defaults to having memcached disabled. To enable it, set ENABLE_MEMCACHED=yes and memcached starts when your server boots. This does have a launchpad bug, but nobody seems to be taking responsibility for fixing it.
Another gotcha turned out to be the fact that memcached must already be running when Django starts. I only resolved the issues with memcached after my Django processes had started on the other server, and it took me a few minutes to remember that I needed to restart them to fix caching.
The only other minor issue was that (as expected) the upgrade overwrote my script that gets invoked whenever svnserve is called. I have this in place so that I can svn+ssh into the server and check files out without specifying their absolute path in the file system. My script looks like this:
#!/bin/sh
umask 002
exec /usr/bin/svnserve.bin -t -r [path to svn repo] "$@"
I keep the actual svnserve binary (default installed to /usr/bin/svnserve) in svnserve.bin and the script in svnserve.ssh. I then link /usr/bin/svnserve to svnserve.ssh, so when svn gets upgraded, I just recopy the binary and re-link.
