The upgrade wasn't entirely smooth; I wrote up some notes about what IIf the version of db is different, you can't just expect to use the binary database files and logs. Dumping the contents to a text file, wiping the transaction logs, and then reloading them is the safest way.
did: http://nakedape.cc/wiki/index.cgi/CyrusImapNotes in case someone
else wanders along this path... The biggest issue was that ctl_cyrusdb
wasn't able to read my old mailboxes.db file; I reverted to my old
installation and dumped the database to a flat file and it went okay. For some reason that I don't understand, I had to remove the
/var/lib/imap/db directory for the rebuilding of the database to work
correctly.
You should have had A-W, not Z (23 is a prime to give better distribution of the hash values between directories) -- full hashing chooses a hash directory based on the complete mailbox name rather than just the first character. Traditional hashing tends to overload some directories while leaving others almost empty.'rehash full' did very strange things; it only created directories of A-Z, none of a-z and my own mailbox information was under 'I/' in both the mailbox spool and the '/var/lib/imap/user' directory. As a result, I had to disable 'hashimapspool', which Simon's RPMs enabled by default.
mbpath will give you the path for the mailbox, or just ls -ld /cyrus/*/user/wcooley (for example). If you have less than a thousand mailboxes, there is no need to worry about hashing. Otherwise, you will likely get poor performance with long namei lookups.
Finally, I have a customer that's a small ISP that's currently runningIn this day, is there really any good reason to continue using POP? There are so many problems with it (including support issues when people downloaded their mail to one computer and wonder why they can't access it from another) it seems best to retire it.
2.0.16. I'm going to upgrade regardless, just so I can bounce messages
delivered through LMTP to boxes that are over-quota. However, I
recurrent problem we have is with POP3 users (which everyone is) who
lose their connection (usually because of problems with dial-up). The
pop3d stays running and locks the mailbox for 15 minutes or so, causing
lots of support calls and grumbling. I'm guessing the connection stays
in TIME_WAIT for this period, but 15 minutes seems like a long time for
it to stay open. I see the 'poptimeout' setting that might help, but
even 10 minutes might be too long. (This 15 minutes could be only 10
minutes already; I'm just being told this by the guy who does support.) Will anything that's changed between 2.0.16 and 2.1.13 help assuage this
problem?
When the user calls up complaining about this, that gives you a perfect opening to convince them to move to IMAP.
-- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
