Rebuild client libraries error | Community
Skip to main content
November 8, 2016
Solved

Rebuild client libraries error

  • November 8, 2016
  • 15 replies
  • 16957 views

I'm having trouble rebuilding the client libraries in our AEM author instance when using this URL: /libs/granite/ui/content/dumplibs.rebuild.html

I am following the same process I have always done which is to invalidate the caches first then rebuild them.

I've attached a screenshot of the errors I am getting.

The only thing that has changed configuration-wise on this AEM server since this process last worked was the installation of Communities Feature Pack 5 1.8.448.

Has anyone seen this before and potentially give advice on how to resolve it?

Alistair

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by donwalling

Hi,

We've confirmed that there is an incompatibility between Communities FP5 and FP6 and the Invalidate Caches function.  Communities FP5 requires com.adobe.granite.ui.clientlibs.content-1.0.4.zip for some of the admin ui screens. That package introduces a serviceuser "clientlibs-service" for manipulating the /var/clientlibs directory. The dumplibs.rebuild.html script in 6.1 which is in a different package does not use the serviceuser, and is coded to remove the /var/clientlibs directory during invalidation. When rebuild is triggered, the serviceuser does not have sufficient privileges to recreate the /var/clientlibs directory. A workaround is as follows:

1. Confirm the system does still have the /var/clientlibs folder intact. If it does not have that folder, recreate it and grant the clientlibs-service principal the jcr:read and rep:write privileges. This returns the system to the correct initial condition

2. Prevent future deletions of the folder by modifying /libs/granite/ui/components/dumplibs/rebuild.jsp as follows:

a) delete the following 2 lines of code, which should currently be lines 85 and 86 in the file:  

s.getNode(TMP_LOCATION).remove(); s.save();

b) add the following code in its place:

NodeIterator nodeIt = s.getNode(TMP_LOCATION).getNodes(); while (nodeIt.hasNext()) { Node child = (Node) nodeIt.next(); if (!"rep:policy".equals(child.getName())) { child.remove(); } } if (s.hasPendingChanges()) { s.save(); }

 

This is the approach being used in AEM 6.2 and later with the clientlibs-service user

HTH,

Don

15 replies

November 18, 2016

As far as I can tell, FP5 does create that system user. It took a bit of delving around for me to find this, but this is the node within the feature pack that creates it:

AEM-6.1-Communities-Feature-Pack-5-1.8.448.zip/jcr_root/etc/packages/day/cq61/social/console...

/cq-social-compatibility-pkg-0.0.12.zip/jcr_root/etc/packages/adobe/granite...

/com.adobe.granite.ui.clientlibs.content-1.0.4.zip/jcr_root/home/users/system/clientlibs-service

If you look at the list of system users in crx/de/home/users/system, the clientlibs-service user is not there on a fresh AEM 6.1 but does appear after installing FP5.

Adobe Employee
November 23, 2016

Hi Alistair,

I just wanted to update my side of the investigation.

I started a 6.1 instance, then installed SP2. After that I reinstalled com.adobe.granite.ui.clientlibs.content-1.0.4.zip (<instance>/crx/packmgr/index.jsp#/etc/packages/adobe/granite/com.adobe.granite.ui.clientlibs.content-1.0.4.zip) and I was able to reproduce the issue you see after installing FP5.

I wanted to isolate if Communities FP5 was causing this. As you see in my steps, I am not even uploading or installing communities Feature pack. So this is a SP2 bug and will try to find out if there is fix in progress for this.

Thanks

November 24, 2016

Hi Arun,

Thanks for the update. This thread has now been marked as solved but I'm not convinced it has been since the errors haven't been resolved my end.

You said, "After that I reinstalled com.adobe.granite.ui.clientlibs.content-1.0.4.zip ... and I was able to reproduce the issue you see after installing FP5."

This is an FP5 issue as the package, com.adobe.granite.ui.clientlibs.content-1.0.4.zip, is bundled with the FP5 package (I've pasted the full path below). The clientlibs.content package may be what is causing the problem but since it's bundled into FP5 (perhaps erroneously?), that by extension is now the root of the issue.

Alistair

 

The clientlibs system user package path within FP5: 

AEM-6.1-Communities-Feature-Pack-5-1.8.448.zip/jcr_root/etc/packages/day/cq61/social/console/cq-social-compatibility-pkg-0.0.12.zip/jcr_root/etc/packages/adobe/granite/com.adobe.granite.ui.clientlibs.content-1.0.4.zip/jcr_root/home/users/system/clientlibs-service

donwallingAdobe EmployeeAccepted solution
Adobe Employee
November 28, 2016

Hi,

We've confirmed that there is an incompatibility between Communities FP5 and FP6 and the Invalidate Caches function.  Communities FP5 requires com.adobe.granite.ui.clientlibs.content-1.0.4.zip for some of the admin ui screens. That package introduces a serviceuser "clientlibs-service" for manipulating the /var/clientlibs directory. The dumplibs.rebuild.html script in 6.1 which is in a different package does not use the serviceuser, and is coded to remove the /var/clientlibs directory during invalidation. When rebuild is triggered, the serviceuser does not have sufficient privileges to recreate the /var/clientlibs directory. A workaround is as follows:

1. Confirm the system does still have the /var/clientlibs folder intact. If it does not have that folder, recreate it and grant the clientlibs-service principal the jcr:read and rep:write privileges. This returns the system to the correct initial condition

2. Prevent future deletions of the folder by modifying /libs/granite/ui/components/dumplibs/rebuild.jsp as follows:

a) delete the following 2 lines of code, which should currently be lines 85 and 86 in the file:  

s.getNode(TMP_LOCATION).remove(); s.save();

b) add the following code in its place:

NodeIterator nodeIt = s.getNode(TMP_LOCATION).getNodes(); while (nodeIt.hasNext()) { Node child = (Node) nodeIt.next(); if (!"rep:policy".equals(child.getName())) { child.remove(); } } if (s.hasPendingChanges()) { s.save(); }

 

This is the approach being used in AEM 6.2 and later with the clientlibs-service user

HTH,

Don

November 28, 2016

Hi Don,

Thanks very much for this workaround. I've had a go at implementing it this morning and it works perfectly. We'll use this until we get round to upgrading to 6.2

Cheers,

Alistair