hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-2264) NamenodeProtocol has the wrong value for clientPrincipal in KerberosInfo annotation
Date Wed, 17 Aug 2011 20:27:27 GMT

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

Aaron T. Myers commented on HDFS-2264:

Good point, Jitendra.

I notice, however, that the balancer only appears to use the {{versionRequest}}, {{getBlockKeys}},
and {{getBlocks}} methods of the {{NamenodeProtocol}}. Of these, I believe the 2NN only uses
{{versionRequest}}. Might it make sense, then, to move the {{getBlockKeys}} and {{getBlocks}}
methods out of {{NamenodeProtocol}} and add a new protocol interface, perhaps {{BalancerProtocol}}?

It seems to me now that {{getBlockKeys}} and {{getBlocks}} should have never been added to
{{NamenodeProtocol}} in the first place. At least, the comment at the top of {{NamenodeProtocol}}
is incorrect with those methods in there:

 * Protocol that a secondary NameNode uses to communicate with the NameNode.
 * It's used to get part of the name node state

> 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


View raw message