Solr with Sentry, Databased backed storage

[#1]

Hi,

I am using Solr with Sentry service.
Both Service are up and running properly but when I run below command, I get NullPointer Error

solrctl sentry --list-roles

ERROR tools.SentryShellSolr: Config key sentry.service.client.server.rpc-address is required
java.lang.NullPointerException: Config key sentry.service.client.server.rpc-address is required
at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:208)
at org.apache.sentry.provider.db.generic.service.thrift.SentryGenericServiceClientDefaultImpl.<init>(SentryGenericServiceClientDefaultImpl.java:123)
at org.apache.sentry.provider.db.generic.service.thrift.SentryGenericServiceClientFactory.create(SentryGenericServiceClientFactory.java:31)
at org.apache.sentry.provider.db.generic.tools.SentryShellSolr.run(SentryShellSolr.java:50)
at org.apache.sentry.provider.db.tools.SentryShellCommon.executeShell(SentryShellCommon.java:241)
at org.apache.sentry.provider.db.generic.tools.SentryShellSolr.main(SentryShellSolr.java:95)
The operation failed. Message: Config key sentry.service.client.server.rpc-address is require

 Any help/hint is appreciable. Thanks! 

EDIT : 1

Following is the message I get when I try to add priviledges using Hue.

{ "message": "{\"responseHeader\":{\"status\":401,\"QTime\":26},\"error\":{\"metadata\":[\"error-class\",\"org.apache.solr.common.SolrException\",\"root-error-class\",\"org.apache.sentry.binding.solr.authz.SentrySolrAuthorizationException\"],\"msg\":\"org.apache.sentry.binding.solr.authz.SentrySolrAuthorizationException: User admin does not have privileges for admin\",\"code\":401}}\n (error 401)", "traceback": [ [ "/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hue/desktop/libs/libsolr/src/libsolr/api.py", 481, "configs", "return self._root.get('admin/configs', params=params)['configSets']" ], [ "/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hue/desktop/core/src/desktop/lib/rest/resource.py", 98, "get", "return self.invoke(\"GET\", relpath, params, headers=headers, allow_redirects=True)" ], [ "/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hue/desktop/core/src/desktop/lib/rest/resource.py", 79, "invoke", "urlencode=self._urlencode)" ], [ "/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hue/desktop/core/src/desktop/lib/rest/http_client.py", 163, "execute", "raise self._exc_class(ex)" ] ], "detail": null, "title": "Error while accessing Solr" }

[#2]

Hi,

Can you please confirm what version of CDH are you using? Solr with Sentry is only supported in CDH5.8.x.

Thanks

[#3]

CDH version is 5.8.0.

[#4]

I'm getting the same behaviour with CDH 5.8.0. The only way that I've found to get past the SentryShellSolr NullPointerException is to run the command on the machine that Sentry is running on. Only those machines get the sentry-site.xml deployed to them with the required key/value pair in it.

Unfortunately, after resolving that then I instead get:

WARN security.UserGroupInformation: PriviledgedActionException as:<user-account> (auth:KERBEROS) cause:org.apache.thrift.transport.TTransportException: Peer indicated failure: Problem with callback handler

Based on this post then this is actually a security issue and <user-account> isn't listed in the "sentry.service.allow.connect" setting.

Once I used the correct server and an account that was listed in sentry.service.allow.connect then "solrctl sentry ..." commands run successfully.

The only down-side now is that Solr/Sentry appears to be ignoring Linux groups as a way of identifying which role a user has, despite it working when I used a flat file and despite Solr's "sentry.provider" value being set to org.apache.sentry.provider.file.HadoopGroupResourceAuthorizationProvider.

[#5]

Hi, I'm going through the same problem up to where roles-to-group mapping are not being associated correctly, have anyone reported this already or found a workaround?

[#6]

It has been a while since I looked at this, but I think it ended up reading from Hue groups when using the Hue interface (particularly when you used PAM as the Hue authenticator rather than LDAP, Kerberos or similar). I can't be sure, though. I didn't report this as an issue, but I believe it is working in our development system (rather than my ad-hoc initial testing cluster of three VMs and a rough LDAP/Kerberos system).

[#7]

Solved. FYI, in my case (even though I still dont understand the reason) I had to drop the external table I was using to create my new table, and recreate it, that way I stopped getting the 4k limititation error. So, updating serde_params and columns_v2 was enough, I went with mediumtext.