On Fri, Aug 15, 2008 at 09:01:13AM +0100, Andrew Harford wrote:
On Fri, Aug 15, 2008 at 12:32:55AM +0100, Cian Brennan wrote:
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.
Why won't they be able to write to the index directory?
Sorry, should've been clearer. On deathray, I've created for each user a /var/indexes/$username directory. We don't *want* them to be able to write to this themselves, which at the moment isn't a problem. But, if we move back to minerva and use the same setup, then obviously they will be able to write to /var/indexes. (they can log into the machine). The assumption on deathray is that WWW will be moved back to murphy in the very near future. (WWW provides another way for them to write to their index directory). Cian's point about procmail is right though, that's executed on deathray, so could in theory be used to do whatever they want there. (thinking about it more, this is a security bug in general, users shouldn't be able to execute code on deathray).
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
--
--
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
-- Andrew Harford System Administrator, DCU Networking Society Ordinary Member, Societies & Publications Committee
Ultimately, we're all dead men. Sadly, we cannot choose how, but what we can decide is how we meet that end, in order that we are remembered as men. --Proximo (Gladiator)