Difference between revisions of "Monk upgrade"
BrettGiles (talk | contribs) m (MonkUpgrade moved to Monk upgrade) |
|||
| (4 intermediate revisions by 3 users not shown) | |||
| Line 12: | Line 12: | ||
# Wider post-upgrade testing and observations |
# Wider post-upgrade testing and observations |
||
| − | == Application |
+ | == Application upgrades == |
Which crucial applications will be upgraded? |
Which crucial applications will be upgraded? |
||
| Line 20: | Line 20: | ||
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... |
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 |
||
| + | <pre>mysqldump --all-databases > backup-mysql-db-4.0.24-sarge-`date +%F`</pre> |
||
| + | 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 |
||
| + | <pre>pg_dumpall > backup-db-7.4.7-sarge-`date +%F`</pre> |
||
| + | 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: |
||
| + | |||
| + | <pre> |
||
| + | 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 |
||
| + | </pre> |
||
| + | |||
| + | === 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. |
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=== |
||
| ⚫ | |||
| + | 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 |
||
| − | Rollback plan(s) |
+ | ===Rollback plan(s)=== |
| − | == Post- |
+ | == Post-upgrade notes and observations == |
Anything we learned or observed that will be helpful as we move forward? |
Anything we learned or observed that will be helpful as we move forward? |
||
Revision as of 17:13, 1 July 2007
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
- Which crucial applications will be upgraded (with specific version numbers)?
- What config files will need tweaking?
- What binary data stores (e.g., database disk files) will need processing?
- The downtime plan
- Schedule
- Regression tests (including who will carry them out)
- Rollback plan(s)
- 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.
Schedule
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
Rollback plan(s)
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)