grabbit AEM 6.3 compatibility/verification

@sagarsane

May 22 '17 21:05 jbornemann

👍

May 23 '17 00:05 sagarsane

I'm having issues integrating Grabbit 7.1.2 on a new AEM 6.3. Long story short, any time I perform a GET on /grabbit path (eg. localhost:4502/grabbit/job), I always run into this:

I notice I also receive a 409 response on PUT requests. Anyone else running into this on 6.3? Or is there a configuration I'm missing? Did not have any issues with previous versions on 6.2, so I'm glomping on this open issue.

Jun 12 '17 13:06 dscirto

Interesting.

We might have to do some debugging in the GrabbitResourceProvider

Jun 12 '17 15:06 jbornemann

Thanks @jbornemann , let me know if there are any configurations I should look at that could be indirectly causing problems or if you need some logs down the road to help with debugging.

Jun 12 '17 16:06 dscirto

@dscirto just curious .. you don't have the Deserialization firewall enabled on your instance do you?

If you do, you may need to install the Config Package provided to exclude Grabbit from it.

More info can be found here : https://github.com/TWCable/grabbit/blob/master/docs/AEMSupport.adoc#what-you-need-to-run-grabbit (the 3rd bullet point)

Jun 12 '17 21:06 sagarsane

@sagarsane, @jbornemann : I started fresh, installed all the config packages.. Running into multiple issues..

For new job request, config JSON that works on 6.1 not working on 6.3

Processing.....

~~~~~~~~~Failure~~~~~~~~~~~~~

Something went wrong when processing the given config.

cURL, the transfer library used by this shell received an error code of 22. See https://curl.haxx.se/libcurl/c/libcurl-errors.html for debugging.
If this doesn't help, please check the client log for more details.

For monitor job as well, its not going to the GrabbitJobServlet..

I saw difference in behavior of Resource provider between 6.3 and 6.1. Taking example of monitor job, on:

6.1, getResource is called 3 times - /grabbit/job/dsdads, /grabbit/job and /grabbit.. Then it goes to the GrabbitJobServlet.
6.3, getResource is called 3 times - /grabbit/job/dsdads, /grabbit/job and /grabbit.. This goes to RootResourceServlet..

Jun 13 '17 07:06 viveksachdeva

One more observation:

/grabbit/job/adsa.json resolves correctly to the resource but not to the servlet in 6.3

Jun 13 '17 08:06 viveksachdeva

@sagarsane Looks like OOTB AEM 6.3 has Deserialization Firewall configured so I'll take your suggestion

Jun 13 '17 14:06 dscirto

@jbornemann @dscirto @viveksachdeva I think its happening because of this #188

Jun 13 '17 17:06 sagarsane

Will try to get to some testing today and will look at #188

Jun 14 '17 14:06 dscirto

I can verify seeing the same thing as @viveksachdeva

Noticed in relation to #188 that checking "Bypass the whitelist" config option does not resolve issue. Note that I have not run across the exception in #188 however, with-or-without the configuration option

Jun 14 '17 17:06 dscirto

@dscirto just to clarify -- I saw the exception mentioned in #188 when the bundle is being installed and activated.

Jun 14 '17 18:06 sagarsane

@sagarsane : Checked by whitelisting config mentioned in #188.. The error goes away with that.. Whitelisting it could be a stopgap fix, so atleast grabbit works on 6.3..

Jun 19 '17 09:06 viveksachdeva

@viveksachdeva does that mean you have been able to trigger a sync with the whitelisting?

Jun 19 '17 14:06 dscirto

@dscirto : yeah.. I can sync content after making that config change

Jun 22 '17 09:06 viveksachdeva

I was able to verify that I can sync from one local AEM 6.3 to another local AEM 6.3 with the firewall deserialization package and login admin whitelist. I am also able to view jobs as expected at "/grabbit/job/all.json" as expected.

Thanks for the debugging!

Jun 30 '17 18:06 dscirto

Thanks for confirming @dscirto and for raising this issue!

Jul 01 '17 15:07 sagarsane

I'm still having the issues described above with Grabbit 7.1.2 on AEM 6.3. I have installed the Deserialization firewall package as well as checked whitelist.bypass on org.apache.sling.jcr.base.internal.LoginAdminWhitelist.

Admittedly, this is my first time using Grabbit, so it could be something else I'm doing. Any suggestions?

Aug 17 '17 08:08 remingtonreed

@remingtonreed : Could you please share the exact issue that you are having..? Logs would be helpful..

Aug 17 '17 12:08 viveksachdeva

I'm pretty well getting the same results from above. Here is the message that the bash script returns.

~~~~~~~~~Failure~~~~~~~~~~~~~

Something went wrong when processing the given config.

cURL, the transfer library used by this shell received an error code of 22. See https://curl.haxx.se/libcurl/c/libcurl-errors.html for debugging.
If this doesn't help, please check the client log for more details.

I've checked the grabbit-receive.log, grabbit-send.log, and error.log of both servers and can't see any meaningful error, so I'm not sure what else to check there.

Here are the OSGi configs after modifying them (this is what both the receiving and sending end look like)

admin-whitelist

deserialization-firewall

Unfortunately pretty well all of the useful pieces of the config seem like sensitive information, however, I just copied the sample one and modified each field. Thanks!

Aug 17 '17 15:08 remingtonreed

@remingtonreed : Did you install Sun-Misc-Fragment bundle as well as mentioned in README.. https://bintray.com/artifact/download/twcable/aem/dependencies/Sun-Misc-Fragment-Bundle-1.0.0.zip

Aug 18 '17 02:08 viveksachdeva

@viveksachdeva: Yes, here are the packages I installed on both sending and receiving instances.

Aug 18 '17 04:08 remingtonreed

Hey @remingtonreed, will you be able to provide an excerpt of the error.log on the Grabbit Client (at least) which shows the OSGi activity when Grabbit bundle is installed?

Aug 18 '17 15:08 sagarsane

Hey @remingtonreed, I'm facing the exact same issues right now. Were you able to get any progress?

I have the three packages installed and the whitelist.bypass checked but I see the cURL error code 22.

Thanks a lot!