Re: Folder subscription issue

[Bron Gondwana]

Sorry for not getting back to you yesterday. I was on my way back from vacation 
and had family commitments all last night.

Regarding contribution - the very best thing to do for a case like this is to 
build Cassandane tests which isolate the issue :) I'll see if I can get that 
done today.

Cheers,

Bron.

On Tue, Jul 16, 2019, at 02:34, Egoitz Aurrekoetxea wrote:
> Hi Bron!
> 
> Sorry for answering so late I had the thought I answered you before…. I’m 
> slightly stressed these days...
> 
> I answer below in green bold for instance…..
> 
> 
> sarenet
> *Egoitz Aurrekoetxea*
> Dpto. de sistemas
> 944 209 470
> Parque Tecnológico. Edificio 103
> 48170 Zamudio (Bizkaia)
> ego...@sarenet.es
> www.sarenet.es
> 
> Antes de imprimir este correo electrónico piense si es necesario hacerlo.
> 
>> El 14 jul 2019, a las 14:36, Bron Gondwana  escribió:
>> 
>> On Wed, Jul 10, 2019, at 19:11, Egoitz Aurrekoetxea wrote:
>>> Good morning,
>>> 
>>> In previous thread (with the title slightly incorrect) I talk about an 
>>> issue suffered some day with Sieve script and folder subscriptions. The 
>>> Sieve part, was related to the migration, so for the moment let’s forget 
>>> about it (for me at least) as it has never reproduced again since then.
>> 
>> Sorry, I missed the previous thread. Did you mention which version of Cyrus 
>> you are running? There's clearly a bug and it would be good to know which 
>> version(s) it affects.
> 
> 
> *I think I have specified all these details (including what the previous 
> thread was saying) in the answered mail this morning… I think it's all there… 
> the version was 3.0.8…. If is not all or you need something, please tell me 
> and I’ll try my bests for providing you all the info you need..*
> 
> 
>> 
>>> About the folder subscription issue, I think I got something, at least a 
>>> close approximation... When a user causes in mua a rename mailbox (a rename 
>>> for a folder caused by a folder move in hierarchy), after the own rename, 
>>> if folders were subscribed “should” (for the "plain user" at least) become 
>>> subscribed in the new path. It seems that after a user rename in Cyrus the 
>>> new folder is automatically subscribed (even if no subscribe command is 
>>> sent by the mua). But this, does not cause in the replica (in the slave, if 
>>> SUB is not sent by the client) a sync_apply_changesub() or something like 
>>> entering in the “ move_subscription” condition in mboxlist_renamemailbox(), 
>>> and then, the folder is properly renamed but not subscribed in the slave. I 
>>> think this is what I’m suffering. Obviously, if after a rename the mua 
>>> sends a subscribe too, no issue is seen. I think the problem happens when a 
>>> mailbox rename happens and a SUB is not send later.
>> 
>> Subscriptions aren't automatically renamed when a folder is renamed, but 
>> they should be automatically renamed for a user rename. Intermediate 
>> replicated states can be bit messy due to race conditions with replication, 
>> but I believe it should always wind up in the final correct state. If not, 
>> that's a bug for sure!
> 
> *This tests are some days ago… I’m slightly confused now because I don’t 
> remember it exactly… *
> 
>> 
>>> An example : 
>>> 
>>> The folder domain.com!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG 
>>> is moved (renamed) to trash.
>>> 
>>> May 16 16:16:50 mx6c imap[83976]: conversations_rename_folder: renamed 
>>> domain.com!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG to 
>>> domain.com!user.parta^partb.Trash.XINGANG
>>> May 16 16:16:50 mx6c imap[83976]: Rename: 
>>> domain.com!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG -> 
>>> domain.com!user.parta^partb.Trash.XINGANG
>>> May 16 16:16:50 mx6c imap[83976]: Deleted mailbox 
>>> domain.com!user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG
>>> 
>>> In the master (sync), the folder in Trash is subscribed but in the slave it 
>>> is not, and remains subscribed the folder in the original location in the 
>>> “.sub” file.
>> 
>> This might just be a matter of failing to sync_log the subscription in that 
>> codepath. Hmm...
>> 
>> But there is a question of whether we should even be renaming the 
>> subscription - RFC3501 is a little silent on this issue, but it does say in 
>> a couple of places that the server MUST NOT remove a subscription even if 
>> the mailbox with that name doesn't exist, which makes renaming subscriptions 
>> a bit unclear. I'll check in with the authors of draft-ietf-extra-imap4rev2 
>> and ask for this to be clarified next time around!
> 
> 
> *That’s it Bron.. it was strange… anyway… you know, when you try to debug an 
> issue like the commented you do a closer inspection to all this behaviour, 
> you know…. **Although as said before, perhaps it’s better to talk about 
> today's examples… I got them more recent….*
> 
> 
>> 
>>> A diff between the master (replication client) .sub file and the slave’s 
>>> one is (mx5 is the master, the client and 6

Re: Folder subscription issue

[Egoitz Aurrekoetxea]

Hi Bron!

Sorry for answering so late I had the thought I answered you before…. I’m 
slightly stressed these days...

I answer below in green bold for instance…..



Egoitz Aurrekoetxea
Dpto. de sistemas
944 209 470
Parque Tecnológico. Edificio 103
48170 Zamudio (Bizkaia)
ego...@sarenet.es 
www.sarenet.es 
Antes de imprimir este correo electrónico piense si es necesario hacerlo.

> El 14 jul 2019, a las 14:36, Bron Gondwana  escribió:
> 
> On Wed, Jul 10, 2019, at 19:11, Egoitz Aurrekoetxea wrote:
>> Good morning,
>> 
>> In previous thread (with the title slightly incorrect) I talk about an issue 
>> suffered some day with Sieve script and folder subscriptions. The Sieve 
>> part, was related to the migration, so for the moment let’s forget about it 
>> (for me at least) as it has never reproduced again since then.
> 
> Sorry, I missed the previous thread.  Did you mention which version of Cyrus 
> you are running?  There's clearly a bug and it would be good to know which 
> version(s) it affects.


I think I have specified all these details (including what the previous thread 
was saying) in the answered mail this morning… I think it's all there… the 
version was 3.0.8…. If is not all or you need something, please tell me and 
I’ll try my bests for providing you all the info you need..


> 
>> About the folder subscription issue, I think I got something, at least a 
>> close approximation... When a user causes in mua a rename mailbox (a rename 
>> for a folder caused by a folder move in hierarchy), after the own rename, if 
>> folders were subscribed “should” (for the "plain user" at least) become 
>> subscribed in the new path. It seems that after a user rename in Cyrus the 
>> new folder is automatically subscribed (even if no subscribe command is sent 
>> by the mua). But this, does not cause in the replica (in the slave, if SUB 
>> is not sent by the client) a sync_apply_changesub() or something like 
>> entering in the “ move_subscription” condition in mboxlist_renamemailbox(), 
>> and then, the folder is properly renamed but not subscribed in the slave. I 
>> think this is what I’m suffering. Obviously, if after a rename the mua sends 
>> a subscribe too, no issue is seen. I think the problem happens when a 
>> mailbox rename happens and a SUB is not send later.
> 
> Subscriptions aren't automatically renamed when a folder is renamed, but they 
> should be automatically renamed for a user rename.  Intermediate replicated 
> states can be bit messy due to race conditions with replication, but I 
> believe it should always wind up in the final correct state.  If not, that's 
> a bug for sure!

This tests are some days ago… I’m slightly confused now because I don’t 
remember it exactly… 

> 
>> An example : 
>> 
>> The folder domain.com 
>> !user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG is 
>> moved (renamed) to trash.
>> 
>> May 16 16:16:50 mx6c imap[83976]: conversations_rename_folder: renamed 
>> domain.com 
>> !user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG to 
>> domain.com !user.parta^partb.Trash.XINGANG
>> May 16 16:16:50 mx6c imap[83976]: Rename: domain.com 
>> !user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG -> 
>> domain.com !user.parta^partb.Trash.XINGANG
>> May 16 16:16:50 mx6c imap[83976]: Deleted mailbox domain.com 
>> !user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG
>> 
>> In the master (sync), the folder in Trash is subscribed but in the slave it 
>> is not, and remains subscribed the folder in the original location in the 
>> “.sub” file.
> 
> This might just be a matter of failing to sync_log the subscription in that 
> codepath.  Hmm...
> 
> But there is a question of whether we should even be renaming the 
> subscription - RFC3501 is a little silent on this issue, but it does say in a 
> couple of places that the server MUST NOT remove a subscription even if the 
> mailbox with that name doesn't exist, which makes renaming subscriptions a 
> bit unclear.  I'll check in with the authors of draft-ietf-extra-imap4rev2 
> and ask for this to be clarified next time around!


That’s it Bron..  it was strange… anyway… you know, when you try to debug an 
issue like the commented you do a closer inspection to all this behaviour, you 
know…. Although as said before, perhaps it’s better to talk about today's 
examples… I got them more recent….


> 
>> A diff between the master (replication client) .sub file and the slave’s one 
>> is (mx5 is the master, the client and 6 the slave): 
>> 
>> --- subscripciones-mx5c/parta.partb.sub 2019-07-10 08:47:29.0 +0200
>> +++ subscripciones-mx6c/parta.partb.sub 2019-07-10 08:48:08.0 +0200
>> 
>> +domain.com 
>> !user.parta^partb.Archives.2019.TRAFICO.CHINA.XINGANG
>> -domain.com !user.parta^partb.Trash.XINGANG
>> 
>

Re: Folder subscription issue

[Egoitz Aurrekoetxea]

Hi all :) :),First of all, thanks a lot for your time :) .At present moment… I’m slightly confused due to all the tests done, attempts to reproduce the issue and all the Cyrus code read... I’ll tell all the history although I think some parts are not relevant but in an attempt to not omit something useful : We were running Cyrus 2.3.18. We moved then to 2.4 as an intermediate version (it converted databases on the fly and so… and although this caused us to work more at nights due to the high load we preferred to do it this way) , in order to be able to finally replicate to a 3.0.8 version. From 2.3 to 2.4 we used sync_client and sync_server and from 2.4 to 3.0 too (if I remember correctly too) because I think Imap replication was not working between 2.4 and 3.0.8. Finally in 3.0.8, we set up another slave for having a couple in 3.0.8 replicating in rolling mode through imap.The first thing we noticed was that in 3.0.8 (when setting this version as master, giving the service), some accounts had the folders not subscribed and the sieve script didn’t exist (created by each user from Roundcube plugin). As when we were in the intermediate phase between 2.4 and 3.0 (a couple of days) some issues appeared (for instance, in some migrations, while we were using 2.4 for the service and replicating with sync_client in user mode to 3.0.8 some Cyrus database locks happened and so…) we though it was due to that version difference. We finally wrote some scripts for copying manually the Sieve scripts manually. We created too another one for massive folder subscription for those customers telling us they were not seeing the folders. We didn’t worry more then, due to the version difference as commented.If all that happened were that, we would be relaxed, but…. New problems come again (from 3.0.8 to 3.0.8)…. We needed to say, that we setup new slaves by just syncing with sync_client in user mode…. Finally run in rolling replication mode with a last user mode replication… Here they are : - When failing over from a 3.0.8 to another 3.0.8 (master-slave change) we saw again the subscription issue mainly (perhaps the Sieve issue could still be there).- When setting up new slaves (for moving vm from storage for instance, we created a new slave) with sync_client in user mode… we didn’t appreciate the Sieve issue (although it could exist), but yes, the subscriptions one….I started checking what could be happening and I saw some examples as the one described in the mail below. Later, I think I found something more concrete. Please take a look : % ls -altotal 104drwx--  2 cyrus  cyrus    512 Jul 14 03:12 .drwx--  7 cyrus  cyrus    512 Feb 11 14:52 ..-rw---  1 cyrus  cyrus  77072 Jul 15 04:36 a.saizar.conversations-rw---  1 cyrus  cyrus     88 Jul  3 10:00 a.saizar.counters-rw---  1 cyrus  cyrus     36 Mar 15 05:47 a.saizar.sub-rw---  1 cyrus  cyrus     12 Jul 14 03:12 a.saizar.xapianactive-rw---  1 cyrus  cyrus    944 Feb 11 00:41 a^saizar.seen-rw---  1 cyrus  cyrus    203 Feb 11 00:41 a^saizar.sub% pwd/expert/correo/imap/domain/l/x/user/aIt seems, that (at least some) of the mailboxes that had a dot in their name, the subscriptions, sieve (I’m pretty sure too) and seen were created in the slave (sync destination) with the Cyrus mailbox internal name (replacing dots with ^)… instead with just a dot, as it’s seen it works normally. It seems, sync_client in user mode was creating the file with the ^ instead the dot. Then when Cyrus was trying to find the file, with the dots (as it was expected) it didn’t find them. So creates new one and then as that new subs database is empty, it’s the same effect as if subscriptions were “not copied” with sync_client. I think, although it’s a theory that all the meta files (quota, sieve, seen, subs) are created the same way, all of them with ‘^’ when only quota file has to have that name format.So, for summarizing I think I have observed two important issues : 1 - When you replicate from a 3.0.8 master to 3.0.8 slave sometimes subscriptions (at least, I assume to seen and probably Sieve) are not copied properly (are copied with the dot) and then as the file is not present when Cyrus tries to access with the proper name… creates a new database for subscriptions and considers it’s, just empty… no subscriptions…. I’d say the problem affects just to users who have a dot in the username part (without the domain) of the email. Happens in user mode replication.2 - Seen a lot at differences of subscribed folders in a master in a slave (both in 3.0.8 and in rolling replication) I saw some differences in some enumerated accounts of some customers :Jul 12 10:13:26 mx13c imap[53014]: conversations_rename_folder: renamed xxx.com!user.gl-p^expooort.Sent.OFERTAS.AGENTES VENDA.Gabana Logistics to xxx.com!user.gl-p^expooort.Sent.OFERTAS.Gabana LogisticsJul 12 10:13:26 mx13c imap[53014]: Rename: xxx.com!user.gl-p^expooort.Sent.OFERTAS.AGENTES VENDA.Gabana Logistic