[ 
https://issues.apache.org/jira/browse/ATLAS-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15862223#comment-15862223
 ] 

Madhan Neethiraj commented on ATLAS-1546:
-----------------------------------------

[~gss2002] - by any chance was kinit done for 'hive' user in the host where 
HiveServer2 runs? That might explain the reason for HiveServer2 to use the 
ticket cache. In such case, however, there shouldn't be an error in using that 
ticket to talk to Kafka.

Let me try this in my env.

> Hive hook should choose appropriate JAAS config if host uses kerberos 
> ticket-cache
> ----------------------------------------------------------------------------------
>
>                 Key: ATLAS-1546
>                 URL: https://issues.apache.org/jira/browse/ATLAS-1546
>             Project: Atlas
>          Issue Type: Improvement
>          Components: atlas-intg
>    Affects Versions: 0.7-incubating, 0.8-incubating
>            Reporter: Madhan Neethiraj
>            Assignee: Nixon Rodrigues
>             Fix For: 0.8-incubating
>
>         Attachments: ATLAS-1546.1.patch, ATLAS-1546.patch, 
> hiveserver2_log.txt, hs2.log.gz
>
>
> In a kerberized environment, Atlas hook uses JAAS configuration section named 
> "KakfaClient" to authenticate with Kafka broker. In a typical Hive deployment 
> this configuration section is set to use the keytab and principal of 
> HiveServer2 process. The hook running in HiveCLI might fail to authenticate 
> with Kafka if the user can't read the configured keytab.
> Given that HiveCLI users would have performed kinit, the hook in HiveCLI 
> should use the ticket-cache generated by kinit. When ticket cache is not 
> available (for example in HiveServer2), the hook should use the configuration 
> provided in KafkaClient JAAS section.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to