Bug#369882: cyrus-doc-2.2 upgrade issues [Recipes and Results]

[Ross Boylan]

OK, I just completed an upgrade from 2.1 to 2.2.  I think it worked.
In brief:
*disabled some local cron jobs that do mail backup
*disabled mail delivery to lmtp (just to be safe--probably unnecessary.
For the record, I used a redirect router with 
data = :defer: in exim4)
*apt-get install  for the new packages
(I didn't even stop the old one)
There was a several minute delay after it said
Creating partition spool /var/spool/cyrus/mail...
(the message sorted of sounded as if it were deleting my existing
partition, which would have been bad.  It didn't.)
I got a message saying database versions had changed and directing me to
one of the semi-obsolete README's.
* merged in changes from dpkg-dist imapd.conf and cyrus.conf
(should the apop service be listed in cyrus.conf?  it doesn't seem to
be)
* cd /var/lib/cyrus/
* rm tls_sessions.db
* db4.2_upgrade /var/lib/cyrus/deliver.db
(Not sure what to do with the db directory.
Specifying it in -h produced an error: incompatible version.
Maybe I should have deleted it, or the files in it?
Also, instructions could note it is safe to delete deliver.db if you
don't mind getting some duplicates.)
* rm /usr/lib/cyrus/cyrus-db-types.active
* dpkg-reconfigure cyrus-common-2.2
(another several minute delay at same point.  I would not have known to
do this except for the clue in README.Debian.Database, which the debconf
message referenced.  I was concerned since my old cyrus-db.types had db3
in a couple of names)
* /etc/hosts.allow modified to allow sieve service
(I had sieveusehomedir enabled in 2.1, and disabled it in 2.2.  I found
out the hard way I couldn't talk to the server).

Instructions to Debian upgraders should also note the need to run
masssievec if there are already scripts on the server, and deal with
user home scripts otherwise.

It would be helpful to note that 2.1 database formats in Debian differ
from upstream, so there is less work to do than indicated in their
instructions: mailbox and seen db's do not change format from 2.1 to 2.2
in Debian.

Finally, upstream upgrade instructions note some changes to the
configuration system, but there are some peculiarities there I'll detail
in a separate bug.

The logs indicated a database version mismatch error with the logs and
environment:
Jul 25 19:21:03 iron cyrus/master[11318]: process started
Jul 25 19:21:03 iron cyrus/master[11319]: about to
exec /usr/sbin/ctl_cyrusdb
Jul 25 19:21:03 iron cyrus/ctl_cyrusdb[11319]: DBERROR db4: Program
version 4.2 doesn't match environment version
Jul 25 19:21:03 iron cyrus/ctl_cyrusdb[11319]: DBERROR db4: Ignoring log
file: /var/lib/cyrus/db/log.0000000042: unreadable log version 3
Jul 25 19:21:03 iron last message repeated 2 times
Jul 25 19:21:03 iron cyrus/ctl_cyrusdb[11319]: recovering cyrus
databases
Jul 25 19:21:03 iron cyrus/ctl_cyrusdb[11319]: skiplist:
recovered /var/lib/cyrus/mailboxes.db (38 records, 6488 bytes) in 0
seconds
Jul 25 19:21:03 iron cyrus/ctl_cyrusdb[11319]: done recovering cyrus
databases
Jul 25 19:21:03 iron cyrus/master[11320]: about to
exec /usr/sbin/ctl_deliver
Jul 25 19:21:04 iron cyrus/cyr_expire[11320]: duplicate_prune: pruning
back 3 days
Jul 25 19:21:04 iron cyrus/cyr_expire[11320]: mydelete: starting txn
2147483650
Jul 25 19:21:05 iron cyrus/cyr_expire[11320]: mydelete: committing txn
2147483650
Jul 25 19:21:05 iron cyrus/cyr_expire[11320]: mydelete: starting txn
2147483651
Jul 25 19:21:05 iron cyrus/cyr_expire[11320]: mydelete: committing txn
2147483651
Jul 25 19:21:05 iron cyrus/cyr_expire[11320]: mydelete: starting txn
2147483652
(etc)

Apparently bdb was able to recover automatically.


-- 
Ross Boylan                                      wk:  (415) 514-8146
185 Berry St #5700                               ross at biostat.ucsf.edu
Dept of Epidemiology and Biostatistics           fax: (415) 514-8150
University of California, San Francisco
San Francisco, CA 94107-1739                     hm:  (415) 550-1062