On 24/08/2016 10:58 AM, Stephan Bosch wrote:> Op 8/1/2016 om 3:37 AM schreef Reuben Farrelly: >> In other words, the rules did eventually get propagated across, and >> based on the file sizes they are complete. >> >> But there is obviously something amiss with handling of dates (which >> in turn may relate to how the system determines that the file on each >> server is up to date or not, I guess). In this case the two systems >> are in different timezones - the primary is GMT+10 and the secondary >> GMT+8. >> >> Also the status of active users is not always replicated either. On >> one host the output of 'doveadm sieve list -A' shows my own account as >> ACTIVE but the other host shows all users - except for my account - as >> being active, and the sieve script for my account is not being >> replicated. > This should fix the file timestamps getting set at unix time_t 0: > > https://github.com/dovecot/pigeonhole/commit/af91dd3f2d78da752292dce27f9e76d2c936868c > > I haven't been able to replicate the situation where this occurs though, > since my current replication setup is very simple. > > I need to extend my replication setup to test this more thoroughly. > > So, please test this at your end first. > > Regards, > > Stephan.Thanks Stephan. I have re-tested and the dates are now all look to be correct on the replicated scripts. We can cross that off as fixed now. There is still a problem with the scripts not being replicated though between replicated hosts. They do eventually catch up many hours later. I don't know what the trigger is for them updating but it's not triggered by delivery attempts (as every time a delivery was attempted the secondary complained about the missing sieve script). Thanks, Reuben
Hey guys, I was gonna report this issue too. New script FILES get replicated right away but changes to an existing file are only replicated with a full sync (looks like this is every 24h by default). My assumption is this happens bc there?s no index file for sieve scripts. Cheers, Jean-Luc> On Sep 7, 2016, at 5:44 AM, Reuben Farrelly <reuben-dovecot at reub.net> wrote: > > > > > > On 24/08/2016 10:58 AM, Stephan Bosch wrote: >> >> >> Op 8/1/2016 om 3:37 AM schreef Reuben Farrelly: >>> >>> >>> In other words, the rules did eventually get propagated across, and >>> based on the file sizes they are complete. >>> >>> >>> But there is obviously something amiss with handling of dates (which >>> in turn may relate to how the system determines that the file on each >>> server is up to date or not, I guess). In this case the two systems >>> are in different timezones - the primary is GMT+10 and the secondary >>> GMT+8. >>> >>> >>> Also the status of active users is not always replicated either. On >>> one host the output of 'doveadm sieve list -A' shows my own account as >>> ACTIVE but the other host shows all users - except for my account - as >>> being active, and the sieve script for my account is not being >>> replicated. >>> >> >> This should fix the file timestamps getting set at unix time_t 0: >> >> >> https://github.com/dovecot/pigeonhole/commit/af91dd3f2d78da752292dce27f9e76d2c936868c >> >> >> I haven't been able to replicate the situation where this occurs though, >> since my current replication setup is very simple. >> >> >> I need to extend my replication setup to test this more thoroughly. >> >> >> So, please test this at your end first. >> >> >> Regards, >> >> >> Stephan. >> > > > > > Thanks Stephan. I have re-tested and the dates are now all look to be? > correct on the replicated scripts. We can cross that off as fixed now. > > > There is still a problem with the scripts not being replicated though? > between replicated hosts. They do eventually catch up many hours? > later. I don't know what the trigger is for them updating but it's not? > triggered by delivery attempts (as every time a delivery was attempted? > the secondary complained about the missing sieve script). > > > Thanks, > Reuben >
Op 8-9-2016 om 0:40 schreef Jean-Luc Wasmer:> Hey guys, > > > I was gonna report this issue too. > New script FILES get replicated right away but changes to an existing file are only replicated with a full sync (looks like this is every 24h by default). > > > My assumption is this happens bc there?s no index file for sieve scripts.Looking at his is on my list. Will do that soon.. Regards, Stephan.> > > >> On Sep 7, 2016, at 5:44 AM, Reuben Farrelly <reuben-dovecot at reub.net> wrote: >> >> >> >> >> >> On 24/08/2016 10:58 AM, Stephan Bosch wrote: >>> >>> Op 8/1/2016 om 3:37 AM schreef Reuben Farrelly: >>>> >>>> In other words, the rules did eventually get propagated across, and >>>> based on the file sizes they are complete. >>>> >>>> >>>> But there is obviously something amiss with handling of dates (which >>>> in turn may relate to how the system determines that the file on each >>>> server is up to date or not, I guess). In this case the two systems >>>> are in different timezones - the primary is GMT+10 and the secondary >>>> GMT+8. >>>> >>>> >>>> Also the status of active users is not always replicated either. On >>>> one host the output of 'doveadm sieve list -A' shows my own account as >>>> ACTIVE but the other host shows all users - except for my account - as >>>> being active, and the sieve script for my account is not being >>>> replicated. >>>> >>> This should fix the file timestamps getting set at unix time_t 0: >>> >>> >>> https://github.com/dovecot/pigeonhole/commit/af91dd3f2d78da752292dce27f9e76d2c936868c >>> >>> >>> I haven't been able to replicate the situation where this occurs though, >>> since my current replication setup is very simple. >>> >>> >>> I need to extend my replication setup to test this more thoroughly. >>> >>> >>> So, please test this at your end first. >>> >>> >>> Regards, >>> >>> >>> Stephan. >>> >> >> >> >> Thanks Stephan. I have re-tested and the dates are now all look to be >> correct on the replicated scripts. We can cross that off as fixed now. >> >> >> There is still a problem with the scripts not being replicated though >> between replicated hosts. They do eventually catch up many hours >> later. I don't know what the trigger is for them updating but it's not >> triggered by delivery attempts (as every time a delivery was attempted >> the secondary complained about the missing sieve script). >> >> >> Thanks, >> Reuben >>
Hi, Could you guys send us your current configuration (output from `dovecot -n`)? First of all, we would like to compare it to a configuration-related problem we've seen in the wild. That is a bit of a long shot. That issue revolves around the target username not always being the same for one physical user (e.g. when aliases are involved). In any case, the configuration may be useful for reproducing the problem at our end. Regards, Stephan. Op 7-9-2016 om 11:44 schreef Reuben Farrelly:> > > On 24/08/2016 10:58 AM, Stephan Bosch wrote: >> Op 8/1/2016 om 3:37 AM schreef Reuben Farrelly: >>> In other words, the rules did eventually get propagated across, and >>> based on the file sizes they are complete. >>> >>> But there is obviously something amiss with handling of dates (which >>> in turn may relate to how the system determines that the file on each >>> server is up to date or not, I guess). In this case the two systems >>> are in different timezones - the primary is GMT+10 and the secondary >>> GMT+8. >>> >>> Also the status of active users is not always replicated either. On >>> one host the output of 'doveadm sieve list -A' shows my own account as >>> ACTIVE but the other host shows all users - except for my account - as >>> being active, and the sieve script for my account is not being >>> replicated. >> This should fix the file timestamps getting set at unix time_t 0: >> >> https://github.com/dovecot/pigeonhole/commit/af91dd3f2d78da752292dce27f9e76d2c936868c >> >> >> I haven't been able to replicate the situation where this occurs though, >> since my current replication setup is very simple. >> >> I need to extend my replication setup to test this more thoroughly. >> >> So, please test this at your end first. >> >> Regards, >> >> Stephan. > > Thanks Stephan. I have re-tested and the dates are now all look to be > correct on the replicated scripts. We can cross that off as fixed now. > > There is still a problem with the scripts not being replicated though > between replicated hosts. They do eventually catch up many hours > later. I don't know what the trigger is for them updating but it's > not triggered by delivery attempts (as every time a delivery was > attempted the secondary complained about the missing sieve script). > > Thanks, > Reuben