Hadoop HDFS
  1. Hadoop HDFS
  2. HDFS-4448

HA NN does not start with wildcard address configured for other NN when security is enabled

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0.3-alpha
    • Fix Version/s: None
    • Component/s: ha, namenode, security
    • Labels:
      None

      Description

      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:

      java.lang.IllegalArgumentException: java.io.IOException: Cannot use a wildcard address with security. Must explicitly set bind address for Kerberos
      

      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.

      1. HDFS-4448.patch
        2 kB
        Aaron T. Myers
      2. HDFS-4448.patch
        2 kB
        Aaron T. Myers

        Activity

        Hide
        Aaron T. Myers added a comment -

        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.

        Show
        Aaron T. Myers added a comment - 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.
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12566904/HDFS-4448.patch
        against trunk revision .

        +1 @author. The patch does not contain any @author tags.

        -1 tests included. The patch doesn't appear to include any new or modified tests.
        Please justify why no new tests are needed for this patch.
        Also please list what manual steps were performed to verify this patch.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 javadoc. The javadoc tool did not generate any warning messages.

        +1 eclipse:eclipse. The patch built with eclipse:eclipse.

        -1 findbugs. The patch appears to introduce 1 new Findbugs (version 1.3.9) warnings.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        +1 core tests. The patch passed unit tests in hadoop-hdfs-project/hadoop-hdfs.

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/3901//testReport/
        Findbugs warnings: https://builds.apache.org/job/PreCommit-HDFS-Build/3901//artifact/trunk/patchprocess/newPatchFindbugsWarningshadoop-hdfs.html
        Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/3901//console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12566904/HDFS-4448.patch against trunk revision . +1 @author . The patch does not contain any @author tags. -1 tests included . The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. -1 findbugs . The patch appears to introduce 1 new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-hdfs-project/hadoop-hdfs. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/3901//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HDFS-Build/3901//artifact/trunk/patchprocess/newPatchFindbugsWarningshadoop-hdfs.html Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/3901//console This message is automatically generated.
        Hide
        Aaron T. Myers added a comment -

        Whoops, left an unused variable in the previous patch. This patch is to address that findbugs warning.

        Show
        Aaron T. Myers added a comment - Whoops, left an unused variable in the previous patch. This patch is to address that findbugs warning.
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12566921/HDFS-4448.patch
        against trunk revision .

        +1 @author. The patch does not contain any @author tags.

        -1 tests included. The patch doesn't appear to include any new or modified tests.
        Please justify why no new tests are needed for this patch.
        Also please list what manual steps were performed to verify this patch.

        +1 javac. The applied patch does not increase the total number of javac compiler warnings.

        +1 javadoc. The javadoc tool did not generate any warning messages.

        +1 eclipse:eclipse. The patch built with eclipse:eclipse.

        +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

        +1 release audit. The applied patch does not increase the total number of release audit warnings.

        +1 core tests. The patch passed unit tests in hadoop-hdfs-project/hadoop-hdfs.

        +1 contrib tests. The patch passed contrib unit tests.

        Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/3902//testReport/
        Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/3902//console

        This message is automatically generated.

        Show
        Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12566921/HDFS-4448.patch against trunk revision . +1 @author . The patch does not contain any @author tags. -1 tests included . The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . The javadoc tool did not generate any warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-hdfs-project/hadoop-hdfs. +1 contrib tests . The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/3902//testReport/ Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/3902//console This message is automatically generated.
        Hide
        Daryn Sharp added a comment -

        Does this present any issues for kerberos authentication on the multiple interfaces? I think we'd need principals for each canonical hostname of all interfaces, which I'm not sure the security infrastructure will support? Although perhaps I'm misunderstanding the issue.

        Show
        Daryn Sharp added a comment - Does this present any issues for kerberos authentication on the multiple interfaces? I think we'd need principals for each canonical hostname of all interfaces, which I'm not sure the security infrastructure will support? Although perhaps I'm misunderstanding the issue.
        Hide
        Aaron T. Myers added a comment -

        That's a great point, Daryn, and I agree with your analysis. Even though this patch will allow the NNs to start and function properly when bound to the wildcard address, clients (or DNs) will not in fact be able to connect on any interface not contained in the principal name used by the RPC server of the NN. A proper fix for this is thus somewhat more involved than I had originally anticipated.

        Show
        Aaron T. Myers added a comment - That's a great point, Daryn, and I agree with your analysis. Even though this patch will allow the NNs to start and function properly when bound to the wildcard address, clients (or DNs) will not in fact be able to connect on any interface not contained in the principal name used by the RPC server of the NN. A proper fix for this is thus somewhat more involved than I had originally anticipated.

          People

          • Assignee:
            Aaron T. Myers
            Reporter:
            Aaron T. Myers
          • Votes:
            0 Vote for this issue
            Watchers:
            11 Start watching this issue

            Dates

            • Created:
              Updated:

              Development