[
https://issues.apache.org/jira/browse/HDFS-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070761#comment-13070761
]
Aaron T. Myers commented on HDFS-2193:
--------------------------------------
I'm of the opinion that the NN's hostname determination should be changed to be
the same as the way the DN presently does it, namely the result of
"{{InetAddress.getLocalHost().getCanonicalHostName()}}".
It may be that there's some good reason for this asymmetry that I can't think
of. (Distinct internal/external interfaces on the NN?) If so, the resolution of
this JIRA should probably just be to clearly document how all the various
daemons determine their own hostnames.
This same asymmetry exists between the JT and TT as well, but I figure we
should just discuss the appropriate solution to this issue here first, and then
I'll file a complementary MR JIRA once we figure out the correct course of
action.
> The NN should determine its own hostname using the same method as the DN
> ------------------------------------------------------------------------
>
> Key: HDFS-2193
> URL: https://issues.apache.org/jira/browse/HDFS-2193
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node, security
> Affects Versions: 0.23.0
> Reporter: Aaron T. Myers
> Assignee: Aaron T. Myers
>
> When the "{{_HOST}}" replacement feature of Kerberos principal names is used,
> the various Hadoop daemons must determine their own canonical hostname in
> order to form their principal name.
> Presently, the NN determines its own hostname based on the configured value
> of "{{fs.default.name}}", whereas the DNs determine their hostnames based on
> the result of "{{InetAddress.getLocalHost().getCanonicalHostName()}}". This
> asymmetry can cause confusion during configuration of a secure cluster.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
