On Thu, Aug 14, 2008 at 11:03:23PM +0100, Andrew Martin wrote:
On Mon, Aug 11, 2008 at 06:49:15AM +0100, Ryaner wrote:
On Sun, Aug 10, 2008 at 11:39:50PM +0100, Andrew Martin wrote:
Hi all,
At the suggestion of ryaner (thanks!), we've put a test copy of Dovecot IMAP server on deathray. This has a few advantages over courier:
- It's faster (indexing, caching, stuff). - It lets me log in (courier refuses to accept that I exist, and shows nothing in the error logs). - It's website (http://www.dovecot.org/) says lots of nice things about it.
I haven't added our SSL cert to it just yet, I'll do that in the next few minutes.
It saves it's indexes locally on deathray in /var/indexes/$username, making it nice and fast.
If anyone wants to try it out, just create a Secure IMAP (SSL) connection to deathray.redbrick.dcu.ie, and play around with it.
Few things to mention are that dovecot and courier uses different subscription lists and namespaces. http://wiki.dovecot.org/Migration/Courier details a good part of it and they have done a lot of work over the past while making the change easier. Basic steps would be to copy "courierimapsubscribed" to "subscriptions" for every one but have it changed to remove the inbox prefixes, then copy the uid files if you want. RB has enough cpu/memory so as not to notice a uid rebuild, even for the largest of users here.
That looks good.. I like the PostLoginScripting option to convert people's UIDs the first time they log in.. we might want to add a couple of conditionals to that to make sure that they don't run it twice, but the idea should work.
About the indexes - The way I'm doing it now is using a perl script to create a bunch of directories belonging to users under /var/indexes.
This means that we don't have to worry about NFS limitations on dovecot's indexing. (It doesn't like saving it's indexes on NFS volumes too much, it has to apply workarounds which reduce performance).
Because deathray isn't accessable to users, we can safely assume that once WWW is moved back to murphy, there'll be no way for them to write $random_crap to their index directory (essentially giving them extra local storage). Procmail? We're not being stingy or anything, but that particular disk space is valuable. Anyway, this obviously won't work on minerva.
So, do we want to come up with an alternate (NFS safe, so less fast) solution for minerva, or just plan on moving production IMAP back to deathray?
Did any of that even make sense to anyone? Congratulations if it did, I'm quite tired writing this :)
-Andrew
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
-- --