Best practice for getting sieve scripts replicated?
Hi —
I do have replication between two servers running, and mail is replicated without any issues. I do have sieve running at both servers without any issues.
But replication of sieve scripts doesn't work as "expected":
Whenever I do modify my default script und upload it via "doveadm sieve put -u abc -a default < default" it becomes uploaded to the home directory of user abc as expected, but it will not be replicated to the partner server.
Whenever I do deactivate the default script by "doveadm sieve deactivate -u abc", followed by a deletion "doveadm sieve delete -u abc default" plus subsequent upload of the script "doveadm sieve put -u abc -a default < default", replication takes place instantly.
Questions: Is a modification of a sieve script supposed to be triggered the latter way? Or am I doing it the wrong way?
Thanks and regards, Michael
On 5/14/2015 2:46 PM, Michael Grimm wrote:
Hi —
I do have replication between two servers running, and mail is replicated without any issues. I do have sieve running at both servers without any issues.
But replication of sieve scripts doesn't work as "expected":
Whenever I do modify my default script und upload it via "doveadm sieve put -u abc -a default < default" it becomes uploaded to the home directory of user abc as expected, but it will not be replicated to the partner server.
Whenever I do deactivate the default script by "doveadm sieve deactivate -u abc", followed by a deletion "doveadm sieve delete -u abc default" plus subsequent upload of the script "doveadm sieve put -u abc -a default < default", replication takes place instantly.
Questions: Is a modification of a sieve script supposed to be triggered the latter way? Or am I doing it the wrong way?
That smells like a bug. What is your configuration (dovecot -n)? This should also show the versions of the packages you have installed.
Regards,
Stephan.
On 14.05.2015, at 19:21, Stephan Bosch <stephan@rename-it.nl> wrote:
On 5/14/2015 2:46 PM, Michael Grimm wrote:
Hi —
I do have replication between two servers running, and mail is replicated without any issues. I do have sieve running at both servers without any issues.
But replication of sieve scripts doesn't work as "expected":
Whenever I do modify my default script und upload it via "doveadm sieve put -u abc -a default < default" it becomes uploaded to the home directory of user abc as expected, but it will not be replicated to the partner server.
Whenever I do deactivate the default script by "doveadm sieve deactivate -u abc", followed by a deletion "doveadm sieve delete -u abc default" plus subsequent upload of the script "doveadm sieve put -u abc -a default < default", replication takes place instantly.
Questions: Is a modification of a sieve script supposed to be triggered the latter way? Or am I doing it the wrong way?
That smells like a bug. What is your configuration (dovecot -n)? This should also show the versions of the packages you have installed.
mail> doveconf -n # 2.2.17 (05e14a49507f): /usr/local/etc/dovecot/dovecot.conf # Pigeonhole version 0.4.8.rc3 (b491aa4139bc) # OS: FreeBSD 10.1-STABLE amd64 zfs auth_username_format = %Ln auth_verbose = yes deliver_log_format = msgid=%m, time=%{delivery_time}ms, status=%$ doveadm_password = </usr/local/etc/dovecot/SQLITE/doveadm-secret doveadm_port = xxxxx first_valid_gid = 5000 first_valid_uid = 5000 last_valid_gid = 5000 last_valid_uid = 5000 mail_gid = vmail mail_home = /var/mail/.homedirs/%n mail_location = mdbox:/var/mail/.maildirs/%n mail_log_prefix = "%s(%u) %{session}: " mail_plugins = " mail_log notify replication" 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 index ihave duplicate mdbox_rotate_size = 100 M passdb { args = /usr/local/etc/dovecot/dovecot-sql.conf driver = sql } plugin { mail_log_events = delete undelete expunge copy flag_change save mailbox_delete mailbox_rename mailbox_create mail_log_fields = uid box msgid flags mail_replica = tcp:dsync2.some.td replication_full_sync_interval = 1 hours sieve = ~/.dovecot.sieve sieve_dir = ~/.sieves } postmaster_address = postmaster@some.td protocols = imap lmtp sieve service aggregator { fifo_listener replication-notify-fifo { mode = 0600 user = vmail } unix_listener replication-notify { mode = 0600 user = vmail } } service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } unix_listener auth-userdb { user = vmail } } service config { unix_listener config { user = vmail } } service doveadm { inet_listener { address = dsync1.some.td port = 55588 } user = vmail } service imap-login { inet_listener imap { port = 0 } inet_listener imaps { address = *,[::] port = 993 } } service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0660 user = postfix } user = vmail } service managesieve-login { inet_listener sieve { address = *,[::] port = yyyy } } service replicator { process_min_avail = 1 unix_listener replicator-doveadm { mode = 0600 user = vmail } } ssl_cert = </etc/ssl/certs/mail.some.td.crt ssl_cipher_list = TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:!PSK:@STRENGTH ssl_key = </etc/ssl/private/mail.some.td.key ssl_protocols = !SSLv2 !SSLv3 userdb { driver = prefetch } userdb { args = /usr/local/etc/dovecot/dovecot-sql.conf driver = sql } verbose_proctitle = yes protocol imap { imap_client_workarounds = delay-newmail } protocol lmtp { mail_plugins = " mail_log notify replication sieve" }
Sorry, I should thought about providing more before :-( Sorry, again.
Feel free to ask for potential tests from my site.
HTH, Michael
On 5/14/2015 9:32 PM, Michael Grimm wrote:
On 14.05.2015, at 19:21, Stephan Bosch <stephan@rename-it.nl> wrote: On 5/14/2015 2:46 PM, Michael Grimm wrote:
I do have replication between two servers running, and mail is replicated without any issues. I do have sieve running at both servers without any issues.
But replication of sieve scripts doesn't work as "expected":
Whenever I do modify my default script und upload it via "doveadm sieve put -u abc -a default < default" it becomes uploaded to the home directory of user abc as expected, but it will not be replicated to the partner server.
Whenever I do deactivate the default script by "doveadm sieve deactivate -u abc", followed by a deletion "doveadm sieve delete -u abc default" plus subsequent upload of the script "doveadm sieve put -u abc -a default < default", replication takes place instantly.
Questions: Is a modification of a sieve script supposed to be triggered the latter way? Or am I doing it the wrong way?
That smells like a bug. What is your configuration (dovecot -n)? This should also show the versions of the packages you have installed. Sorry, I should thought about providing more before :-( Sorry, again.
Feel free to ask for potential tests from my site.
I had to setup my own replication (I usually only test with manual dsync invocation). Still, I cannot reproduce your problem: replication occurs instantly. Our setups aren't very different, with the exception that I installed two Dovecot instances on one server with replication configured between them.
Do your logs show anything strange? What do your logs show when you enable mail_debug=yes?
What do the doveadm commands show when the -D option is added?
Is your configuration completely equal at both servers (except of course for the configured replication peer)?
Regards,
Stephan.
On 5/15/2015 1:03 PM, Stephan Bosch wrote:
On 5/14/2015 9:32 PM, Michael Grimm wrote:
On 14.05.2015, at 19:21, Stephan Bosch <stephan@rename-it.nl> wrote: On 5/14/2015 2:46 PM, Michael Grimm wrote:
I do have replication between two servers running, and mail is replicated without any issues. I do have sieve running at both servers without any issues.
But replication of sieve scripts doesn't work as "expected":
Whenever I do modify my default script und upload it via "doveadm sieve put -u abc -a default < default" it becomes uploaded to the home directory of user abc as expected, but it will not be replicated to the partner server.
Whenever I do deactivate the default script by "doveadm sieve deactivate -u abc", followed by a deletion "doveadm sieve delete -u abc default" plus subsequent upload of the script "doveadm sieve put -u abc -a default < default", replication takes place instantly.
Questions: Is a modification of a sieve script supposed to be triggered the latter way? Or am I doing it the wrong way? That smells like a bug. What is your configuration (dovecot -n)? This should also show the versions of the packages you have installed. Sorry, I should thought about providing more before :-( Sorry, again.
Feel free to ask for potential tests from my site. I had to setup my own replication (I usually only test with manual dsync invocation). Still, I cannot reproduce your problem: replication occurs instantly. Our setups aren't very different, with the exception that I installed two Dovecot instances on one server with replication configured between them.
Do your logs show anything strange? What do your logs show when you enable mail_debug=yes?
What do the doveadm commands show when the -D option is added?
Is your configuration completely equal at both servers (except of course for the configured replication peer)?
This may be helpful:
http://hg.dovecot.org/dovecot-2.2/rev/7cf62f28fd62 (now included in 2.2.18).
Regards,
Stephan.
Stephan Bosch <stephan@rename-it.nl> wrote:
On 5/15/2015 1:03 PM, Stephan Bosch wrote:
On 5/14/2015 9:32 PM, Michael Grimm wrote:
On 14.05.2015, at 19:21, Stephan Bosch <stephan@rename-it.nl> wrote: On 5/14/2015 2:46 PM, Michael Grimm wrote:
I do have replication between two servers running, and mail is replicated without any issues. I do have sieve running at both servers without any issues.
But replication of sieve scripts doesn't work as "expected":
Whenever I do modify my default script und upload it via "doveadm sieve put -u abc -a default < default" it becomes uploaded to the home directory of user abc as expected, but it will not be replicated to the partner server.
Whenever I do deactivate the default script by "doveadm sieve deactivate -u abc", followed by a deletion "doveadm sieve delete -u abc default" plus subsequent upload of the script "doveadm sieve put -u abc -a default < default", replication takes place instantly.
Questions: Is a modification of a sieve script supposed to be triggered the latter way? Or am I doing it the wrong way? That smells like a bug. What is your configuration (dovecot -n)? This should also show the versions of the packages you have installed. Sorry, I should thought about providing more before :-( Sorry, again.
Feel free to ask for potential tests from my site. I had to setup my own replication (I usually only test with manual dsync invocation). Still, I cannot reproduce your problem: replication occurs instantly. Our setups aren't very different, with the exception that I installed two Dovecot instances on one server with replication configured between them.
Do your logs show anything strange?
No, I never found something strange. That why I began thinking about my expectations were wrong regarding how sieve replication is supposed to work.
What do your logs show when you enable mail_debug=yes?
Nothing strange as well.
What do the doveadm commands show when the -D option is added?
This I didn't try :-(
Is your configuration completely equal at both servers (except of course for the configured replication peer)?
Yes, absolutely identical. Same config, same hg revisions, same OS, etc.
This may be helpful:
http://hg.dovecot.org/dovecot-2.2/rev/7cf62f28fd62 (now included in 2.2.18).
Well, I do feel like an idiot! I swear, sieve replication never ran as expected, I always had to do it the way mentioned above. Today, after compiling brand new dovecot, sieve replication works as expected and as you confirmed it should work. I really tried hard to reproduce my issue, but: to no avail ;-) No idea whether those last minute revisions made the trick or something else …
So I feel very sorry having bothered you without real cause :-(
Thanks and with kind regards, Michael
@Timo: There's a typo in src/plugins/replication/replication-plugin.c: s/transction commit/transaction commit/
participants (2)
-
Michael Grimm
-
Stephan Bosch