Berkeley DB upgrade - 2nd try

[Paul Boven]

Hi everyone,

Paul Boven wrote:
> If I build cyrus against the old version (4.1.25), it runs great. If I 
> build it against 4.4.20, it doesn't want to start. Even though I've 
> changed tlscache_db and duplicate_db to 'skiplist' in the imapd.conf and 
> removed those db-files from the system, so it shouldn't even be using 
> Berkeley-db anymore, with all databases being skiplist.
> Starting with a clean /var/imap, I can start the newly compiled Cyrus, 
> so it has to do with whatever is left in /var/imap/db from the old 
> Berkeley version.
> 
> I've also done a db_upgrade in /var/imap using the 4.4.20 db_upgrade 
> version, but the Cyrus with the 4.4.20 Berkeley libs still won't start.
> 
> I'd welcome any suggestions on how to proceed and make this into a 
> working mail-server again. (Don't worry, this is only the testbed - the 
> really scary stuff is yet to come).

Progress made since:

I've tried to build a Cyrus without any Berkeley by specifying 
'--without-bdb' - for that, I had to comment out a fixed '#include 
<db.h>' in lib/auth_pts.h. But that only resulted in this error message 
when starting up: "Fatal error: cyrusdb backend berkeley not supported". 
Other people seem to have managed to go without Berkeley, but so far I 
haven't - and as Berkely has better performance for the deliver.db and 
tls_sessions.db, that is not the preferred workaround anyway.

I've started building cyrus-imapd-2.2.13 - the Cyrus homepage still 
lists 2.2.12 as the 'current' version, but is apparently outdated a bit. 
In another posting to this list, Andrew Morgan hinted that "Cyrus 
v2.2.12 and older will not work with Berkeley DB 4.3+ without a patch". 
With 2.2.13, at least I get a meaningful error out of Berkeley when I 
start Cyrus:

DBERROR db4: Skipping log file /var/imap/db/log.0000000001: historic log 
version 7
DBERROR db4: /var/imap/db/log.0000000002: log file open failed: No such 
file or directory
DBERROR db4: PANIC: No such file or directory

Running db_recover from Berkeley4.4.20 gave me essentially the same errors.

In the end, I figured it apparently doesn't care about log.00000001, so 
I moved it aside. This time, it also stopped looking for log.00000002 
and recovered succesfully. And now Cyrus works again!

Before I even want to consider doing this kind of surgery on any of my 
production Cyrus servers, I'd like to know what would have been in 
log.00000001 - what risks do I run when removing it?

Regards, Paul Boven.