[jira] [Commented] (SLING-7714) SCD FileVault packages created with root filter which removes ACEs

2018-06-14 Thread Timothee Maret (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512109#comment-16512109
 ] 

Timothee Maret commented on SLING-7714:
---

Thanks [~mpetria]!

> SCD FileVault packages created with root filter which removes ACEs
> --
>
> Key: SLING-7714
> URL: https://issues.apache.org/jira/browse/SLING-7714
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Ankit Aggarwal
>Assignee: Timothee Maret
>Priority: Major
> Fix For: Content Distribution Core 0.3.0
>
> Attachments: CQ-4245994.patch, CQ-4245994_2.patch, 
> CQ-4245994_3.patch, faulty-pkg-4503-1.0.zip, pkg-4503-additionnal.zip, 
> pkg-4503-base.zip, pre-SP2-1.0.zip
>
>
> After upgrading the customer stage instances, it has been observed that the 
> user synchronization is broken.
> After investigation, I observed that not only the user sync is broken but 
> possible the whole instance, as many "rep:policy" nodes have been removed.
>  
> h4. Steps to reproduce
>  # start a 3 instances (1 author, 2 publishers) setup on AEM 6.3
>  # enable the user synchronization following the documentation
>  # upgrade publishers to SP2, then author
>  # create a new user on pub1
>  
> Expected result:
> User is propagated/synchronized on pub2 without side-effect
>  
> Actual result:
> User is propagated/synchronized on pub2, but the following rep:policy nodes 
> are removed (maybe non exhaustive list):
>  * /rep:policy
>  * /home/rep:policy
>  * /home/users/rep:policy
>  
> I reproduce this issue and tested again the procedure, but I disabled the 
> sync agent on Author, so that I could retrieve the package being replicated 
> on the other publisher (pub2) to inspect its definition.
>  
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  is a raw package containing the "/var/sling/distribution" and 
> "/var/eventing/jobs/unassigned" of pub1 where I created the new user post-SP2 
> install, if you require more details.
>  
> [pkg-4503-base.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594549/2594549_pkg-4503-base.zip]
>  and 
> [pkg-4503-additionnal.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594550/2594550_pkg-4503-additionnal.zip]
>  are the actual packages that will be distributed by SCD, and installed on 
> pub2. I extracted them from 
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  from the following path 
> "faulty-pkg-4503-1.0.zip\jcr_root\var\sling\distribution\packages\socialpubsync-vlt\data\dstrpck-1528203802286-58c3aa28-a83a-4a74-a781-e48e5415a541\"
>  and "dstrpck-1528203802288-c6416288-9b4d-43cc-8967-c09215bd6a91" (they are 
> the "bin" file renamed).
>  
> Checking their _META-INF\vault\filter.xml,_ I think that the filter 
> definition is incorrect:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
>   
> {code}
>  
> *The last entry with filter on "/" looks suspicious.*
>  
> On a pre-SP2 instance, I have the following which is correct:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
> {code}
>  
> I assume that the ACL are merged and as the filter is pointing to "/" and the 
> package doesn't have any rep:policy for any nodes in the hierarchy, it is 
> removing the existing ones.
>  
> PS: I have some instances setup to share if needed.
> *Btw now that the issue is qualified I guess you only need to setup one 
> single publisher, enable usersync, and create a new user. This should trigger 
> the package creation containing the invalid filter definition.*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (SLING-7714) SCD FileVault packages created with root filter which removes ACEs

2018-06-13 Thread Marius Petria (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511370#comment-16511370
 ] 

Marius Petria commented on SLING-7714:
--

I applied the first patch to SCD and filled JCRVLT-305 to track the filter.xml 
problem.

