[Dovecot] Dovecot NFS Indexes and IMAP Migration
Hi there,
After being extremely impressed from implementing it in some customer installations, I've decided to migrate our mail infrastructure to dovecot. Being able to have /bin/checkpassword support across the board for pop, imap, and smtp authentication, as well as being able to ditch stunnel for the SSL layer...where were you in 2001?!? :)
I have two concerns, the first is about the proper index configuration in our environment, and the second is about the best way to migrate mailboxes.
Some quick background: we've long been distributed, with an L4 switch up front and a Netapp in the back, Mysql for metadata. We have a cluster of several FreeBSD boxes doing filtering and maildir delivery (postfix/amavisd-new), and we have a server that users get sent to for pop/imap. If it's down, they get sent to one of the filter boxes instead.
So, regarding the indexes:
From reading the docs, it appears I would not be able to use the dovecot LDA due to locking issues (bummer), and I should configure dovecot to store index files on a local disk of the primary pop/imap server rather than on the netapp.
My first question would be, how much of a performance hit should I expect from having to update the indexes when mail is checked rather then when mail is delivered since I can't use the LDA? Is this a minor issue like I expect, or can it be something the user actually notices when checking mail?
In a worst case scenario, if the pop/imap server is down, and another server is used, how long would it take to create an index for an account with a few hundered megs, several thousand messages? I'm wondering if, since I have plenty of overhead available on the netapp, I should just store the indexes there in case another server must be used.
I'm basically looking for more information about the pros and cons of storing the indexes on the nfs volume in a situation where a single server would normally be providing pop/imap service.
Regarding migration:
My concerns regarding migration relate to how best to process existing maildirs by both converting the previous imap metadata and calculating an initial index for each account.
First off, I can't seem to find any info on a way to create an initial index file for all of the mailboxes. Can anybody suggest a command I can use for this? I'm sure I just overlooked it.
Regarding the migrations, we have both courier and bincimap to deal with. (We use qmail's pop, so no complications with migrating courier).
Fortunately, courier is used for normal imap on 143, bincimap is only used for webmail. So, it would seem that metadata from bincimap could be ignored; the only thing it would seem important to preserve is mailbox subscriptions. Please correct this assumption if I'm wrong.
bincimap uses a INBOX/folder format in the subscription file, however the actual folders are stored exactly the same as the INBOX.folder style of courier.
So, it seems like my best option is to modify the courier-dovecot-migrate.pl script to consider the mailboxes subscribed to via bincimap. Here's a modified convert_subscriptions that seems to work well in limited testing, feel free to point out any idiot mistakes, it's been a while since I've done anything substantial in perl. I would have sent a patch but I suspect I'm the only person who will ever use this change and critiquing it would be easier with a full context.
sub convert_subscriptions { my ($dir, $owner_uid, $owner_gid) = @_; my $in_fname = "$dir/courierimapsubscribed";
# ADDED: The bincimap file to parse
my $in_fname2 = "$dir/.bincimap-subscribed"; my $out_fname = "$dir/subscriptions";
# MODIFIED: Return only if neither exist
return if (!-f $in_fname && !-f $in_fname2); if (!$overwrite && -f $out_fname) { print "$out_fname already exists, not overwritten\n" if (!$quiet); return; } return if (!$do_conversion);
my ($fin, $fin2, $fout); open ($fin, $in_fname) || die $!; open ($fin2, $in_fname2) || die $!; open ($fout, ">$out_fname") || die $!;
# ADDED: An array to track mailboxes we've written in case both files exist
my @subs;
while (<$fin>) {
chomp $_;
if (/^INBOX$/i) {
print $fout "INBOX\n";
push @subs, "INBOX\n";
} elsif (/^INBOX\.(.*)$/i) {
print $fout "$1\n";
push @subs, "$1\n";
} else {
# unknown. keep it as-is.
print $fout "$_\n";
push @subs, "$_\n";
}
}
close $fin;
# ADDED: A second loop, same as the first, but also checking to make # sure that the mailbox has not already been written to the new file to # eliminate duplicates.
while (<$fin2>) {
chomp $_;
my $sub = $_;
if (/^INBOX$/i && !grep (/^INBOX\n/i, @subs)) {
print $fout "INBOX\n";
} elsif (/^INBOX\/(.*)$/i && !grep (/^$1\n/i, @subs)) {
print $fout "$1\n";
} elsif (!grep(/^$sub\n/, @subs)) {
# unknown. keep it as-is.
print $fout "$sub\n";
}
}
close $fin;
close $fin2;
close $fout;
chown $owner_uid, $owner_gid, $out_fname;
}
Thanks in advance for any help or suggestions! Andy
Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972
On Feb 27, 2008, at 8:49 AM, Andy Dills wrote:
From reading the docs, it appears I would not be able to use the
dovecot LDA due to locking issues (bummer), and I should configure dovecot to store index files on a local disk of the primary pop/imap server
rather than on the netapp.
I don't think locking is an issue. NFS caching is more problematic.
But with v1.1's mail_nfs_*=yes settings there should be no problems
with storing indexes on NFS.
My first question would be, how much of a performance hit should I
expect from having to update the indexes when mail is checked rather then
when mail is delivered since I can't use the LDA? Is this a minor issue
like I expect, or can it be something the user actually notices when checking mail?
It's a minor issue usually.
In a worst case scenario, if the pop/imap server is down, and another server is used, how long would it take to create an index for an
account with a few hundered megs, several thousand messages? I'm wondering if, since I have plenty of overhead available on the netapp, I should just store the indexes there in case another server must be used.
The actual index file creation is really fast. More problematic is
losing dovecot.index.cache file for clients that want to fetch/search
old data. But Courier/Binc did no caching at all, so Dovecot wouldn't
be any worse.
First off, I can't seem to find any info on a way to create an initial index file for all of the mailboxes. Can anybody suggest a command I
can use for this? I'm sure I just overlooked it.
I don't think you should worry about it. Like I said, the
dovecot.index.cache file generation is the slow part. But since its
generation depends entire on what fields client is using, you can't
really pregenerate it properly anyway. http://wiki.dovecot.org/IndexFiles
tries to describe this. http://imapwiki.org/Benchmarking might have
more understandable explanation as well.
Fortunately, courier is used for normal imap on 143, bincimap is
only used for webmail. So, it would seem that metadata from bincimap could be ignored; the only thing it would seem important to preserve is mailbox subscriptions. Please correct this assumption if I'm wrong.
Right.
So, it seems like my best option is to modify the courier-dovecot-migrate.pl script to consider the mailboxes
subscribed to via bincimap. Here's a modified convert_subscriptions that seems to
work well in limited testing, feel free to point out any idiot mistakes,
it's been a while since I've done anything substantial in perl.
I'm not that great perl coder either. :)
On Wed, 27 Feb 2008, Timo Sirainen wrote:
On Feb 27, 2008, at 8:49 AM, Andy Dills wrote:
From reading the docs, it appears I would not be able to use the dovecot LDA due to locking issues (bummer), and I should configure dovecot to store index files on a local disk of the primary pop/imap server rather than on the netapp.
I don't think locking is an issue. NFS caching is more problematic. But with v1.1's mail_nfs_*=yes settings there should be no problems with storing indexes on NFS.
That's good to know. Do you view 1.1 as production ready now, or should I wait for an official release? It sounds production ready in the RC1 release notes, but I was curious how much remains on your "few issues you'd like to fix" list and how relevant they are to my environment.
Thanks, Andy
Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972
On Feb 28, 2008, at 3:25 AM, Andy Dills wrote:
I don't think locking is an issue. NFS caching is more problematic.
But with v1.1's mail_nfs_*=yes settings there should be no problems with
storing indexes on NFS.That's good to know. Do you view 1.1 as production ready now, or
should I wait for an official release? It sounds production ready in the RC1 release notes, but I was curious how much remains on your "few issues you'd like to fix" list and how relevant they are to my environment.
v1.1 is already used in production in a couple of large installations,
so it should probably work quite well. I think most of the crashfixes
that are on my TODO list happen only after client has already
disconnected.
FYI,
We deployed Dovecot 1.1RC1 yesterday on about 100k+ mailboxes (on multiple frontends which connect to a storage via NFS). We handle about one IMAP login every second (for now only from our webmail app). So far; it's been running like a charm; we come from Courier IMAP and Dovecot IMAP (with indexes and auth_cache) performs much faster and puts less load on our frontends and webmail app.
Cheers,
Jan
-----Oorspronkelijk bericht----- Van: dovecot-bounces+jan.vandenberg=isp.solcon.nl@dovecot.org [mailto:dovecot-bounces+jan.vandenberg=isp.solcon.nl@dovecot.org] Namens Timo Sirainen Verzonden: donderdag 28 februari 2008 18:49 Aan: Andy Dills CC: dovecot@dovecot.org Onderwerp: Re: [Dovecot] Dovecot NFS Indexes and IMAP Migration
On Feb 28, 2008, at 3:25 AM, Andy Dills wrote:
I don't think locking is an issue. NFS caching is more problematic.
But with v1.1's mail_nfs_*=yes settings there should be no problems with
storing indexes on NFS.That's good to know. Do you view 1.1 as production ready now, or
should I wait for an official release? It sounds production ready in the RC1 release notes, but I was curious how much remains on your "few issues you'd like to fix" list and how relevant they are to my environment.
v1.1 is already used in production in a couple of large installations,
so it should probably work quite well. I think most of the crashfixes
that are on my TODO list happen only after client has already
disconnected.
Jan van den Berg, on 2/29/2008 3:45 AM, said the following:
FYI,
We deployed Dovecot 1.1RC1 yesterday on about 100k+ mailboxes (on multiple frontends which connect to a storage via NFS). We handle about one IMAP login every second (for now only from our webmail app). So far; it's been running like a charm; we come from Courier IMAP and Dovecot IMAP (with indexes and auth_cache) performs much faster and puts less load on our frontends and webmail app.
Hi Jan,
Just out of curiosity... why only webmail? And, which webmail app do you use?
--
Best regards,
Charles
The bulk of our customers now/still use POP (we still use Courier POP); but we're planning on also offering IMAP as a regular service (so we needed a decent IMAP server). But also because we're planning on rolling out a new in-house developed webmail app. based on IMAP. For now we use SquirrelMail as webmail app.
Cheers,
Jan
-----Oorspronkelijk bericht----- Van: dovecot-bounces+jan.vandenberg=isp.solcon.nl@dovecot.org [mailto:dovecot-bounces+jan.vandenberg=isp.solcon.nl@dovecot.org] Namens Charles Marcus Verzonden: vrijdag 29 februari 2008 11:41 Aan: Dovecot Mailing List Onderwerp: Re: [Dovecot] Dovecot NFS Indexes and IMAP Migration
Jan van den Berg, on 2/29/2008 3:45 AM, said the following:
FYI,
We deployed Dovecot 1.1RC1 yesterday on about 100k+ mailboxes (on multiple frontends which connect to a storage via NFS). We handle about one IMAP login every second (for now only from our webmail app). So far; it's been running like a charm; we come from Courier IMAP and Dovecot IMAP (with indexes and auth_cache) performs much faster and puts less load on our frontends and webmail app.
Hi Jan,
Just out of curiosity... why only webmail? And, which webmail app do you
use?
--
Best regards,
Charles
participants (4)
-
Andy Dills
-
Charles Marcus
-
Jan van den Berg
-
Timo Sirainen