Member since
04-09-2019
254
Posts
140
Kudos Received
34
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 2178 | 05-22-2018 08:32 PM | |
| 14752 | 03-15-2018 02:28 AM | |
| 3962 | 08-07-2017 07:23 PM | |
| 4739 | 07-27-2017 05:22 PM | |
| 2680 | 07-27-2017 05:16 PM |
05-01-2017
04:07 PM
Awesome ! Thanks @Gerd Koenig for the update. I'm glad that it worked out for you. Cheers.
... View more
04-28-2017
04:03 PM
The correct commands are - kadmin.local -q "getprincs solr/<hostname>"
kadmin.local -q "getprincs HTTP/<hostname>"
... View more
04-28-2017
03:58 PM
1 Kudo
Hello @Gerd Koenig, I don't see any problem with the encryption type here. There are couple of reasons for this kind of error: 1. Please check the SOLR hostname in the curl request is exactly same as what is used in keytab "solr/<solr-hostname>". In ideal condition, both should be FQDN. Also check the same for SPNEGO keytab (HTTP/<solr-hostname>). 2. The Key Version Number (kvno) of solr/<sorl-hostname> and HTTP/<solr-hostname> should be same in the keytab and in MIT KDC database. You can do a 'klist -kt <keytab>' and 'kadmin.local -q "getprincs solr/<solr-hostname>" ' to compare the kvno. In case the error persist, please set KRB5_TRACE and then run kinit & curl to get more debug output and paste here: export KRB5_TRACE=/tmp/curl-krb.log
kinit <user-principal>
klist -eaf
curl -iv --negotiate -u : http://<solr-hostname>:8983/solr
Hope this helps!
... View more
04-27-2017
04:57 PM
Nice work @Arpit Khare ! This is going to be quite useful for the folks around. Thank you and keep it up !!
... View more
04-26-2017
06:46 PM
Hello @Haaris Khan, The following applied to HDP 2.5.3.0 and above. You can restrict AD groups to access different components of Zeppelin (interpreter, configurations, credentials) like this: 1. Add all your AD groups against some role(s). To do this, you have the following in the [main] section: activeDirectoryRealm.groupRolesMap = "cn=hr,ou=CorpUsers,dc=lab,dc=hortonworks,dc=net":"endusers","cn=legal,ou=CorpUsers,dc=lab,dc=hortonworks,dc=net":"admin","cn=sales,ou=CorpUsers,dc=lab,dc=hortonworks,dc=net":"readonly" Note: You can create roles with any name that you like.
2. Next, define the access for these roles in the [urls] section: [urls]
/api/version = anon
/api/interpreter/** = authc, roles[endusers,readonly]
/api/configurations/** = authc, roles[readonly]
/api/credential/** = authc, roles[admin]
/** = authc
#/** = anon
With these two, your LDAP group should be authorized to access the only the specific URLs. Hope this helps.
... View more
04-24-2017
05:23 PM
Hi @Daniel Kozlowski, Yes, I do see an option in HDP 2.6 Zeppelin (v0.7.0) to schedule a note based on cron. You can go to any notebook and click on clock icon to setup scheduling. I believe this is what you were looking for. Hope this helps.
... View more
04-24-2017
01:21 PM
Hello @Juan Manuel Nieto, The 'request is a replay' usually means that your Kerberos KDC is processing two same requests (almost) at the same time and 'thinks' that the second request is actually a replay attack than a legitimate request. Therefore it will drop the second request. Things to check here: 1. KDC logs - try to find out for which requests and what principal, it is complaining about 2. Application log - Check YARN ATS log for any possible error w.r.t. Kerberos 3. Are you using same keytab with multiple services? (apart from spnego.service.keytab which is shared across services on a node). If yes, please try and use different keytabs for different services. For the logs, it'll be worth to increase the Kerberos debug level by setting up "-Dsun.security.krb5.debug=true" in the JVM parameters and also try 'export KRB5_TRACE=/tmp/somefile' on the client-side before running a curl request (using browser won't help much). Hope this helps !
... View more
04-23-2017
06:05 PM
3 Kudos
Hello @Varun R, From the error stack, it seems that Ranger permission checker is not even getting invoked and it is falling back to 'hdfs-acl'. By following that doc, are you sure that you have changed the ownership of the directory '/user/admin' to 'admin:hadoop' as mentioned? I can still see that the owner as "root:hdfs". This could be possible cause of the error. Please run this command to change the ownership correctly and check them again by listing all the files: # hdfs dfs -chown -R admin:hadoop /user/admin
## Check the permisions - it should show admin:hadoop for all the files
# hdfs dfs -ls -R /user/admin/ Hope this helps.
... View more
04-22-2017
06:51 PM
1 Kudo
Hello @Keshav Piplani, Not sure what you are asking here. Please share configuration file setting for domain Exactly what configuration you are looking for? How does it relate Kerberos? What is your end-goal here? I'd start by setting up a 'working' HDP cluster, then reading about Kerberos KDC & client and then enabling Kerberos via Ambari. Hope this helps !
... View more
04-21-2017
09:58 PM
Hello @Geoffrey Shelton Okot, Thanks for attaching the screenshot and the configuration snippet. From the Ambari configuration, the LDAP base is set to "OU=Users,OU=Enterprise,DC=hq,DC=uk,DC=com". So all the users and groups will be looked inside this. From the attached screenshot, it seems like the group 'hadoop_administrators' exist outside 'OU=Users...". Please change the baseDn in Ambari configuration to a common branch from where you can see the users and groups both. That should fix this issue and your group will be found. In case, a top level baseDn is giving you too many results that you don't want, you can filter them by using the correct searchFilters. Hope this helps !
... View more