Repoinit Script for creating system user with jcr:all giving runtime deployment error

[NageshRaja]

Hi All,

I am new to repoinit so trying to create a system user with below path access - 
/content/dam/myapp/folderA

/content/myApp/en/services/folderA

I want to have jcr:all access for both these paths to keep it as simple as possible.

Here's my script - 

"create service user Test with path system/myApp",
"ensure nodes (sling:Folder) /conf",
"ensure nodes (sling:Folder) /content/dam/myApp/folderA",
"ensure nodes (sling:Folder) /content/myApp/en/services/folderA",
"set ACL for Test\n allow jcr:read on /conf\n allow jcr:all on /content/dam/myApp/folderA\n allow jcr:all on /content/myApp/en/services/folderA\nend"
]

I also have defined as cq:Page in .content.xml for ui.content module for pages - myApp, en, services, folderA
However, the cloud manager stops deployment at stage installing mutable content.

1. If I don't use ensure nodes then the deployment fails at runtime with error javax.jcr.RepositoryException: Failed to set ACL (javax.jcr.PathNotFoundException: Cannot set ACL on non-existent path)

This is understandable as the repoinit runs before ui.content module might be deployed.

2. If I use sling:Folder as ensure nodes for /content based cq:Page paths then also the deployment fails

Ideally this should have worked as the reasoning was that repoinit will create sling:Folder for each node at path /content/myApp/en/services/folderA and then ui.content which has .content.xml defined for each node will update the jcr:primaryType to cq:Page

Apparently that also does not work since the filter definition for "/content/myApp" is set to mode "merge" so if repoinit runs first then that definition stays.

3. I upgraded the ensure nodes for /content/myApp/en/services/folderA to below - 

"ensure nodes (sling:Folder) /content/myApp(cq:Page)/en(cq:Page)/services(cq:Page)/folderA(cq:Page)",

The idea was that repoinit will create cq:Page node and then .content.xml will add jcr:content with type cq:PageContent to the nodes created by repoinit.

This approach works from deployment point of view but when I check the nodes then no jcr:content is present on these.

However, the folderA now has rep:policy node with allow node further tagged to the system user.

I am not sure though why this time with mode merge in place the updated properties from ui.content.

To check if the ui.content was working correctly I reinstalled the package. This time the updated jcr:content reflected in folderA but the rep:policy node disappeared as expected.

So I am having trouble aligning these 2 aspects of repoinit script and ui.content's configuration for the page node.

I am not sure if the problem is as hard as I am finding it to be. Can anyone please help with this?

@arunpatidar, @SantoshSai, @BrianKasingli, @Rohan_Garg, @daniel-strmecki 

daniel-strmecki

Thanks,

Nagesh

[SantoshSai]

Hi @NageshRaja,

Seems like RepoInit executes before ui.content

• RepoInit scripts run during the provisioning of the OSGi container, before your content packages (like ui.content) are installed.

• That means your /content/myApp/... nodes don’t exist yet when RepoInit tries to set ACLs -> hence the PathNotFoundException.

I would Split ACL setup into a separate content package

This is the cleanest, Cloud-safe way.

• Create your system user and ACL setup in a separate content package that depends on your content structure being present.

• You can ensure the order via dependencies in your pom.xml:

  <dependency>
      <groupId>com.myapp</groupId>
      <artifactId>myapp.ui.content</artifactId>
      <version>${project.version}</version>
  </dependency>

• Then your RepoInit can safely assume that /content/myApp/... exists.

RepoInit (in ui.config)

create service user Test with path system/myApp
set ACL for Test
  allow jcr:read on /conf
  allow jcr:all on /content/dam/myApp/folderA
  allow jcr:all on /content/myApp/en/services/folderA
end

This case, No need for ensure nodes since ui.content ensures page structure exists.

[NageshRaja]

Hey @SantoshSai, do we have any documentation or blog link which follows the same?

I actually have multiple repoinit users each tied to some different functionality.

[Rohan_Garg]

Hey @NageshRaja, You might want to read up on a couple of blogs here - 

1.  @Jörg_Hoh has written a great blog on this How to deal with RepoInit failures in Cloud Service

2. https://aemslate.com/aem-cloud-system-service-user-guide

If you check #1 and try the below points from it - 

It is hard to validate this locally, as you don’t have an immutable /apps and /libs, but there is a test approach which comes very close to it:

• Run all your repoinit statements in your local test environment
• Install all your content packages
• Enable write tracing (see my blog post)
• Re-run all your repo-init statements.
• Disable write tracing again

Also @SantoshSai has good suggestion of putting this in a separate content package and have it dependent on your ui.content to ensure the scripts are executed later.

Best Regards,

Rohan Garg

[NageshRaja]

thanks - will try this 👍
Update - I did have this issue wherein the builder is read only came up but right now its not an issue yet still the deployment fails...

Here's the current snip - 

create service user TestUser with path system/projA

ensure nodes (sling:Folder) /content/myApp
ensure nodes (sling:Folder) /conf

set ACL for TestUser
allow jcr:all on /content/dam/myApp/folderA
end

set ACL for TestUser
allow jcr:all on /content/myApp/en/services/folderA
end

set ACL for TestUser
allow jcr:all on /content/myApp/fr/services/folderA
end

set ACL for TestUser
allow jcr:read on /conf
end

[Rohan_Garg · Accepted solution]

I have few follow up queries listed below - 

1. Why are you trying to use ensure nodes?

2. If you are using ensure nodes, are you sure your ui.content is not trying to override the repoinit ensure nodes?
One RCA can be the sequence for repoinit runs twice - So after first time, ui.content would run and have its own configuration and then repoinit finds the ensure nodes violated and throws the error.

3. Generally it's not recommended to have anything of the types cq:Page in the ensure nodes but might not be a bad idea if you are sure #2 is not an issue. That ways your repoinit defines the structure which is validated via ui.content's installation.

Can you send your ui.content's configuration for .content.xml?

Assuming /content/myApp is c:Page and /content/dam/myApp to be sling:Folder can you try the below config?

ensure nodes (nt:folder) /content(sling:OrderedFolder)/dam(sling:Folder)/myApp(sling:Folder)/folderA(sling:Folder)
ensure nodes (nt:folder) /conf(sling:Folder)
ensure nodes (nt:folder) /content(sling:OrderedFolder)/myApp(cq:Page)/en(cq:Page)/services(cq:Page)/folderA(cq:Page)
ensure nodes (nt:folder) /content(sling:OrderedFolder)/myApp(cq:Page)/fr(cq:Page)/services(cq:Page)/folderA(cq:Page)
set ACL for TestUser
allow jcr:all on /content/dam/myApp/folderA
end
set ACL for TestUser
allow jcr:all on /content/myApp/en/services/folderA
end
set ACL for TestUser
allow jcr:all on /content/myApp/fr/services/folderA
end
set ACL for TestUser
allow jcr:read on /conf
end