Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
Content Distribution Core 0.2.10
-
None
Description
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.
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^^ 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^^ and 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^^ 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:
<workspaceFilter version="1.0"> <filter root="/home/users/6"> <include pattern="/home/users/6"/> </filter> <filter root="/home/users/6/68dhk9JC3OnZO5Z87rLR"> <include pattern="/home/users/6/68dhk9JC3OnZO5Z87rLR"/> </filter> <filter root="/"/> </workspaceFilter>
The last entry with filter on "/" looks suspicious.
On a pre-SP2 instance, I have the following which is correct:
<workspaceFilter version="1.0"> <filter root="/home/users/L"> <include pattern="/home/users/L"/> </filter> <filter root="/home/users/L/L3q-3NdVN-uV1eawzefF"> <include pattern="/home/users/L/L3q-3NdVN-uV1eawzefF"/> </filter> </workspaceFilter>
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.
Attachments
Attachments
Issue Links
- is blocked by
-
JCRVLT-305 DefaultWorkspaceFilter.add(nodeFilters) does not include properties
- Closed
- is related to
-
JCRVLT-304 Add tests that cover combinations of node and property filters
- Closed
- relates to
-
JCRVLT-227 Import fail if user does not have access to the root path
- Closed
-
JCRVLT-278 Root path ACEs removed due to JCRVLT-227
- Closed