[jira] [Commented] (HDFS-4448) HA NN does not start with wildcard address configured for other NN when security is enabled
[
https://issues.apache.org/jira/browse/HDFS-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508674#comment-14508674
]
Arun Suresh commented on HDFS-4448:
---
No tests were included since as [~atm] had mentioned, Tested this manually on a
4 node secure-cluster and ensured both NNs came up and DNs were able to talk to
them.
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
Fix For: 2.8.0
Attachments: HDFS-4448.2.patch, HDFS-4448.patch, 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 was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-4448) HA NN does not start with wildcard address configured for other NN when security is enabled
[
https://issues.apache.org/jira/browse/HDFS-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508413#comment-14508413
]
Hadoop QA commented on HDFS-4448:
-
\\
\\
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | pre-patch | 14m 33s | Pre-patch trunk compilation is
healthy. |
| {color:green}+1{color} | @author | 0m 0s | The patch does not contain any
@author tags. |
| {color:red}-1{color} | tests included | 0m 0s | 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. |
| {color:green}+1{color} | whitespace | 0m 0s | The patch has no lines that
end in whitespace. |
| {color:green}+1{color} | javac | 7m 22s | There were no new javac warning
messages. |
| {color:green}+1{color} | javadoc | 9m 40s | There were no new javadoc
warning messages. |
| {color:green}+1{color} | release audit | 0m 22s | The applied patch does
not increase the total number of release audit warnings. |
| {color:green}+1{color} | checkstyle | 5m 28s | There were no new checkstyle
issues. |
| {color:green}+1{color} | install | 1m 34s | mvn install still works. |
| {color:green}+1{color} | eclipse:eclipse | 0m 32s | The patch built with
eclipse:eclipse. |
| {color:green}+1{color} | findbugs | 3m 5s | The patch does not introduce
any new Findbugs (version 2.0.3) warnings. |
| {color:green}+1{color} | native | 3m 12s | Pre-build of native portion |
| {color:green}+1{color} | hdfs tests | 163m 56s | Tests passed in hadoop-hdfs.
|
| | | 209m 48s | |
\\
\\
|| Subsystem || Report/Notes ||
| Patch URL |
http://issues.apache.org/jira/secure/attachment/12727482/HDFS-4448.2.patch |
| Optional Tests | javadoc javac unit findbugs checkstyle |
| git revision | trunk / 0ebe84d |
| hadoop-hdfs test log |
https://builds.apache.org/job/PreCommit-HDFS-Build/10354/artifact/patchprocess/testrun_hadoop-hdfs.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HDFS-Build/10354/testReport/ |
| Console output |
https://builds.apache.org/job/PreCommit-HDFS-Build/10354//console |
This message was automatically generated.
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
Fix For: 2.8.0
Attachments: HDFS-4448.2.patch, HDFS-4448.patch, 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 was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-4448) HA NN does not start with wildcard address configured for other NN when security is enabled
[
https://issues.apache.org/jira/browse/HDFS-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14503673#comment-14503673
]
Arun Suresh commented on HDFS-4448:
---
[~daryn], [~atm] It looks like after HADOOP-9789 , clients can be configured
with *dfs.namenode.kerberos.principal.pattern* to make it accept a SPN that is
different from the connecting namenode address.
But NN still complains when starting up due to this check, which is now clearly
not required. I plan to rebase and commit this within a day if there are no
objections.
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, 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 was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HDFS-4448) HA NN does not start with wildcard address configured for other NN when security is enabled
[
https://issues.apache.org/jira/browse/HDFS-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13565211#comment-13565211
]
Hadoop QA commented on HDFS-4448:
-
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12566921/HDFS-4448.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. 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.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-hdfs-project/hadoop-hdfs.
{color:green}+1 contrib tests{color}. 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.
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, 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
[jira] [Commented] (HDFS-4448) HA NN does not start with wildcard address configured for other NN when security is enabled
[
https://issues.apache.org/jira/browse/HDFS-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13565405#comment-13565405
]
Daryn Sharp commented on HDFS-4448:
---
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.
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, 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
[jira] [Commented] (HDFS-4448) HA NN does not start with wildcard address configured for other NN when security is enabled
[
https://issues.apache.org/jira/browse/HDFS-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13565110#comment-13565110
]
Hadoop QA commented on HDFS-4448:
-
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12566904/HDFS-4448.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. 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.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-hdfs-project/hadoop-hdfs.
{color:green}+1 contrib tests{color}. 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.
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