> SCD FileVault packages created with root filter which removes ACEs
> --
>
> Key: SLING-7714
> URL: https://issues.apache.org/jira/browse/SLING-7714
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Ankit Aggarwal
>Assignee: Timothee Maret
>Priority: Major
> Attachments: CQ-4245994.patch, CQ-4245994_2.patch, 
> CQ-4245994_3.patch, faulty-pkg-4503-1.0.zip, pkg-4503-additionnal.zip, 
> pkg-4503-base.zip, pre-SP2-1.0.zip
>
>
> After upgrading the customer stage instances, it has been observed that the 
> user synchronization is broken.
> After investigation, I observed that not only the user sync is broken but 
> possible the whole instance, as many "rep:policy" nodes have been removed.
>  
> h4. Steps to reproduce
>  # start a 3 instances (1 author, 2 publishers) setup on AEM 6.3
>  # enable the user synchronization following the documentation
>  # upgrade publishers to SP2, then author
>  # create a new user on pub1
>  
> Expected result:
> User is propagated/synchronized on pub2 without side-effect
>  
> Actual result:
> User is propagated/synchronized on pub2, but the following rep:policy nodes 
> are removed (maybe non exhaustive list):
>  * /rep:policy
>  * /home/rep:policy
>  * /home/users/rep:policy
>  
> I reproduce this issue and tested again the procedure, but I disabled the 
> sync agent on Author, so that I could retrieve the package being replicated 
> on the other publisher (pub2) to inspect its definition.
>  
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  is a raw package containing the "/var/sling/distribution" and 
> "/var/eventing/jobs/unassigned" of pub1 where I created the new user post-SP2 
> install, if you require more details.
>  
> [pkg-4503-base.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594549/2594549_pkg-4503-base.zip]
>  and 
> [pkg-4503-additionnal.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594550/2594550_pkg-4503-additionnal.zip]
>  are the actual packages that will be distributed by SCD, and installed on 
> pub2. I extracted them from 
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  from the following path 
> "faulty-pkg-4503-1.0.zip\jcr_root\var\sling\distribution\packages\socialpubsync-vlt\data\dstrpck-1528203802286-58c3aa28-a83a-4a74-a781-e48e5415a541\"
>  and "dstrpck-1528203802288-c6416288-9b4d-43cc-8967-c09215bd6a91" (they are 
> the "bin" file renamed).
>  
> Checking their _META-INF\vault\filter.xml,_ I think that the filter 
> definition is incorrect:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
>   
> {code}
>  
> *The last entry with filter on "/" looks suspicious.*
>  
> On a pre-SP2 instance, I have the following which is correct:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
> {code}
>  
> I assume that the ACL are merged and as the filter is pointing to "/" and the 
> package doesn't have any rep:policy for any nodes in the hierarchy, it is 
> removing the existing ones.
>  
> PS: I have some instances setup to share if needed.
> *Btw now that the issue is qualified I guess you only need to setup one 
> single publisher, enable usersync, and create a new user. This should trigger 
> the package creation containing the invalid filter definition.*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (SLING-7714) SCD FileVault packages created with root filter which removes ACEs

2018-06-13 Thread Timothee Maret (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511275#comment-16511275
 ] 

Timothee Maret commented on SLING-7714:
---

In SCD, we currently allow to build any combinations of deep/shallow packages 
with/without property filter. FileVault can support those combinations, I have 
built test cases for FileVault to cover each combination, see 
https://issues.apache.org/jira/browse/JCRVLT-304.

