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 [EMAIL PROTECTED] Dept of Epidemiology and Biostatistics fax: (415) 514-8150 University of California, San Francisco San Francisco, CA 94107-1739 hm: (415) 550-1062 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
