hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jitendra Nath Pandey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-2264) NamenodeProtocol has the wrong value for clientPrincipal in KerberosInfo annotation
Date Thu, 25 Aug 2011 23:12:29 GMT

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

Jitendra Nath Pandey commented on HDFS-2264:
--------------------------------------------

In the context of HA, BN should be using same principal as the primary namenode, because on
a failover, it becomes the primary. Therefore NamenodeProtocol must allow the principal of
the primary as well.

> since BN/CN are not available on the 0.20 branch, can we introduce changes that split
out balancer methods to its  
> own protocol and then applies separated configs to namenode protocol and balancer protocols
for their individual 
> principals? I can open a new JIRA for the proto split if this is OK.
 OK for the jira, but I will recommend to first do that in trunk. It will probably be an incompatible
change, so not really recommended for 20.
  

> NamenodeProtocol has the wrong value for clientPrincipal in KerberosInfo annotation
> -----------------------------------------------------------------------------------
>
>                 Key: HDFS-2264
>                 URL: https://issues.apache.org/jira/browse/HDFS-2264
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: name-node
>    Affects Versions: 0.23.0
>            Reporter: Aaron T. Myers
>            Assignee: Harsh J
>             Fix For: 0.23.0
>
>         Attachments: HDFS-2264.r1.diff
>
>
> The {{@KerberosInfo}} annotation specifies the expected server and client principals
for a given protocol in order to look up the correct principal name from the config. The {{NamenodeProtocol}}
has the wrong value for the client config key. This wasn't noticed because most setups actually
use the same *value* for for both the NN and 2NN principals ({{hdfs/_HOST@REALM}}), in which
the {{_HOST}} part gets replaced at run-time. This bug therefore only manifests itself on
secure setups which explicitly specify the NN and 2NN principals.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message