> SCD FileVault packages created with root filter which removes ACEs
> --
>
> Key: SLING-7714
> URL: https://issues.apache.org/jira/browse/SLING-7714
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Ankit Aggarwal
>Assignee: Timothee Maret
>Priority: Major
> Attachments: CQ-4245994.patch, CQ-4245994_2.patch, 
> CQ-4245994_3.patch, faulty-pkg-4503-1.0.zip, pkg-4503-additionnal.zip, 
> pkg-4503-base.zip, pre-SP2-1.0.zip
>
>
> After upgrading the customer stage instances, it has been observed that the 
> user synchronization is broken.
> After investigation, I observed that not only the user sync is broken but 
> possible the whole instance, as many "rep:policy" nodes have been removed.
>  
> h4. Steps to reproduce
>  # start a 3 instances (1 author, 2 publishers) setup on AEM 6.3
>  # enable the user synchronization following the documentation
>  # upgrade publishers to SP2, then author
>  # create a new user on pub1
>  
> Expected result:
> User is propagated/synchronized on pub2 without side-effect
>  
> Actual result:
> User is propagated/synchronized on pub2, but the following rep:policy nodes 
> are removed (maybe non exhaustive list):
>  * /rep:policy
>  * /home/rep:policy
>  * /home/users/rep:policy
>  
> I reproduce this issue and tested again the procedure, but I disabled the 
> sync agent on Author, so that I could retrieve the package being replicated 
> on the other publisher (pub2) to inspect its definition.
>  
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  is a raw package containing the "/var/sling/distribution" and 
> "/var/eventing/jobs/unassigned" of pub1 where I created the new user post-SP2 
> install, if you require more details.
>  
> [pkg-4503-base.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594549/2594549_pkg-4503-base.zip]
>  and 
> [pkg-4503-additionnal.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594550/2594550_pkg-4503-additionnal.zip]
>  are the actual packages that will be distributed by SCD, and installed on 
> pub2. I extracted them from 
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  from the following path 
> "faulty-pkg-4503-1.0.zip\jcr_root\var\sling\distribution\packages\socialpubsync-vlt\data\dstrpck-1528203802286-58c3aa28-a83a-4a74-a781-e48e5415a541\"
>  and "dstrpck-1528203802288-c6416288-9b4d-43cc-8967-c09215bd6a91" (they are 
> the "bin" file renamed).
>  
> Checking their _META-INF\vault\filter.xml,_ I think that the filter 
> definition is incorrect:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
>   
> {code}
>  
> *The last entry with filter on "/" looks suspicious.*
>  
> On a pre-SP2 instance, I have the following which is correct:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
> {code}
>  
> I assume that the ACL are merged and as the filter is pointing to "/" and the 
> package doesn't have any rep:policy for any nodes in the hierarchy, it is 
> removing the existing ones.
>  
> PS: I have some instances setup to share if needed.
> *Btw now that the issue is qualified I guess you only need to setup one 
> single publisher, enable usersync, and create a new user. This should trigger 
> the package creation containing the invalid filter definition.*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (SLING-7714) SCD FileVault packages created with root filter which removes ACEs

2018-06-13 Thread Ankit Aggarwal (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16511074#comment-16511074
 ] 

Ankit Aggarwal commented on SLING-7714:
---

[~mpetria], [~marett]

I had shared the buddy build from [^CQ-4245994_3.patch] and it is working fine 
on their test environment as of now.

> SCD FileVault packages created with root filter which removes ACEs
> --
>
> Key: SLING-7714
> URL: https://issues.apache.org/jira/browse/SLING-7714
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Ankit Aggarwal
>Assignee: Timothee Maret
>Priority: Major
> Attachments: CQ-4245994.patch, CQ-4245994_2.patch, 
> CQ-4245994_3.patch, faulty-pkg-4503-1.0.zip, pkg-4503-additionnal.zip, 
> pkg-4503-base.zip, pre-SP2-1.0.zip
>
>
> After upgrading the customer stage instances (this is ManagedService), it has 
> been observed that the user synchronization si broken.
> After investigation, I observed that not only the user sync is broken but 
> possible the whole instance, as many "rep:policy" nodes have been removed.
>  
> h4. Steps to reproduce
>  # start a 3 instances (1 author, 2 publishers) setup on AEM 6.3
>  # enable the user synchronization following the documentation
>  # upgrade publishers to SP2, then author
>  # create a new user on pub1
>  
> Expected result:
> User is propagated/synchronized on pub2 without side-effect
>  
> Actual result:
> User is propagated/synchronized on pub2, but the following rep:policy nodes 
> are removed (maybe non exhaustive list):
>  * /rep:policy
>  * /home/rep:policy
>  * /home/users/rep:policy
>  
> I reproduce this issue and tested again the procedure, but I disabled the 
> sync agent on Author, so that I could retrieve the package being replicated 
> on the other publisher (pub2) to inspect its definition.
>  
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  is a raw package containing the "/var/sling/distribution" and 
> "/var/eventing/jobs/unassigned" of pub1 where I created the new user post-SP2 
> install, if you require more details.
>  
> [pkg-4503-base.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594549/2594549_pkg-4503-base.zip]
>  and 
> [pkg-4503-additionnal.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594550/2594550_pkg-4503-additionnal.zip]
>  are the actual packages that will be distributed by SCD, and installed on 
> pub2. I extracted them from 
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  from the following path 
> "faulty-pkg-4503-1.0.zip\jcr_root\var\sling\distribution\packages\socialpubsync-vlt\data\dstrpck-1528203802286-58c3aa28-a83a-4a74-a781-e48e5415a541\"
>  and "dstrpck-1528203802288-c6416288-9b4d-43cc-8967-c09215bd6a91" (they are 
> the "bin" file renamed).
>  
> Checking their _META-INF\vault\filter.xml,_ I think that the filter 
> definition is incorrect:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
>   
> {code}
>  
> *The last entry with filter on "/" looks suspicious.*
>  
> On a pre-SP2 instance, I have the following which is correct:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
> {code}
>  
> I assume that the ACL are merged and as the filter is pointing to "/" and the 
> package doesn't have any rep:policy for any nodes in the hierarchy, it is 
> removing the existing ones.
>  
> PS: I have some instances setup to share if needed.
> *Btw now that the issue is qualified I guess you only need to setup one 
> single publisher, enable usersync, and create a new user. This should trigger 
> the package creation containing the invalid filter definition.*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (SLING-7714) SCD FileVault packages created with root filter which removes ACEs

