[Dovecot] dsync replication available for testing
In dovecot-2.1 hg you can now test dsync-based replication. Everything isn't finished yet, but it appears to work and I've enabled it for my @dovecot.fi mails. Some issues:
- public namespace isn't replicated at all
- shared namespace is replicated, but not private mail flags
- I've only tested SSH replication setup now, not director replication setup (and director setup is still missing many things)
- SSH replication setup uses aggregator process, which isn't really necessary and can probably be avoided in future
Below is a configuration for virtual user setup. System user configuration works pretty much the same, except doveadm/ssh is run as root.
Try first that dsync works successfully with ssh in host1:
doveadm sync -u user@domain remote:vmail@host2.example.com
and also in host2:
doveadm sync -u user@domain remote:vmail@host1.example.com
mail_plugins = $mail_plugins notify replication
service aggregator { # give enough permissions for mail processes fifo_listener replication-notify-fifo { user = vmail mode = 0600 } unix_listener replication-notify { user = vmail mode = 0600 } }
service replicator { # start replication at startup process_min_avail = 1 }
plugin { # host1 replicates to host2 mail_replica = remote:vmail@host2.example.com # host2 replicates to host1 #mail_replica = remote:vmail@host1.example.com }
#dsync_remote_cmd = ssh -l%{login} %{host} doveadm dsync-server -u%u -l%{lock_timeout} -n%{namespace}
service doveadm { # if you're using a single virtual user, set this to # start ssh as vmail (not root) user = vmail }
Hi --
On 04.03.2012, at 11:44, Timo Sirainen wrote:
In dovecot-2.1 hg you can now test dsync-based replication.
Great news. I would love to test it, if I will be able to run this on a test account, only. All other users should become synced the "old way" for the time being.
Would that be possible with the current implementation?
Regards, Michael
On 4.3.2012, at 13.34, Michael Grimm wrote:
On 04.03.2012, at 11:44, Timo Sirainen wrote:
In dovecot-2.1 hg you can now test dsync-based replication.
Great news. I would love to test it, if I will be able to run this on a test account, only. All other users should become synced the "old way" for the time being.
Would that be possible with the current implementation?
Replicator syncs all users at startup. If you can change your userdb iteration to return only one test user for replicator that avoids it. (You may be able to do protocol replicator { userdb {..} } and protocol !replicator { .. })
You can enable replication plugin only for one user by changing mail_plugins setting via userdb extra fields.
Anyway, replicator simply runs doveadm, so there's not much that can go wrong. So you could even ignore 1) and just let it sync everyone at startup.
Hi --
On 04.03.2012, at 12:38, Timo Sirainen wrote:
On 4.3.2012, at 13.34, Michael Grimm wrote:
On 04.03.2012, at 11:44, Timo Sirainen wrote:
In dovecot-2.1 hg you can now test dsync-based replication.
Great news. I would love to test it, if I will be able to run this on a test account, only. All other users should become synced the "old way" for the time being.
Would that be possible with the current implementation?
Replicator syncs all users at startup. If you can change your userdb iteration to return only one test user for replicator that avoids it. (You may be able to do protocol replicator { userdb {..} } and protocol !replicator { .. })
You can enable replication plugin only for one user by changing mail_plugins setting via userdb extra fields.
Anyway, replicator simply runs doveadm, so there's not much that can go wrong. So you could even ignore 1) and just let it sync everyone at startup.
Does that mean that the new functionality (queue) does only run dsync replication the usual way whenever new mail arrives? That's at least what I read in your code committed today (but I'm not that good in reading code I do have to confess).
If you could approve my assumption, I'm willing to give it a try to all users.
Regards, Michael
On 4.3.2012, at 23.39, Michael Grimm wrote:
Anyway, replicator simply runs doveadm, so there's not much that can go wrong. So you could even ignore 1) and just let it sync everyone at startup.
Does that mean that the new functionality (queue) does only run dsync replication the usual way whenever new mail arrives? That's at least what I read in your code committed today (but I'm not that good in reading code I do have to confess).
If you could approve my assumption, I'm willing to give it a try to all users.
Yes, the replicator simply runs "doveadm sync -u user@domain -d" (and sometimes with -f). The -d gets the default location from mail_replica setting.
On Sun, Mar 04, 2012 at 01:38:14PM +0200, Timo Sirainen wrote:
Great news. I would love to test it, if I will be able to run this on a test account, only. All other users should become synced the "old way" for the time being.
Would that be possible with the current implementation?
- Replicator syncs all users at startup. If you can change your userdb iteration to return only one test user for replicator that avoids it. (You may be able to do protocol replicator { userdb {..} } and protocol !replicator { .. })
IMHO it would be great if it didn't sync all users. We probably av have hundreds of thousands of inactive users that we would like to sync at a later point. Also when we provision users that's just an entry in a LDAP-directory without any files or directories. So dovecot shouldn't create any directories for these before they've received mail or logged in.
So, ideally (for us), dovecot should keep a log over which accounts are active (has received or checked mail), and only sync users that has been active for the last $timeperiode on startup.
-jf
On 5.3.2012, at 10.35, Jan-Frode Myklebust wrote:
- Replicator syncs all users at startup. If you can change your userdb iteration to return only one test user for replicator that avoids it. (You may be able to do protocol replicator { userdb {..} } and protocol !replicator { .. })
IMHO it would be great if it didn't sync all users. We probably av have hundreds of thousands of inactive users that we would like to sync at a later point. Also when we provision users that's just an entry in a LDAP-directory without any files or directories. So dovecot shouldn't create any directories for these before they've received mail or logged in.
So, ideally (for us), dovecot should keep a log over which accounts are active (has received or checked mail), and only sync users that has been active for the last $timeperiode on startup.
Well, all of this could be done already, although not very automatically.. Whenever a new mail is delivered or user is logged in, the user's last-login timestamp in SQL could be updated. And replicator's userdb iterate_query could return only users whose last-login timestamp is new enough. The SQL userdb could be used only by replicator, everything else could keep using LDAP.
On Mon, Mar 05, 2012 at 12:45:26PM +0200, Timo Sirainen wrote:
So, ideally (for us), dovecot should keep a log over which accounts are active (has received or checked mail), and only sync users that has been active for the last $timeperiode on startup.
Well, all of this could be done already, although not very automatically.. Whenever a new mail is delivered or user is logged in, the user's last-login timestamp in SQL could be updated. And replicator's userdb iterate_query could return only users whose last-login timestamp is new enough. The SQL userdb could be used only by replicator, everything else could keep using LDAP.
.. or we could keep touching /activemailaccounts/$address in post-login scripts, and run "doveadm sync" for any user updated the last $timeperiode and avoid the need for SQL-userdatabase. But we still don't have a last-login update on lmtp delivery... or has this changed?
-jf
On 5.3.2012, at 14.35, Jan-Frode Myklebust wrote:
On Mon, Mar 05, 2012 at 12:45:26PM +0200, Timo Sirainen wrote:
So, ideally (for us), dovecot should keep a log over which accounts are active (has received or checked mail), and only sync users that has been active for the last $timeperiode on startup.
Well, all of this could be done already, although not very automatically.. Whenever a new mail is delivered or user is logged in, the user's last-login timestamp in SQL could be updated. And replicator's userdb iterate_query could return only users whose last-login timestamp is new enough. The SQL userdb could be used only by replicator, everything else could keep using LDAP.
.. or we could keep touching /activemailaccounts/$address in post-login scripts, and run "doveadm sync" for any user updated the last $timeperiode and avoid the need for SQL-userdatabase. But we still don't have a last-login update on lmtp delivery... or has this changed?
It would be pretty simple to write such a plugin that globally does it for all imap/pop3/lmtp. Here, works for v2.0 and v2.1:
Hi,
On 03/04/12 11:44, Timo Sirainen wrote:
In dovecot-2.1 hg you can now test dsync-based replication. Everything isn't finished yet, but it appears to work and I've enabled it for my @dovecot.fi mails. Some issues:
- public namespace isn't replicated at all
- shared namespace is replicated, but not private mail flags
- I've only tested SSH replication setup now, not director replication setup (and director setup is still missing many things)
- SSH replication setup uses aggregator process, which isn't really necessary and can probably be avoided in future Do you plan to make it more performant in the future? I mean calling doveadm (and ssh) for every change -even when they are aggregated- seems to be very resource intensive, it won't keep up on a machine with a lot of modifications happening every seconds.
It would be good to have constantly running daemons on both sides to eliminate the high startup/teardown costs.
(if I understand things correctly)
Thanks for working on this.
On 5.3.2012, at 9.25, Attila Nagy wrote:
On 03/04/12 11:44, Timo Sirainen wrote:
In dovecot-2.1 hg you can now test dsync-based replication. Everything isn't finished yet, but it appears to work and I've enabled it for my @dovecot.fi mails. Some issues:
Do you plan to make it more performant in the future? I mean calling doveadm (and ssh) for every change -even when they are aggregated- seems to be very resource intensive, it won't keep up on a machine with a lot of modifications happening every seconds.
Sure the idea is to improve the performance :) There are two ways:
Use longer running SSH sessions which dsync more than one user at a time.
Use TCP connections instead of SSH.
It would be good to have constantly running daemons on both sides to eliminate the high startup/teardown costs.
The process startup/teardown costs are pretty low. I'll need to improve dsync's performance at some point though. Actually I pretty much redesigned the whole dsync already, but I'll probably leave that to v2.2. The current design can still be improved.
On 03/05/12 11:08, Timo Sirainen wrote:
On 5.3.2012, at 9.25, Attila Nagy wrote:
On 03/04/12 11:44, Timo Sirainen wrote:
In dovecot-2.1 hg you can now test dsync-based replication. Everything isn't finished yet, but it appears to work and I've enabled it for my @dovecot.fi mails. Some issues:
Do you plan to make it more performant in the future? I mean calling doveadm (and ssh) for every change -even when they are aggregated- seems to be very resource intensive, it won't keep up on a machine with a lot of modifications happening every seconds. Sure the idea is to improve the performance :) There are two ways:
Use longer running SSH sessions which dsync more than one user at a time.
Use TCP connections instead of SSH. Don't forget about connection pooling to get concurrency. :) BTW, despite being somewhat harder to implement, I personally like native connections better.
It would be good to have constantly running daemons on both sides to eliminate the high startup/teardown costs. The process startup/teardown costs are pretty low. I'll need to improve dsync's performance at some point though. Actually I pretty much redesigned the whole dsync already, but I'll probably leave that to v2.2. The current design can still be improved.
It depends. For a moderately loaded server I get this: # time ssh root@be02 "echo 1" 1 0.000u 0.009s 0:00.30 0.0% 0+0k 0+0io 0pf+0w ICMP echo RTT is 0.878 ms.
So the ssh connection adds ~29 ms overhead to each sync request.
Yes, dsync seems to need some optimizations too. :) I've tried previously on one pair of our servers with a higher level of concurrency (8-16 or so, I can't remember), and it couldn't keep up with the changes. The method was similar to yours:
- an external library wrote modified user ids to a file
- in an endless loop a script picked up those (moved the file) and started parallel dsyncs (on ssh)
The runs were longer and longer... BTW, we modify the maildirs externally, so this adds a lot of inefficiency here...
On 5.3.2012, at 14.15, Attila Nagy wrote:
On 03/04/12 11:44, Timo Sirainen wrote:
In dovecot-2.1 hg you can now test dsync-based replication. Everything isn't finished yet, but it appears to work and I've enabled it for my @dovecot.fi mails. Some issues:
Do you plan to make it more performant in the future? I mean calling doveadm (and ssh) for every change -even when they are aggregated- seems to be very resource intensive, it won't keep up on a machine with a lot of modifications happening every seconds. Sure the idea is to improve the performance :) There are two ways:
Use longer running SSH sessions which dsync more than one user at a time.
Use TCP connections instead of SSH. Don't forget about connection pooling to get concurrency. :)
There's already concurrency. replication_max_conns (default 10) specifies how many dsyncs can be running concurrently.
BTW, despite being somewhat harder to implement, I personally like native connections better.
Native = TCP? It's not difficult, probably a few lines of more code since doveadm server can already listening for TCP connections. It doesn't support SSL though.
It would be good to have constantly running daemons on both sides to eliminate the high startup/teardown costs. The process startup/teardown costs are pretty low. I'll need to improve dsync's performance at some point though. Actually I pretty much redesigned the whole dsync already, but I'll probably leave that to v2.2. The current design can still be improved.
It depends. For a moderately loaded server I get this: # time ssh root@be02 "echo 1"
I meant doveadm/dsync costs, ssh startup is rather slow.
Yes, dsync seems to need some optimizations too. :) I've tried previously on one pair of our servers with a higher level of concurrency (8-16 or so, I can't remember), and it couldn't keep up with the changes. The method was similar to yours:
- an external library wrote modified user ids to a file
- in an endless loop a script picked up those (moved the file) and started parallel dsyncs (on ssh)
The runs were longer and longer...
dsync doesn't currently take enough advantage of modseqs and send only the changed data.
BTW, we modify the maildirs externally, so this adds a lot of inefficiency here...
Definitely doesn't help.
On 5.3.2012, at 14.15, Attila Nagy wrote:
On 03/04/12 11:44, Timo Sirainen wrote:
In dovecot-2.1 hg you can now test dsync-based replication. Everything isn't finished yet, but it appears to work and I've enabled it for my @dovecot.fi mails. Some issues:
Do you plan to make it more performant in the future? I mean calling doveadm (and ssh) for every change -even when they are aggregated- seems to be very resource intensive, it won't keep up on a machine with a lot of modifications happening every seconds. Sure the idea is to improve the performance :) There are two ways:
Use longer running SSH sessions which dsync more than one user at a time.
Use TCP connections instead of SSH. Don't forget about connection pooling to get concurrency. :) There's already concurrency. replication_max_conns (default 10) specifies how many dsyncs can be running concurrently. Good to hear.
BTW, despite being somewhat harder to implement, I personally like native connections better. Native = TCP? It's not difficult, probably a few lines of more code since doveadm server can already listening for TCP connections. It doesn't support SSL though. Yes. For large installations there may be some backend channel already (SSL tunnels, IPSec etc), so it seems to be OK.
It would be good to have constantly running daemons on both sides to eliminate the high startup/teardown costs. The process startup/teardown costs are pretty low. I'll need to improve dsync's performance at some point though. Actually I pretty much redesigned the whole dsync already, but I'll probably leave that to v2.2. The current design can still be improved.
It depends. For a moderately loaded server I get this: # time ssh root@be02 "echo 1" I meant doveadm/dsync costs, ssh startup is rather slow. I see. Running from network makes this worse slightly. Long running
On 03/05/12 13:48, Timo Sirainen wrote: processes with long running connections rule. :)
Yes, dsync seems to need some optimizations too. :) I've tried previously on one pair of our servers with a higher level of concurrency (8-16 or so, I can't remember), and it couldn't keep up with the changes. The method was similar to yours:
- an external library wrote modified user ids to a file
- in an endless loop a script picked up those (moved the file) and started parallel dsyncs (on ssh)
The runs were longer and longer... dsync doesn't currently take enough advantage of modseqs and send only the changed data.
Hm. What is your estimate about the performance capability of the current "best" replication scheme available in Dovecot? I know it's hard to tell, because there are a lot of parameters, but do you think it's good for a real world environment with (10-1000*x :) thousands of users, and a lot of changes? BTW, it would even better to have something scalable as Cassandra, so Dovecout wouldn't have to worry about replication and (read/write) scalability.
BTW, we modify the maildirs externally, so this adds a lot of inefficiency here... Definitely doesn't help.
I know, we are working on this. :)
On 5.3.2012, at 15.11, Attila Nagy wrote:
dsync doesn't currently take enough advantage of modseqs and send only the changed data. Hm. What is your estimate about the performance capability of the current "best" replication scheme available in Dovecot? I know it's hard to tell, because there are a lot of parameters, but do you think it's good for a real world environment with (10-1000*x :) thousands of users, and a lot of changes?
The plan is to get it working with at least a few thousand users to several tens of thousands.
BTW, it would even better to have something scalable as Cassandra, so Dovecout wouldn't have to worry about replication and (read/write) scalability.
Yes, that's also in my future plans, but it's a larger change. Also I don't think Cassandra (or any nosql?) still supports application-level merging of data after split brain.
Hi --
On 04.03.2012 11:44, Timo Sirainen wrote:
In dovecot-2.1 hg you can now test dsync-based replication. Everything isn't finished yet, but it appears to work and I've enabled it for my @dovecot.fi mails.
I did give it a try starting some days ago, and I can confirm that you are right, dsync replication can be used, but there are some issues, see below.
Let me start with replicator's configuration ...
Below is a configuration for virtual user setup. [...] service doveadm { # if you're using a single virtual user, set this to # start ssh as vmail (not root) user = vmail }
... that led to the following complaints at start-up:
| dovecot: master: Dovecot v2.1.1 (d66568d34e40) starting up | dovecot: doveadm: Error: Error reading configuration: net_connect_unix(/var/run/dovecot/config) failed: Permission denied | [...] | (repeatedly, presumably for the number of users in userdb?)
Therefore, I modified dsync_remote_cmd ...
dsync_remote_cmd = ssh -p 1234 -l vmail %{host} doveadm dsync-server -u%u -l%{lock_timeout} -n%{namespace}
... and used an empty 'service doveadm { }' instead. That worked, but I would love to run doveadm as vmail user (security), though. How should I do that without running into the error messages above?
Now some observations regarding replicator:
I see a lot of error messages whenever replicator is in action like (although everything is being synced correctly):
| <mail.err> mail dovecot: dsync-local(test): Error: remote: dsync-remote(test): Info: save: box=INBOX, uid=27, msgid=<3V2JfH5Kv4z7Ft@example.tld>, size=547, from=test@example.tld (admin), flags=()
| <mail.info> mail dovecot: dsync-local(test): Error: remote: dsync-remote(test): Info: flag_change: box=TEST, uid=27568, msgid=<20120307144810.6360A74F013@example.tld>, size=435, from=test@example.tld, flags=(\Seen)
JFTR: I do have mail_log plugin activated.
Some testing results:
I ran a test by sending locally produced mails every other minute on both servers simultaneously. That test ran for ~5 hours. All mails became synced correctly, and no losses were observable, but some duplicates.
I did send 100 small test mails from a distant server to my mailservers (mx1 and mx2):
a) replicator and dsync deactivated: received 100 distinct mails (57 at mx1, 43 at mx2). b) now, replicator active: 172 mails (100 distinct, a lot of duplicates (up to 8 incarnations of the very same mail).
Ok, 2b) is a rather 'mailbomb-like' scenario, but it worries me a bit: One of my users is receiving mails from a mailing list that sends individual mails batch-wise ...
replicator active: 1000 mails sent ended in 4523 mails at every server. Well, that was a mailbomb :-)
replicator active: 100 (and even 1000) locally produced mails at one server only: all 100 (and 1000 mails) became synced, prefectly well, without duplicates.
replicator active: 100 locally produced mails at both servers simultaneously: 341 mails, thus a lot of multiple incarnations. (This test differed from 1) because all mails were sent in one batch.)
Final note to these tests: It doesn't matter whether sieve with redirecting, or sieve with redirecting and copying, or no sieve at all has been involved.
It seems to me, that whenever a larger number of mails arrive on both servers simultaneously, the replicator gets into trouble [1]. I am unsure if one can expect that a replicator should deal with such stress, though. Or?
Résumé: The overall performance of replicator is very good from my point of view for my conditions (handful users, average workload of roughly 1000 mails a day).
Thank you for replicator and regards, Michael
[1] JFTR: I did similar tests in the past with dsync running from cron every other minute with similar results.
On Thu, 2012-03-08 at 11:26 +0100, Michael Grimm wrote:
Let me start with replicator's configuration ...
Below is a configuration for virtual user setup. [...] service doveadm { # if you're using a single virtual user, set this to # start ssh as vmail (not root) user = vmail }
... that led to the following complaints at start-up:
| dovecot: master: Dovecot v2.1.1 (d66568d34e40) starting up | dovecot: doveadm: Error: Error reading configuration: net_connect_unix(/var/run/dovecot/config) failed: Permission denied | [...] | (repeatedly, presumably for the number of users in userdb?)
You can do for example:
service config { unix_listener config { user = vmail } }
Now some observations regarding replicator:
I see a lot of error messages whenever replicator is in action like (although everything is being synced correctly):
| <mail.err> mail dovecot: dsync-local(test): Error: remote: dsync-remote(test): Info: save: box=INBOX, uid=27, msgid=<3V2JfH5Kv4z7Ft@example.tld>, size=547, from=test@example.tld (admin), flags=()
| <mail.info> mail dovecot: dsync-local(test): Error: remote: dsync-remote(test): Info: flag_change: box=TEST, uid=27568, msgid=<20120307144810.6360A74F013@example.tld>, size=435, from=test@example.tld, flags=(\Seen)
JFTR: I do have mail_log plugin activated.
Hmm. Right. I guess all the logging should go to the log files instead of via the ssh pipe. Of course that would also require that dsync has write access to your log files.
It seems to me, that whenever a larger number of mails arrive on both servers simultaneously, the replicator gets into trouble [1]. I am unsure if one can expect that a replicator should deal with such stress, though. Or?
Were these mails delivered via LMTP or dovecot-lda?
The locks should prevent duplicates I think, so there's something still going wrong.
On 08.03.2012, at 12:35, Timo Sirainen wrote:
On Thu, 2012-03-08 at 11:26 +0100, Michael Grimm wrote:
Now some observations regarding replicator:
I see a lot of error messages whenever replicator is in action like (although everything is being synced correctly):
| <mail.err> mail dovecot: dsync-local(test): Error: remote: dsync-remote(test): Info: save: box=INBOX, uid=27, msgid=<3V2JfH5Kv4z7Ft@example.tld>, size=547, from=test@example.tld (admin), flags=()
| <mail.info> mail dovecot: dsync-local(test): Error: remote: dsync-remote(test): Info: flag_change: box=TEST, uid=27568, msgid=<20120307144810.6360A74F013@example.tld>, size=435, from=test@example.tld, flags=(\Seen)
JFTR: I do have mail_log plugin activated.
Hmm. Right. I guess all the logging should go to the log files instead of via the ssh pipe. Of course that would also require that dsync has write access to your log files.
I'd like to come back to this old thread: What would one need to do to get rid of these lines from mail_log plugin?
Regards, Michael
On 19.8.2012, at 12.51, Michael Grimm wrote:
- I see a lot of error messages whenever replicator is in action like (although everything is being synced correctly):
| <mail.err> mail dovecot: dsync-local(test): Error: remote: dsync-remote(test): Info: save: box=INBOX, uid=27, msgid=<3V2JfH5Kv4z7Ft@example.tld>, size=547, from=test@example.tld (admin), flags=()
| <mail.info> mail dovecot: dsync-local(test): Error: remote: dsync-remote(test): Info: flag_change: box=TEST, uid=27568, msgid=<20120307144810.6360A74F013@example.tld>, size=435, from=test@example.tld, flags=(\Seen)
JFTR: I do have mail_log plugin activated.
Hmm. Right. I guess all the logging should go to the log files instead of via the ssh pipe. Of course that would also require that dsync has write access to your log files.
I'd like to come back to this old thread: What would one need to do to get rid of these lines from mail_log plugin?
Not enable mail_log for doveadm:
protocol !doveadm { mail_plugins = $mail_plugins = mail_log }
or alternatively override it only for the dsync command with doveadm -o mail_plugins=...
On 23.08.2012, at 22:01, Timo Sirainen wrote:
On 19.8.2012, at 12.51, Michael Grimm wrote:
- I see a lot of error messages whenever replicator is in action like (although everything is being synced correctly):
| <mail.err> mail dovecot: dsync-local(test): Error: remote: dsync-remote(test): Info: save: box=INBOX, uid=27, msgid=<3V2JfH5Kv4z7Ft@example.tld>, size=547, from=test@example.tld (admin), flags=()
| <mail.info> mail dovecot: dsync-local(test): Error: remote: dsync-remote(test): Info: flag_change: box=TEST, uid=27568, msgid=<20120307144810.6360A74F013@example.tld>, size=435, from=test@example.tld, flags=(\Seen)
JFTR: I do have mail_log plugin activated.
Hmm. Right. I guess all the logging should go to the log files instead of via the ssh pipe. Of course that would also require that dsync has write access to your log files.
I'd like to come back to this old thread: What would one need to do to get rid of these lines from mail_log plugin?
Not enable mail_log for doveadm:
protocol !doveadm { mail_plugins = $mail_plugins = mail_log }
JFTR: That didn't work.
or alternatively override it only for the dsync command with doveadm -o mail_plugins=...
But, a ...
dsync_remote_cmd = ssh -l%{login} %{host} doveadm -o mail_plugins= dsync-server -u%u -l%{lock_timeout} -n%{namespace}... did omit those error messages successfully.
Thanks and regards, Michael
On 25.8.2012, at 19.09, Michael Grimm wrote:
Not enable mail_log for doveadm:
protocol !doveadm { mail_plugins = $mail_plugins = mail_log }
JFTR: That didn't work.
This would omit it from the local dsync.
or alternatively override it only for the dsync command with doveadm -o mail_plugins=...
But, a ...
dsync_remote_cmd = ssh -l%{login} %{host} doveadm -o mail_plugins= dsync-server -u%u -l%{lock_timeout} -n%{namespace}
... did omit those error messages successfully.
And yes, this would omit it from the remote dsync.
participants (4)
-
Attila Nagy
-
Jan-Frode Myklebust
-
Michael Grimm
-
Timo Sirainen