[
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
