Re: [Dovecot] Performance of Maildir vs sdbox/mdbox
Am 20.01.2012 01:13, schrieb Timo Sirainen: > On 20.1.2012, at 1.51, Stan Hoeppner wrote: > >> I spent a decent amount of time last night researching the NFS cache >> issue. It seems there is no way to completely disable NFS client >> caching (in lie of rewriting the code oneself--a daunting tak), which >> would seem to be the real solution to the mdbox index corruption problem. >> >> So I went looking for alternatives and came up with the idea above. >> Obviously it's far from an optimal solution and introduces some >> limitations, but I thought it was worth tossing out for discussion. > > I spent months looking into NFS related issues. I read through Linux and > FreeBSD kernel source codes to figure out if there's something I could do to > avoid the problems I see. I sent some patches to try to improve things, which > of course didn't get accepted (some alternative ways might have been, but it > would have required much more work from my part). The mail_nfs_* settings are > the result of what I found out. They don't fully work, so I gave up. > >> Timo, it seems that when you designed mdbox you didn't have NFS based >> clusters in mind. Do you consider mdbox simply not suitable for such an >> NFS cluster deployment? If one has no choice but an NFS cluster >> architecture, what Dovecot mailbox format do you recommend? Stick with >> maildir? > > In the typical random-access NFS setup I don't consider any of Dovecot's > formats suitable. Not maildir, not dbox. Perhaps in future I can redesign > everything in a way that just happens to work well with all kinds of NFS > setups, but I don't really hold a lot of hope for that. It seems that either > you'll get bad performance (I'm not really interested in making Dovecot do > that) or you'll use such a setup where you get good performance by avoiding > the NFS problems. > > There are several huge Dovecot+NFS setups. They use director. It works well > enough (and with the recent fixes, I'd hope perfectly). > >> In this case the OP has Netapp storage. Netapp units support both NFS >> exports as well as iSCSI LUNs. If the OP could utilize iSCSI instead of >> NFS, switching to GFS2 or OCFS, do you see these cluster filesystem as >> preferable for mdbox? > > I don't have personal experience with cluster filesystems in recent years > (other than glusterfs, which had some problems, but most(/all?) were fixed > already or are available from their commercial support..). Based on what I've > heard, I'm guessing they work better than random-access-NFS, but even if > there are no actual corruption problems, it sounds like their performance > isn't very good. for info i have 3500 users behind keepalived loadbalancers with drbd ocfs2 on two lucid servers, they are heavy penetrated by pop3 with maildir on dove2 , in the begin i had some performance problem but they were mostly related to the raid controlers io, so imap was very slow. Fixing this raid problems gave good imap performance now ( beside some dovecot and kernel tuneups ), anyway i would overthink this whole setup again going up to more users i.e i guess mixing loadbalancers and directors is no problem, maildir seems to be slow by io in design , so mdbox might better, and after all i would more investigate about drbd and compare gfs ocfs and other cluster filesystems better, i.e switching to iSCSI i.e i think it should be poosible to design partitioning with ldap or sql to i.e split up heavy and big mailboxes in seperate storage partitions etc am i right here Timo ? anyway i would like to test some cross hostingplace setup with i.e glusterfs lustre etc to get more knowledge as base of a multi redundant mailsystem -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: [Dovecot] Performance of Maildir vs sdbox/mdbox
On 1/19/2012 6:13 PM, Timo Sirainen wrote: > On 20.1.2012, at 1.51, Stan Hoeppner wrote: > >> I spent a decent amount of time last night researching the NFS cache >> issue. It seems there is no way to completely disable NFS client >> caching (in lie of rewriting the code oneself--a daunting tak), which >> would seem to be the real solution to the mdbox index corruption problem. >> >> So I went looking for alternatives and came up with the idea above. >> Obviously it's far from an optimal solution and introduces some >> limitations, but I thought it was worth tossing out for discussion. > > I spent months looking into NFS related issues. I read through Linux and > FreeBSD kernel source codes to figure out if there's something I could do to > avoid the problems I see. I sent some patches to try to improve things, which > of course didn't get accepted (some alternative ways might have been, but it > would have required much more work from my part). The mail_nfs_* settings are > the result of what I found out. They don't fully work, so I gave up. Yeah, I recall some of your posts from that time, and your frustration. If an NFS config option existed to simply turn off the NFS client caching, would that resolve most/all of the remaining issues? Or is the problem more complex than just the file caching? I ask as it would seem creating such a Boolean NFS config option should be simple to implement. If the devs could be convinced of the need for it. >> Timo, it seems that when you designed mdbox you didn't have NFS based >> clusters in mind. Do you consider mdbox simply not suitable for such an >> NFS cluster deployment? If one has no choice but an NFS cluster >> architecture, what Dovecot mailbox format do you recommend? Stick with >> maildir? > > In the typical random-access NFS setup I don't consider any of Dovecot's > formats suitable. Not maildir, not dbox. Perhaps in future I can redesign > everything in a way that just happens to work well with all kinds of NFS > setups, but I don't really hold a lot of hope for that. It seems that either > you'll get bad performance (I'm not really interested in making Dovecot do > that) or you'll use such a setup where you get good performance by avoiding > the NFS problems. > > There are several huge Dovecot+NFS setups. They use director. It works well > enough (and with the recent fixes, I'd hope perfectly). Are any of these huge setups using mdbox? Or does it make a difference? I.e. Indexes are indexes whether they be maildir or mdbox. Would Director alone allow the OP to avoid the cache corruption issues discussed in this thread? Or would there still be problems due to the split LDA setup? >> In this case the OP has Netapp storage. Netapp units support both NFS >> exports as well as iSCSI LUNs. If the OP could utilize iSCSI instead of >> NFS, switching to GFS2 or OCFS, do you see these cluster filesystem as >> preferable for mdbox? > > I don't have personal experience with cluster filesystems in recent years > (other than glusterfs, which had some problems, but most(/all?) were fixed > already or are available from their commercial support..). Based on what I've > heard, I'm guessing they work better than random-access-NFS, but even if > there are no actual corruption problems, it sounds like their performance > isn't very good. So would an ideal long term solution to indexes in a cluster (NFS or clusterFS) environment be something like Dovecot's own index metadata broker daemon/lock manager that controls access to the files/indexes? Either a distributed token based architecture, or maybe something 'simple' such as a master node which all others send index updates to with the master performing the actual writes to the files, similar to a database architecture? The former likely being more difficult to implement, the latter having potential scalability and SPOF issues. Or is the percentage of Dovecot cluster deployments so small that it's difficult to justify the development investment for such a thing? Thanks Timo. -- Stan
Re: [Dovecot] Performance of Maildir vs sdbox/mdbox
On Fri, 2012-01-20 at 02:13 +0200, Timo Sirainen wrote: > There are several huge Dovecot+NFS setups. They use director. It works well > enough (and with the recent fixes, I'd hope perfectly). Not to mention other huge NFS setups that don't use director, and also have no problems. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Performance of Maildir vs sdbox/mdbox
On 20.1.2012, at 1.51, Stan Hoeppner wrote: > I spent a decent amount of time last night researching the NFS cache > issue. It seems there is no way to completely disable NFS client > caching (in lie of rewriting the code oneself--a daunting tak), which > would seem to be the real solution to the mdbox index corruption problem. > > So I went looking for alternatives and came up with the idea above. > Obviously it's far from an optimal solution and introduces some > limitations, but I thought it was worth tossing out for discussion. I spent months looking into NFS related issues. I read through Linux and FreeBSD kernel source codes to figure out if there's something I could do to avoid the problems I see. I sent some patches to try to improve things, which of course didn't get accepted (some alternative ways might have been, but it would have required much more work from my part). The mail_nfs_* settings are the result of what I found out. They don't fully work, so I gave up. > Timo, it seems that when you designed mdbox you didn't have NFS based > clusters in mind. Do you consider mdbox simply not suitable for such an > NFS cluster deployment? If one has no choice but an NFS cluster > architecture, what Dovecot mailbox format do you recommend? Stick with > maildir? In the typical random-access NFS setup I don't consider any of Dovecot's formats suitable. Not maildir, not dbox. Perhaps in future I can redesign everything in a way that just happens to work well with all kinds of NFS setups, but I don't really hold a lot of hope for that. It seems that either you'll get bad performance (I'm not really interested in making Dovecot do that) or you'll use such a setup where you get good performance by avoiding the NFS problems. There are several huge Dovecot+NFS setups. They use director. It works well enough (and with the recent fixes, I'd hope perfectly). > In this case the OP has Netapp storage. Netapp units support both NFS > exports as well as iSCSI LUNs. If the OP could utilize iSCSI instead of > NFS, switching to GFS2 or OCFS, do you see these cluster filesystem as > preferable for mdbox? I don't have personal experience with cluster filesystems in recent years (other than glusterfs, which had some problems, but most(/all?) were fixed already or are available from their commercial support..). Based on what I've heard, I'm guessing they work better than random-access-NFS, but even if there are no actual corruption problems, it sounds like their performance isn't very good.
Re: [Dovecot] Performance of Maildir vs sdbox/mdbox
On 1/19/2012 1:18 PM, Timo Sirainen wrote:
> On 19.1.2012, at 6.39, Stan Hoeppner wrote:
>
>>> You're going to run into NFS caching troubles with the above split
>>> setup. I don't recommend it. You will see error messages about index
>>> corruption with it, and with dbox it can cause metadata loss.
>>> http://wiki2.dovecot.org/NFS http://wiki2.dovecot.org/Director
>>
>> Would it be possible to fix this NFS mdbox index corruption issue in
>> this split scenario by using a dual namespace and disabling indexing on
>> the INBOX? The goal being no index file collisions between LDA and imap
>> processes. Maybe something like:
>>
>> namespace {
>> separator = /
>> prefix = "#mbox/"
>> location = mbox:~/mail:INBOX=/var/mail/%u:INDEX=MEMORY
>> inbox = yes
>> hidden = yes
>> list = no
>> }
>> namespace {
>> separator = /
>> prefix =
>> location = mdbox:~/mdbox
>> }
>>
>> Client access to new mail might be a little slower, but if it eliminates
>> the index corruption issue and allows the split architecture, it may be
>> a viable option.
>
> That assumes that mails are only being delivered to INBOX (i.e. no Sieve or
> +mailbox addressing). I suppose you could do that if you can live with that
> limitation. Slightly better for performance would be to not actually keep
> INBOX mails in mbox format but use snarf plugin to move them to mdbox.
>
> And of course the above still requires that for imap/pop3 access the user is
> redirected to the same server every time. I don't really see it helping much.
I spent a decent amount of time last night researching the NFS cache
issue. It seems there is no way to completely disable NFS client
caching (in lie of rewriting the code oneself--a daunting tak), which
would seem to be the real solution to the mdbox index corruption problem.
So I went looking for alternatives and came up with the idea above.
Obviously it's far from an optimal solution and introduces some
limitations, but I thought it was worth tossing out for discussion.
Timo, it seems that when you designed mdbox you didn't have NFS based
clusters in mind. Do you consider mdbox simply not suitable for such an
NFS cluster deployment? If one has no choice but an NFS cluster
architecture, what Dovecot mailbox format do you recommend? Stick with
maildir?
In this case the OP has Netapp storage. Netapp units support both NFS
exports as well as iSCSI LUNs. If the OP could utilize iSCSI instead of
NFS, switching to GFS2 or OCFS, do you see these cluster filesystem as
preferable for mdbox?
--
Stan
Re: [Dovecot] shared folder files not displaying in thunderbird
On 19.1.2012, at 23.03, Eric Broch wrote: >> Have you checked if the files are actually still there in the maildir? > I've done a list (ls -la) of the directory where the files reside > (path.to.share.sub.dir/cur). They exist. >> You can check if this is a server problem or a client problem by running: >> doveadm fetch -u user@domain uid mailbox project.missing.sub.folder all > I did this per your instructions and there is no output. Try "touch path.to/cur" and the doveadm fetch again. Does it help? If not, there's some kind of a mismatch between what you think is happening in Dovecot and what is happening in filesystem. I'd like to know the exact full path and the mailbox name then. (Or you could run doveadm through strace and see if it's accessing the intended directory.)
Re: [Dovecot] shared folder files not displaying in thunderbird
Timo, > So the folder itself exists, but it just appears empty? Yes. > Have you tried with another IMAP client? Yes, both Outlook and Thunderbird > Have you checked if the files are actually still there in the maildir? I've done a list (ls -la) of the directory where the files reside (path.to.share.sub.dir/cur). They exist. > You can check if this is a server problem or a client problem by running: > doveadm fetch -u user@domain uid mailbox project.missing.sub.folder all I did this per your instructions and there is no output. So, email exists in the share, and it does not show up in Thunderbird, Outlook, or using doveadm. Eric
Re: [Dovecot] Problems sending email direct into publich folders
On 19.1.2012, at 14.02, Bohlken, Henning wrote: > i want to send mails direct into a public folder. If i send an email via my > local postfix the mail will be handled as a normal private mail. Dovecot does > create a mailbox in the private Namespace and do use not the mailbox in > public one. Depends on how you want to do this.. For example all mails intended to be put to public namespace could be sent to a "publicuser" named user, which has write permissions to the public namespace. Then you'll simply create a sieve script for the publicuser which redirects the mails to the wanted folder (e.g. fileinto "public/hrztest").
Re: [Dovecot] shared folder files not displaying in thunderbird
On 18.1.2012, at 16.20, Eric Broch wrote: > I have dovecot installed with the configuration below. > One of the subfolders created (using the email client) under the > '/home/vpopmail/domains/mydomain.com/shared/projects' share no longer > (it used to) displays the files located in it. There are about 150 > folders under the '/home/vpopmail/domains/mydomain.com/shared/projects' > share all of which display the files located in them, the one mentioned > used to display the contents but no longer does. > > What would be the reason that one folder would no longer display > existing files in the email client (Thunderbird) and the other folders > would? And, how do I fix this? So the folder itself exists, but it just appears empty? Have you tried with another IMAP client? Have you checked if the files are actually still there in the maildir? You can check if this is a server problem or a client problem by running: doveadm fetch -u user@domain uid mailbox project.missing.sub.folder all If the output is empty, then Dovecot doesn't see any mails in there (check if there are any files in the maildir). If it outputs something, then the client's local cache is broken and you need to tell the client to do a resync. > Would it now be simply a matter of unsubscribing the folder, deleting > the dovecot files, and resubscribing to the folder? Subscriptions won't matter. Deleting Dovecot's files may emulate the client's cache flush because it changes IMAP UIDVALIDITY.
Re: [Dovecot] Performance of Maildir vs sdbox/mdbox
On 19.1.2012, at 19.08, Mark Moseley wrote:
>> namespace {
>> separator = /
>> prefix = "#mbox/"
>> location = mbox:~/mail:INBOX=/var/mail/%u:INDEX=MEMORY
>> inbox = yes
>> hidden = yes
>> list = no
>> }
>>
>> Client access to new mail might be a little slower, but if it eliminates
>> the index corruption issue and allows the split architecture, it may be
>> a viable option.
>>
>> --
>> Stan
>
> It could be that I botched my test up somehow, but when I tested
> something similar yesterday (pointing the index at another location on
> the LDA), it didn't work.
Note that Stan used mbox format for INBOX, not mdbox.
> I was sending from the LDA server and
> confirmed that the messages made it to storage/m.# but without the
> real indexes being updated. When I checked the mailbox via IMAP, it
> never seemed to register that there was a message there, so I'm
> guessing that dovecot never looks at the storage files but just relies
> on the indexes to be correct. That sound right, Timo?
Correct. dbox absolutely relies on index files always being up to date. In some
error situations it can figure out that it should do an index rebuild and then
it finds any missing mails, but in normal situations it doesn't even try,
because that would unnecessarily waste disk IO. (And there's of course doveadm
force-resync to force it.)
Re: [Dovecot] Performance of Maildir vs sdbox/mdbox
On 19.1.2012, at 6.39, Stan Hoeppner wrote:
>> You're going to run into NFS caching troubles with the above split
>> setup. I don't recommend it. You will see error messages about index
>> corruption with it, and with dbox it can cause metadata loss.
>> http://wiki2.dovecot.org/NFS http://wiki2.dovecot.org/Director
>
> Would it be possible to fix this NFS mdbox index corruption issue in
> this split scenario by using a dual namespace and disabling indexing on
> the INBOX? The goal being no index file collisions between LDA and imap
> processes. Maybe something like:
>
> namespace {
> separator = /
> prefix = "#mbox/"
> location = mbox:~/mail:INBOX=/var/mail/%u:INDEX=MEMORY
> inbox = yes
> hidden = yes
> list = no
> }
> namespace {
> separator = /
> prefix =
> location = mdbox:~/mdbox
> }
>
> Client access to new mail might be a little slower, but if it eliminates
> the index corruption issue and allows the split architecture, it may be
> a viable option.
That assumes that mails are only being delivered to INBOX (i.e. no Sieve or
+mailbox addressing). I suppose you could do that if you can live with that
limitation. Slightly better for performance would be to not actually keep INBOX
mails in mbox format but use snarf plugin to move them to mdbox.
And of course the above still requires that for imap/pop3 access the user is
redirected to the same server every time. I don't really see it helping much.
Re: [Dovecot] Storing passwords encrypted... bcrypt?
On Tue, Jan 17, 2012 at 12:22:35AM +, Ed W wrote: > Note I personally believe there are valid reasons to store > plaintext passwords - this seems to cause huge criticism due to > the ensuing disaster which can happen if the database is pinched, > but it does allow for enhanced security in the password exchange, > so ultimately it depends on where your biggest risk lies... Exactly. In any security decision, consider the threat model first. There are too many kneejerk "secure" ideas in circulation. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: [Dovecot] Performance of Maildir vs sdbox/mdbox
On Wed, Jan 18, 2012 at 8:39 PM, Stan Hoeppner wrote:
> On 1/18/2012 7:54 AM, Timo Sirainen wrote:
>> On Wed, 2012-01-18 at 20:44 +0800, Lee Standen wrote:
>
>>> * All mail storage presented via NFS over 10Gbps Ethernet (Jumbo Frames)
>>>
>>> * Postfix will feed new email to Dovecot via LMTP
>>>
>>> * Dovecot servers have been split based on their role
>>>
>>> - Dovecot LDA Servers (running LMTP protocol)
>>>
>>> - Dovecot POP/IMAP servers (running POP/IMAP protocols)
>>
>> You're going to run into NFS caching troubles with the above split
>> setup. I don't recommend it. You will see error messages about index
>> corruption with it, and with dbox it can cause metadata loss.
>> http://wiki2.dovecot.org/NFS http://wiki2.dovecot.org/Director
>
> Would it be possible to fix this NFS mdbox index corruption issue in
> this split scenario by using a dual namespace and disabling indexing on
> the INBOX? The goal being no index file collisions between LDA and imap
> processes. Maybe something like:
>
> namespace {
> separator = /
> prefix = "#mbox/"
> location = mbox:~/mail:INBOX=/var/mail/%u:INDEX=MEMORY
> inbox = yes
> hidden = yes
> list = no
> }
> namespace {
> separator = /
> prefix =
> location = mdbox:~/mdbox
> }
>
> Client access to new mail might be a little slower, but if it eliminates
> the index corruption issue and allows the split architecture, it may be
> a viable option.
>
> --
> Stan
It could be that I botched my test up somehow, but when I tested
something similar yesterday (pointing the index at another location on
the LDA), it didn't work. I was sending from the LDA server and
confirmed that the messages made it to storage/m.# but without the
real indexes being updated. When I checked the mailbox via IMAP, it
never seemed to register that there was a message there, so I'm
guessing that dovecot never looks at the storage files but just relies
on the indexes to be correct. That sound right, Timo?
Re: [Dovecot] MASTER_AUTH_MAX_DATA_SIZE
On Thu, 2012-01-12 at 22:20 +0200, Timo Sirainen wrote: > On 12.1.2012, at 1.09, Mike Abbott wrote: > > > In 2.0.17 you increased LOGIN_MAX_INBUF_SIZE from 1024 to 4096. > > Should you also have increased MASTER_AUTH_MAX_DATA_SIZE from (1024*2) to > > (4096*2)? > > /* This should be kept in sync with LOGIN_MAX_INBUF_SIZE. Multiply it by two > > to make sure there's space to transfer the command tag */ > > Well, yes.. Although I'd rather not do that. > > 1. Command tag length needs to be restricted to something reasonable, maybe > 100 chars, so it won't have to be multiplied by 2 but just added the 100 (+1 > for NUL). > > 2. Maybe I can change the LOGIN_MAX_INBUF_SIZE back to its original size and > change the AUTHENTICATE command handling to read the SASL initial response to > a separate buffer. > > I'll try doing those next week. http://hg.dovecot.org/dovecot-2.1/rev/b86f7dd170c6 does this.
[Dovecot] Problems sending email direct into publich folders
Hi,
i want to send mails direct into a public folder. If i send an email via my
local postfix the mail will be handled as a normal private mail. Dovecot does
create a mailbox in the private Namespace and do use not the mailbox in public
one.
I hope you can help me with my little problem.
Here sone informations about my configuration:
[root@imap1 etc]# ls -la /var/dovecot/imap/public/
insgesamt 16
drwxr-x--- 3 vmail vmail 4096 19. Jan 10:12 .
drwxr-x--- 5 vmail vmail 4096 18. Jan 08:41 ..
-rw-r- 1 vmail vmail0 19. Jan 10:11 dovecot-acl-list
-rw-r- 1 vmail vmail8 19. Jan 10:12 dovecot-uidvalidity
-r--r--r-- 1 vmail vmail0 19. Jan 10:12 dovecot-uidvalidity.4f17de84
drwx-- 5 vmail vmail 4096 19. Jan 10:12 .hrztest
and here is me configuration:
# 2.0.9: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-220.2.1.el6.i686 i686 Red Hat Enterprise Linux Server
release 6.2 (Santiago)
auth_username_format = %Ln
disable_plaintext_auth = no
login_greeting = Dovecot IMAP der Jade Hochschule.
mail_access_groups = vmail
mail_debug = yes
mail_gid = vmail
mail_plugins = quota acl
mail_uid = vmail
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy
include variables body enotify environment mailbox date imapflags notify
mbox_write_locks = fcntl
namespace {
inbox = yes
location = maildir:/var/dovecot/imap/%1n/%n
prefix =
separator = /
type = private
}
namespace {
list = children
location = maildir:/var/dovecot/imap/public/
prefix = public/
separator = /
subscriptions = no
type = public
}
passdb {
args = /etc/dovecot/dovecot-ldap.conf
driver = ldap
}
passdb {
driver = pam
}
plugin {
acl = vfile
acl_shared_dict = file:/var/lib/dovecot/shared-mailboxes
mail_log_fields = uid box msgid size
quota = dict:user::file:/var/dovecot/imap/%1n/%n/dovecot-quota
quota_rule = *:storage=50MB
quota_rule2 = Trash:storage=+10%
sieve = /var/dovecot/imap/%1n/%n/.dovecot.sieve
sieve_dir = /var/dovecot/imap/%1n/%n/sieve
sieve_extensions = +notify +imapflags
sieve_quota_max_scripts = 2
}
postmaster_address = postmas...@jade-hs.de
protocols = imap pop3 lmtp sieve
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0660
user = postfix
}
}
service managesieve-login {
inet_listener sieve {
port = 4190
}
}
ssl_cert =
