[
https://issues.apache.org/jira/browse/HDFS-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron T. Myers updated HDFS-4448:
---------------------------------
Attachment: HDFS-4448.patch
Here's a patch which addresses the issue by simply removing the check which is
now overly-restrictive.
No tests are included since to test this adequately one needs multiple hosts
and security to be enabled. I tested this patch on a secure 2-node HA cluster
where each NN is configured itself to bind to 0.0.0.0, but is configured with
an actual address for the other node. I confirmed that everything started up
and checkpointing works as expected.
> HA NN does not start with wildcard address configured for other NN when
> security is enabled
> -------------------------------------------------------------------------------------------
>
> Key: HDFS-4448
> URL: https://issues.apache.org/jira/browse/HDFS-4448
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: ha, namenode, security
> Affects Versions: 2.0.3-alpha
> Reporter: Aaron T. Myers
> Assignee: Aaron T. Myers
> Attachments: HDFS-4448.patch
>
>
> Currently if one tries to configure HA NNs use the wildcard HTTP address when
> security is enabled, the NN will fail to start with an error like the
> following:
> {code}
> java.lang.IllegalArgumentException: java.io.IOException: Cannot use a
> wildcard address with security. Must explicitly set bind address for Kerberos
> {code}
> This is the case even if one configures an actual address for the other NN's
> HTTP address. There's no good reason for this, since we now check for the
> local address being set to 0.0.0.0 and determine the canonical hostname for
> Kerberos purposes using
> {{InetAddress.getLocalHost().getCanonicalHostName()}}, so we should remove
> the restriction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
