Red Hat Linux/BDB dependencies upgrade questions

[Kevin M. Myer]

For archival sake, here's what I found out the second time through this process
on my test server.

1)  Make sure that your cyrus user and group can read the databases (any ending
in .db and /var/lib/imap/db/*).  I had wrong ownership on some files that was
generating some slightly misleading error messages (misleading in the sense of
my interpretation of the error messages: "DBERROR db3: region error" went away
when I changed permissions but it originally had me thinking that a file was
corrupt.  I guess if you think in a more abstract database way, the inability to
read a file in a database environment is same as having a region error but I
wasn't thinking that way at first).

2)  Wait.  I found that running db_recover (from the BDB utilities) made the
mismatch error go away and I could then run cvt_cyrusdb without a problem (of
course I started it Tuesday night and it had the leisure of running during the
ice storm yesterday and finishing some time then - but it took awhile).  I've
just restarted the whole process from scratch again to make sure I've got a
clear roadmap for what needs done and this time, the ctl_cyrusdb process is
chewing away at the databases and recovering them.  I suspect this is doing the
same thing as running db_recover manually did.  But its taking a long time,
since the /var/lib/imap/db/log* files are 1.7Gb in size and this box is much
slower than my production mail server.

3)  I've found out that its not exactly clear to me how the embedded databases
are related.  I'd hazard a guess that the __db* files in /var/lib/imap/db are
lock files and the log.* files are transaction logs but for which databases? 
All of them?  Is skiplist based on BDB or is it a new DB scheme totally (looking
at the code, it appears to be the latter)?

I'd love to see something like http://www.postfix.org/big-picture.html generated
for Cyrus IMAP, as well as a discussion in the documentation of the relative
merits of using different DB types for each of the different databases (i.e. how
each one impacts performance, scalability, even bugginess).  All-in-all, doing
those things would make the whole mail system more approachable to everyone. 
You could argue that if you can't understand whats going on with the
documentation thats currently available, then choose a different mail server but
the fact of the matter is, with Cyrus IMAP being packaged for Debian and for
RPM-based Linux systems, its bound to get a much wider exposure than previously,
including many folks who are non-programmers or not full-time IT folks.  The
current Cyrus IMAP overview at
http://asg.web.cmu.edu/cyrus/cyrus-overview-TOC.html says it hasn't been
reviewed in detail since 1997, although the technical content is still valid. 
Most of the time, the devil is in the details :)

Just my $0.02 - I know documentation is the last thing on most people's
priorities (myself included - a lot of our documentation is stored in the gray
matter between my ears, which is A Bad Thing).

Kevin
--
Kevin M. Myer
Systems Administrator
Lancaster-Lebanon Intermediate Unit 13
(717) 560-6140