[ 
https://issues.apache.org/jira/browse/HADOOP-6632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kan Zhang updated HADOOP-6632:
------------------------------

    Attachment: HADOOP-6632-Y20S-18.patch

A patch for Yahoo 0.20S branch. Not for commit.

This patch assumes a service's Kerberos principal name is of the form 
"servicename/hostn...@realm", where servicename is the service type (for 
example, dn for DataNodes, and tt for TaskTrackers), hostname is the 
fully-qualified domain name of the host where the service is running on, and 
REALM is Kerberos realm that the service belongs to. To support the convenience 
of having the same conf on every host, a service's Kerberos principal name can 
be configured as "servicename/${fq...@realm", where ${FQDN} will be substituted 
at runtime with the fully-qualified domain name of the host that the service is 
running on.

> Support for using different Kerberos keys for different instances of Hadoop 
> services
> ------------------------------------------------------------------------------------
>
>                 Key: HADOOP-6632
>                 URL: https://issues.apache.org/jira/browse/HADOOP-6632
>             Project: Hadoop Common
>          Issue Type: Improvement
>            Reporter: Kan Zhang
>            Assignee: Kan Zhang
>         Attachments: HADOOP-6632-Y20S-18.patch
>
>
> We tested using the same Kerberos key for all datanodes in a HDFS cluster or 
> the same Kerberos key for all TaskTarckers in a MapRed cluster. But it 
> doesn't work. The reason is that when datanodes try to authenticate to the 
> namenode all at once, the Kerberos authenticators they send to the namenode 
> may have the same timestamp and will be rejected as replay requests. This 
> JIRA makes it possible to use a unique key for each service instance.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to