Rebuild client libraries error | Adobe Higher Education
Skip to main content
Level 4
November 8, 2016
解決済み

Rebuild client libraries error

  • November 8, 2016
  • 15 の返信
  • 16970 ビュー

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

このトピックへの返信は締め切られました。
ベストアンサー 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 の返信

Level 4
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

Level 4
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

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

Level 4
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