2018-06-13 Thread Ankit Aggarwal (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510711#comment-16510711
 ] 

Ankit Aggarwal commented on SLING-7714:
---

[~marett]

Initially the nodeFilterSet was used to create filter.xml but now 
propertiesFilterSet is used to create the same.

{{DefaultWorkspaceFilter#add(PathFilterSet, PathFilterSet)}} does not keep the 
last filter entry but while generating the filter it iterates over 
propertiesFilterSet  [2] . Here [0] we are creating a PropertyFilter at root 
path "/" which is causing this problem. 
I have set the root path to the node path.


Is there any specific reason of setting propertyFilterSet root to "/" here [1]. 
I think this should have been set to same path as that of the node filter.

 

[0] 
[https://github.com/apache/sling-org-apache-sling-distribution-core/blob/16a4ed809aaf935c29c2b19237e5c54c5d0c9384/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VltUtils.java#L97]

[1] 
[https://github.com/apache/sling-org-apache-sling-distribution-core/blob/16a4ed809aaf935c29c2b19237e5c54c5d0c9384/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VltUtils.java#L97]

[2] 
[https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/config/DefaultWorkspaceFilter.java#L429]
 

> SCD FileVault packages created with root filter which removes ACEs
> --
>
> Key: SLING-7714
> URL: https://issues.apache.org/jira/browse/SLING-7714
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Ankit Aggarwal
>Assignee: Timothee Maret
>Priority: Major
> Attachments: CQ-4245994.patch, CQ-4245994_2.patch, 
> CQ-4245994_3.patch, faulty-pkg-4503-1.0.zip, pkg-4503-additionnal.zip, 
> pkg-4503-base.zip, pre-SP2-1.0.zip
>
>
> After upgrading the customer stage instances (this is ManagedService), it has 
> been observed that the user synchronization si broken.
> After investigation, I observed that not only the user sync is broken but 
> possible the whole instance, as many "rep:policy" nodes have been removed.
>  
> h4. Steps to reproduce
>  # start a 3 instances (1 author, 2 publishers) setup on AEM 6.3
>  # enable the user synchronization following the documentation
>  # upgrade publishers to SP2, then author
>  # create a new user on pub1
>  
> Expected result:
> User is propagated/synchronized on pub2 without side-effect
>  
> Actual result:
> User is propagated/synchronized on pub2, but the following rep:policy nodes 
> are removed (maybe non exhaustive list):
>  * /rep:policy
>  * /home/rep:policy
>  * /home/users/rep:policy
>  
> I reproduce this issue and tested again the procedure, but I disabled the 
> sync agent on Author, so that I could retrieve the package being replicated 
> on the other publisher (pub2) to inspect its definition.
>  
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  is a raw package containing the "/var/sling/distribution" and 
> "/var/eventing/jobs/unassigned" of pub1 where I created the new user post-SP2 
> install, if you require more details.
>  
> [pkg-4503-base.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594549/2594549_pkg-4503-base.zip]
>  and 
> [pkg-4503-additionnal.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594550/2594550_pkg-4503-additionnal.zip]
>  are the actual packages that will be distributed by SCD, and installed on 
> pub2. I extracted them from 
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  from the following path 
> "faulty-pkg-4503-1.0.zip\jcr_root\var\sling\distribution\packages\socialpubsync-vlt\data\dstrpck-1528203802286-58c3aa28-a83a-4a74-a781-e48e5415a541\"
>  and "dstrpck-1528203802288-c6416288-9b4d-43cc-8967-c09215bd6a91" (they are 
> the "bin" file renamed).
>  
> Checking their _META-INF\vault\filter.xml,_ I think that the filter 
> definition is incorrect:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
>   
> {code}
>  
> *The last entry with filter on "/" looks suspicious.*
>  
> On a pre-SP2 instance, I have the following which is correct:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
> {code}
>  
> I assume that the ACL are merged and as the filter is pointing to "/" and the 
> package doesn't have any rep:policy for any nodes in the hierarchy, it is 
> removing the 

[jira] [Commented] (SLING-7714) SCD FileVault packages created with root filter which removes ACEs

2018-06-13 Thread Ankit Aggarwal (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510708#comment-16510708
 ] 

Ankit Aggarwal commented on SLING-7714:
---

[~mpetria]

In [^CQ-4245994_3.patch], I have provided the default value to the property 
filters in addition to the fix in [^CQ-4245994.patch]

> SCD FileVault packages created with root filter which removes ACEs
> --
>
> Key: SLING-7714
> URL: https://issues.apache.org/jira/browse/SLING-7714
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Ankit Aggarwal
>Assignee: Timothee Maret
>Priority: Major
> Attachments: CQ-4245994.patch, CQ-4245994_2.patch, 
> CQ-4245994_3.patch, faulty-pkg-4503-1.0.zip, pkg-4503-additionnal.zip, 
> pkg-4503-base.zip, pre-SP2-1.0.zip
>
>
> After upgrading the customer stage instances (this is ManagedService), it has 
> been observed that the user synchronization si broken.
> After investigation, I observed that not only the user sync is broken but 
> possible the whole instance, as many "rep:policy" nodes have been removed.
>  
> h4. Steps to reproduce
>  # start a 3 instances (1 author, 2 publishers) setup on AEM 6.3
>  # enable the user synchronization following the documentation
>  # upgrade publishers to SP2, then author
>  # create a new user on pub1
>  
> Expected result:
> User is propagated/synchronized on pub2 without side-effect
>  
> Actual result:
> User is propagated/synchronized on pub2, but the following rep:policy nodes 
> are removed (maybe non exhaustive list):
>  * /rep:policy
>  * /home/rep:policy
>  * /home/users/rep:policy
>  
> I reproduce this issue and tested again the procedure, but I disabled the 
> sync agent on Author, so that I could retrieve the package being replicated 
> on the other publisher (pub2) to inspect its definition.
>  
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  is a raw package containing the "/var/sling/distribution" and 
> "/var/eventing/jobs/unassigned" of pub1 where I created the new user post-SP2 
> install, if you require more details.
>  
> [pkg-4503-base.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594549/2594549_pkg-4503-base.zip]
>  and 
> [pkg-4503-additionnal.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594550/2594550_pkg-4503-additionnal.zip]
>  are the actual packages that will be distributed by SCD, and installed on 
> pub2. I extracted them from 
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  from the following path 
> "faulty-pkg-4503-1.0.zip\jcr_root\var\sling\distribution\packages\socialpubsync-vlt\data\dstrpck-1528203802286-58c3aa28-a83a-4a74-a781-e48e5415a541\"
>  and "dstrpck-1528203802288-c6416288-9b4d-43cc-8967-c09215bd6a91" (they are 
> the "bin" file renamed).
>  
> Checking their _META-INF\vault\filter.xml,_ I think that the filter 
> definition is incorrect:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
>   
> {code}
>  
> *The last entry with filter on "/" looks suspicious.*
>  
> On a pre-SP2 instance, I have the following which is correct:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
> {code}
>  
> I assume that the ACL are merged and as the filter is pointing to "/" and the 
> package doesn't have any rep:policy for any nodes in the hierarchy, it is 
> removing the existing ones.
>  
> PS: I have some instances setup to share if needed.
> *Btw now that the issue is qualified I guess you only need to setup one 
> single publisher, enable usersync, and create a new user. This should trigger 
> the package creation containing the invalid filter definition.*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (SLING-7714) SCD FileVault packages created with root filter which removes ACEs

2018-06-13 Thread Marius Petria (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510700#comment-16510700
 ] 

Marius Petria commented on SLING-7714:
--

[~marett] I think we have 2 things to solve:
1. make it work without property filters (these were added recently and they 
are not used a lot)
2. make it work with property filters
I am trying to split this in two because maybe we can solve 1 without fixing 
filevault. I think for that 
[CQ-4245994.patch|https://issues.apache.org/jira/secure/attachment/12926890/CQ-4245994.patch]
 looks to be the best. Even if the resulting filter.xml looks like a "deep 
filter" (with not include pattern) only the distributed node is packaged.

> SCD FileVault packages created with root filter which removes ACEs
> --
>
> Key: SLING-7714
> URL: https://issues.apache.org/jira/browse/SLING-7714
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Ankit Aggarwal
>Assignee: Timothee Maret
>Priority: Major
> Attachments: CQ-4245994.patch, CQ-4245994_2.patch, 
> CQ-4245994_3.patch, faulty-pkg-4503-1.0.zip, pkg-4503-additionnal.zip, 
> pkg-4503-base.zip, pre-SP2-1.0.zip
>
>
> After upgrading the customer stage instances (this is ManagedService), it has 
> been observed that the user synchronization si broken.
> After investigation, I observed that not only the user sync is broken but 
> possible the whole instance, as many "rep:policy" nodes have been removed.
>  
> h4. Steps to reproduce
>  # start a 3 instances (1 author, 2 publishers) setup on AEM 6.3
>  # enable the user synchronization following the documentation
>  # upgrade publishers to SP2, then author
>  # create a new user on pub1
>  
> Expected result:
> User is propagated/synchronized on pub2 without side-effect
>  
> Actual result:
> User is propagated/synchronized on pub2, but the following rep:policy nodes 
> are removed (maybe non exhaustive list):
>  * /rep:policy
>  * /home/rep:policy
>  * /home/users/rep:policy
>  
> I reproduce this issue and tested again the procedure, but I disabled the 
> sync agent on Author, so that I could retrieve the package being replicated 
> on the other publisher (pub2) to inspect its definition.
>  
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  is a raw package containing the "/var/sling/distribution" and 
> "/var/eventing/jobs/unassigned" of pub1 where I created the new user post-SP2 
> install, if you require more details.
>  
> [pkg-4503-base.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594549/2594549_pkg-4503-base.zip]
>  and 
> [pkg-4503-additionnal.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594550/2594550_pkg-4503-additionnal.zip]
>  are the actual packages that will be distributed by SCD, and installed on 
> pub2. I extracted them from 
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  from the following path 
> "faulty-pkg-4503-1.0.zip\jcr_root\var\sling\distribution\packages\socialpubsync-vlt\data\dstrpck-1528203802286-58c3aa28-a83a-4a74-a781-e48e5415a541\"
>  and "dstrpck-1528203802288-c6416288-9b4d-43cc-8967-c09215bd6a91" (they are 
> the "bin" file renamed).
>  
> Checking their _META-INF\vault\filter.xml,_ I think that the filter 
> definition is incorrect:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
>   
> {code}
>  
> *The last entry with filter on "/" looks suspicious.*
>  
> On a pre-SP2 instance, I have the following which is correct:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
> {code}
>  
> I assume that the ACL are merged and as the filter is pointing to "/" and the 
> package doesn't have any rep:policy for any nodes in the hierarchy, it is 
> removing the existing ones.
>  
> PS: I have some instances setup to share if needed.
> *Btw now that the issue is qualified I guess you only need to setup one 
> single publisher, enable usersync, and create a new user. This should trigger 
> the package creation containing the invalid filter definition.*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (SLING-7714) SCD FileVault packages created with root filter which removes ACEs

2018-06-12 Thread Timothee Maret (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509718#comment-16509718
 ] 

Timothee Maret commented on SLING-7714:
---

In JCRVLT-197, FileVault deprecated the ability to define multiple filter 
roots, we reuse the path as root.
The signature {{DefaultWorkspaceFilter#addPropertyFilterSet}} has been 
deprecated in favor of {{DefaultWorkspaceFilter#add(PathFilterSet, 
PathFilterSet)}}.


https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/config/DefaultWorkspaceFilter.java#L121

In SLING-7238, the SCD code has been adapted to use the new signature


https://github.com/apache/sling-org-apache-sling-distribution-core/commit/16a4ed809aaf935c29c2b19237e5c54c5d0c9384

The new signature {{DefaultWorkspaceFilter#add(PathFilterSet, PathFilterSet)}} 
is not semantically equivalent to the previous combination of 
{{DefaultWorkspaceFilter#add}} and 
{{DefaultWorkspaceFilter#addPropertyFilterSet}}. The new signature produces a 
single workspace filter entry instead of the two. It turns out it keeps the 
last filter entry which is the one with the root path.

> SCD FileVault packages created with root filter which removes ACEs
> --
>
> Key: SLING-7714
> URL: https://issues.apache.org/jira/browse/SLING-7714
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Ankit Aggarwal
>Assignee: Timothee Maret
>Priority: Major
> Attachments: CQ-4245994.patch, CQ-4245994_2.patch, 
> CQ-4245994_3.patch, faulty-pkg-4503-1.0.zip, pkg-4503-additionnal.zip, 
> pkg-4503-base.zip, pre-SP2-1.0.zip
>
>
> After upgrading the customer stage instances (this is ManagedService), it has 
> been observed that the user synchronization si broken.
> After investigation, I observed that not only the user sync is broken but 
> possible the whole instance, as many "rep:policy" nodes have been removed.
>  
> h4. Steps to reproduce
>  # start a 3 instances (1 author, 2 publishers) setup on AEM 6.3
>  # enable the user synchronization following the documentation
>  # upgrade publishers to SP2, then author
>  # create a new user on pub1
>  
> Expected result:
> User is propagated/synchronized on pub2 without side-effect
>  
> Actual result:
> User is propagated/synchronized on pub2, but the following rep:policy nodes 
> are removed (maybe non exhaustive list):
>  * /rep:policy
>  * /home/rep:policy
>  * /home/users/rep:policy
>  
> I reproduce this issue and tested again the procedure, but I disabled the 
> sync agent on Author, so that I could retrieve the package being replicated 
> on the other publisher (pub2) to inspect its definition.
>  
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  is a raw package containing the "/var/sling/distribution" and 
> "/var/eventing/jobs/unassigned" of pub1 where I created the new user post-SP2 
> install, if you require more details.
>  
> [pkg-4503-base.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594549/2594549_pkg-4503-base.zip]
>  and 
> [pkg-4503-additionnal.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594550/2594550_pkg-4503-additionnal.zip]
>  are the actual packages that will be distributed by SCD, and installed on 
> pub2. I extracted them from 
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  from the following path 
> "faulty-pkg-4503-1.0.zip\jcr_root\var\sling\distribution\packages\socialpubsync-vlt\data\dstrpck-1528203802286-58c3aa28-a83a-4a74-a781-e48e5415a541\"
>  and "dstrpck-1528203802288-c6416288-9b4d-43cc-8967-c09215bd6a91" (they are 
> the "bin" file renamed).
>  
> Checking their _META-INF\vault\filter.xml,_ I think that the filter 
> definition is incorrect:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
>   
> {code}
>  
> *The last entry with filter on "/" looks suspicious.*
>  
> On a pre-SP2 instance, I have the following which is correct:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
> {code}
>  
> I assume that the ACL are merged and as the filter is pointing to "/" and the 
> package doesn't have any rep:policy for any nodes in the hierarchy, it is 
> removing the existing ones.
>  
> PS: I have some instances setup to share if needed.
> *Btw now that the issue is qualified I guess you only need to setup one 
> single 

[jira] [Commented] (SLING-7714) SCD FileVault packages created with root filter which removes ACEs

2018-06-11 Thread Timothee Maret (JIRA)


[ 
https://issues.apache.org/jira/browse/SLING-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508061#comment-16508061
 ] 

Timothee Maret commented on SLING-7714:
---

This issue relates to JCRVLT-278, JCRVLT-227. The root cause of this issue, is 
a property filter set to the root path independently of a property filter being 
configured or not. The workaround for this issue, is to set the 
{{MERGE_PRESERVE}} ACL handling in the 
{{o.a.s.d.s.i.v.VaultDistributionPackageBuilderFactory}} configuration. I'll 
review the fix.

> SCD FileVault packages created with root filter which removes ACEs
> --
>
> Key: SLING-7714
> URL: https://issues.apache.org/jira/browse/SLING-7714
> Project: Sling
>  Issue Type: Bug
>  Components: Content Distribution
>Affects Versions: Content Distribution Core 0.2.10
>Reporter: Ankit Aggarwal
>Assignee: Timothee Maret
>Priority: Major
> Attachments: CQ-4245994.patch, CQ-4245994_2.patch, 
> CQ-4245994_3.patch, faulty-pkg-4503-1.0.zip, pkg-4503-additionnal.zip, 
> pkg-4503-base.zip, pre-SP2-1.0.zip
>
>
> After upgrading the customer stage instances (this is ManagedService), it has 
> been observed that the user synchronization si broken.
> After investigation, I observed that not only the user sync is broken but 
> possible the whole instance, as many "rep:policy" nodes have been removed.
>  
> h4. Steps to reproduce
>  # start a 3 instances (1 author, 2 publishers) setup on AEM 6.3
>  # enable the user synchronization following the documentation
>  # upgrade publishers to SP2, then author
>  # create a new user on pub1
>  
> Expected result:
> User is propagated/synchronized on pub2 without side-effect
>  
> Actual result:
> User is propagated/synchronized on pub2, but the following rep:policy nodes 
> are removed (maybe non exhaustive list):
>  * /rep:policy
>  * /home/rep:policy
>  * /home/users/rep:policy
>  
> I reproduce this issue and tested again the procedure, but I disabled the 
> sync agent on Author, so that I could retrieve the package being replicated 
> on the other publisher (pub2) to inspect its definition.
>  
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  is a raw package containing the "/var/sling/distribution" and 
> "/var/eventing/jobs/unassigned" of pub1 where I created the new user post-SP2 
> install, if you require more details.
>  
> [pkg-4503-base.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594549/2594549_pkg-4503-base.zip]
>  and 
> [pkg-4503-additionnal.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594550/2594550_pkg-4503-additionnal.zip]
>  are the actual packages that will be distributed by SCD, and installed on 
> pub2. I extracted them from 
> [faulty-pkg-4503-1.0.zip^!/images/icons/link_attachment_7.gif|width=7,height=7,align=absmiddle!^|https://issues.apache.org/secure/attachment/2594552/2594552_faulty-pkg-4503-1.0.zip]
>  from the following path 
> "faulty-pkg-4503-1.0.zip\jcr_root\var\sling\distribution\packages\socialpubsync-vlt\data\dstrpck-1528203802286-58c3aa28-a83a-4a74-a781-e48e5415a541\"
>  and "dstrpck-1528203802288-c6416288-9b4d-43cc-8967-c09215bd6a91" (they are 
> the "bin" file renamed).
>  
> Checking their _META-INF\vault\filter.xml,_ I think that the filter 
> definition is incorrect:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
>   
> {code}
>  
> *The last entry with filter on "/" looks suspicious.*
>  
> On a pre-SP2 instance, I have the following which is correct:
> {code:java}
> 
>   
> 
>   
>   
> 
>   
> {code}
>  
> I assume that the ACL are merged and as the filter is pointing to "/" and the 
> package doesn't have any rep:policy for any nodes in the hierarchy, it is 
> removing the existing ones.
>  
> PS: I have some instances setup to share if needed.
> *Btw now that the issue is qualified I guess you only need to setup one 
> single publisher, enable usersync, and create a new user. This should trigger 
> the package creation containing the invalid filter definition.*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)