Several issues with 2.1.13

[John Alton Tamplin]

Wil Cooley wrote:

>The upgrade wasn't entirely smooth; I wrote up some notes about what I
>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.
>  
>
If 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.

>'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.
>
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.

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 running
>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?
>  
>
In 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.
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