Monk upgrade

cvs.haskell.org (aka haskell.galois.com; aka monk) is in need of an OS upgrade. It's currently running Debian sarge; the upgrade will be to etch, the current stable version of Debian.

This page is meant to host discussion of

1. Which crucial applications will be upgraded (with specific version numbers)?
   1. What config files will need tweaking?
   2. What binary data stores (e.g., database disk files) will need processing?
2. The downtime plan
   1. Schedule
   2. Regression tests (including who will carry them out)
   3. Rollback plan(s)
3. Wider post-upgrade testing and observations

Application upgrades

Which crucial applications will be upgraded?

Notes on re-configuration...

MySQL, PostgreSQL, SQLite, BerkeleyDB -- which of them are in active use and candidates for upgrades? Their data stores will likely need a dump and restore...

Apache

Migration to version 2. Need to update server config, and .htaccess files.

Start using mod_python? --SimonM

MySQL

Nobody claimed to be using this.

As root, in /root, run

mysqldump --all-databases > backup-mysql-db-4.0.24-sarge-`date +%F`

before doing the upgrade. Then upgrade mysql and stop the server running to see if anyone complains.

PostreSQL

Nobody claimed to be using this.

As the postgres user, in its home directory /srv/postgres,run

pg_dumpall > backup-db-7.4.7-sarge-`date +%F`

before doing the upgrade. Then upgrade postgres (it should migrate the data) and stop the server running to see if anyone complains.

SQLite

Used by Trac. To upgrade the databases, do this for each trac instance foo:

cd /srv/trac/foo/db
mv trac.db trac2.db
sqlite trac2.db .dump | sqlite3 trac.db
trac-admin /srv/trac/foo upgrade
comment out repository_type and repository_dir in ../conf/trac.ini

CVS

Paul offerred to deal with this one.

Trac

It should be possible to upgrade Trac independently after the upgrade. If so, I think we should do that, in order to reduce dependencies and shorten the downtime.

Darcs

No upgrade required: we don't use the Debian-supplied version here.

Downtime plan

The downtime plan in as much detail as possible.

We need to move /home to the /srv partition, as it is running out of space.

Regression tests

Preferably scripted, with "owner" who decides how to proceed in event of failure.

Verify that we can

• use darcs, including remote push
• send external email (including darcs reports)
• use all the Tracs
• use darcsweb
• use Hackage
• use CVS

Post-upgrade notes and observations

Anything we learned or observed that will be helpful as we move forward?

Heinlein 19:04, 25 June 2007 (UTC)