Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

Rebuild client libraries error

Avatar

Level 4

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

1 Accepted Solution

Avatar

Correct answer by
Employee

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

View solution in original post

15 Replies

Avatar

Employee

Hi Alistair,

Its highly possible one of the JS/CSS files is not able to minify when you build the client libraries using the /libs/granite/ui/content/dumplibs.rebuild.html

I will try on 1.8.448 and respond back.

Thanks

Avatar

Employee

Sorry for the delay, I was try to set up a system with 1.8.448 Uber. I couldnt reproduce the issue.

After seeing the screenshot, my bet would be to double check the ACLs on /var/clientlibs or ACLs at /apps/acs-commons

Thanks

Avatar

Level 4

Hey, thanks for the reply.

For my own sanity I've gone back to try and reproduce the error myself from scratch starting with a completely new AEM 6.1 installation. To be certain that it was the FP5 package causing the problem I installed all additional packages we have on our server in increments. After each installation, I restarted the server then ran the invalidate / rebuild clientlibs steps. These are the packages I installed:

  • 6.1 service pack 1
  • 6640 & 6680
  • Communities FP3
  • Communities FP5

After each installation the invalidate caches step worked fine. The rebuild libs step also worked fine except for FP5. Once I got to that package, I started getting the same errors I had in the screenshot.

I'm not sure if it is a permissions problem on /var/clientlibs because this folder gets removed during the first step to invalidate the caches. On two of our systems, my local one and our dev server, I can see that when I install FP5 the rebuild libraries step conks out.

Avatar

Employee

The only step i missed is installing the service pack 1. So let me try and respond back.

Thanks

Avatar

Level 9

Hi Alistair,

For AEM 6.1, the most recent service pack is SP2.

Information about SP2 and a subsequent cumulative fix pack (CFP) is on AEM Help hotfix page.

Notice - you no longer need to explicitly install 6640 and 6680.  And even though Communities FP5 will indicate they're missing, they're not.  The code is contained in the service pack, but the actual HF packages are not present.  It is necessary to retain this warning in case AEM 6.1 is installed without service packs.

- JK

Avatar

Employee

I was able to reproduce the issue, with 6.1 service pack1 & Communities FP5. I tried it with 6.1 service pack 2 and re-installed the Communities FP5 and the issue was gone.

Arun

Avatar

Administrator

As stated by "Arun", please try it with AEM 6.1 + SP2 + Communities FP5.

~kautuk



Kautuk Sahni

Avatar

Level 4

Thanks everyone for the advice and info.

I've given this another crack with SP2 but am still getting errors. I started with a fresh AEM, installed SP2, restarted, and then installed FP5.

Arun, what were the steps you took to get it to work? You mentioned that you had to reinstall FP5, did you already have it installed before adding SP2?

Avatar

Level 4

Hi all,

We may have edged a bit closer to finding a solution to this.

When we install feature pack 5, it creates a service user called clientlibs-service. This user has a series of nodes with permissions in jcr:system/rep:permissionStore to root folders (/etc, /apps) and also the /var/clientlibs folder; this is the folder that is coming up in the error messages.

When the first step is run to invalidate the caches, it deletes the node with the permissions for this user to access /var/clientlibs. Could it be that feature pack 5 is changing the core service for invalidating caches/rebuilding clientlibs by having them depend on the clientlibs-service user to run them? If so, would removing these permissions cause the service to stop running and also, why are these permissions removed?

Avatar

Employee

Actually FP5 (Communities) doesnt create or use the service user called clientlibs-service. Also we dont explicitly trigger rebuilding of clientlibs.

For me when I installed SP2 after FP5, I was seeing the issue again. But after I reinstalled FP5 (clicked install on socialcommunities pkg again), the issue resolved itself.

This is definitely an issue and an inconvenience, and we are also trying to get to the bottom of it. But given that SP2 and FP5 are out already the only short term option we have now are workarounds.

Avatar

Level 4

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.

Avatar

Employee

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

Avatar

Level 4

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

Avatar

Correct answer by
Employee

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

Avatar

Level 4

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