Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

Can CDH5.3 Sentry work without Kerberos?

avatar
Contributor

I am trying to evaluate Sentry in the CDH5.3 virtual machine provided by Cloudera.  Unfortunately I am having a lot of problems getting it to even work and I throught I'd check that my assumption that I can even get it to work is correct.

 

In this ( http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/cm_sg_sentry_service.ht... ) documentation the prereqisites say:

I don't have kerberos or LDAP (since I'm in the virtual machine) so I override the HiveServer2/Hive Metastore requirement for strong authentication.

 

The last prerequisite says I need to implement Kerberos authentication.  Is this only if I want Impala to work; or will it stop Sentry from working entirely.

 

 

Thanks

Ty

 

1 ACCEPTED SOLUTION

avatar
Expert Contributor

The original script Eric Sammer wrote up used to be working when CM didn't have the wizard which enables Kerberos. I made some changes with his.

Please use mine instead and specify the password as cloudera in the wizard.

 

See also the step 7 in my github page.

 

https://github.com/daisukebe/krb-bootstrap

 

daisukebe has changed the behavior for configuring Kerberos with Cloudera Manager 5.1 (and above). Then this script just generates a principal as cloudera-scm/admin for CM with a password as 'cloudera'.

View solution in original post

12 REPLIES 12

avatar
Contributor

Thanks for the link to your kerberos bootstrap'er.  It seems to work for me.  Unfortunately I ran into a secondary problem and I'm not sure how to let Cloudera know about it.

 

On a clean CDH5.3 virtual machine I started Cloudera Manager and then ran your kerberos bootstrapper.  Then I ran the Kerberos configuration wizard in Cloudera Manager.  The restart failed to complete successfully.  It seemed like the Yarn NameNode was having trouble with the topology.map amd container-executer.cfg file permissions in the /var/run/cloudera-scm-agent/process/??-yarn-NODEMANAGER/ directory (note: ?? is a number generated each time I tried to restart the NodeManager).

 

On further inspection, and a couple snapshot reverts, I think I found the real problem.  the /etc and /etc/hadoop directories have group write permissions set.  This was identified in the NodeManager logs.  I started again and changed the permissions to remove the group write permission on both directories - before running the Cloudera Manager Kerberos configuration wizard.  This time it seems to have worked.  note: I hve not yet had a chance to test kerberos actually doing anything from a hdfs/hive/pig user perspective.

 

Only one last glitch in the system.  It looks like Spark does not have Kerberos credentials created for it.  The Spark History Server is showing as critical health and its log is identifying missing Kerberos credentials.  When I look at the Kerberos Credentials screen in Cloudera Manager I see credentials for all the services excpt Spark.  I'm not doing anything with Spark and I don't know anything about it so I'll just stop the service for now.

 

I am not sure if changing the directory permissions on /etc and /etc/hadoop will adversely affect other functions; but I hope my little investigation can help others.

avatar
Expert Contributor
Thanks for the information!
Hmm, I have never met such kinds of problem, but I don't think the change
you did will break the other finctionalities.

Daisuke

avatar
Usually /etc/ and /etc/hadoop don't have group write permissions. Not sure how they got there, but removing it seems like a good idea.