[
https://issues.apache.org/jira/browse/HADOOP-12096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14593209#comment-14593209
]
Steve Loughran commented on HADOOP-12096:
-----------------------------------------
{{HttpRequest.getServerName()}} is normally used in webapps as it gives you the
name used by the client to talk to the web site, which you can then use in
responses. This is important it you have >1 NIC with >1 hostname, or doing
multihomed work where >1 hostname maps to the same IP address.
I think in security we're less concerned about having support for multihoming,
and instead having something secure.
AWs comments do make sense; the problem I'd been having with windows and
127.0.0.1 not mapping to localhost was related to MiniKDC tests, where
everything was trying to run locally, not part of a domain.
Looking at the HttpServer2 code, there is a way in the builder API to set the
hostname. Picking the name of the first listener is explicitly listed as a
fallback.
Looking at your patch you are trying to get IP address and then work out the
host, but that's relying on IP DNS lookup working. And while that is something
people should have working in a working Hadoop cluster, it's not something we
can assume in test setups, VMs &c ... the stuff we use a lot for development.
I think the better way address this is issue is to use
{{Builder.setHostname()}} to allow the hostname to be explicitly set. My IDE
says that's what Datanodes do, in
{{DatanodeHttpServer.getHostnameForSpnegoPrincipal()};
That way: no changes in HttpServer2 which could have consequences elsewhere.
Instead, how the RM can be setup is improved.
now, two disclaimers
# I know enough about Keberos to know that I should not be involved in any
reviewing of security patches
# I don't know my way round HttpServer2
Which means that if you are going to do patches, I'm not in a position to say
"+1, committed" to any of them.
> Rest API failing when ip configured in RM address in secure https mode
> ----------------------------------------------------------------------
>
> Key: HADOOP-12096
> URL: https://issues.apache.org/jira/browse/HADOOP-12096
> Project: Hadoop Common
> Issue Type: Bug
> Components: net, security
> Reporter: Bibin A Chundatt
> Assignee: Bibin A Chundatt
> Priority: Critical
> Attachments: 0001-HADOOP-12096.patch, 0001-YARN-3810.patch,
> 0002-YARN-3810.patch
>
>
> Steps to reproduce
> ===============
> 1.Configure hadoop.http.authentication.kerberos.principal as below
> {code:xml}
> <property>
> <name>hadoop.http.authentication.kerberos.principal</name>
> <value>HTTP/[email protected]</value>
> </property>
> {code}
> 2. In RM web address also configure IP
> 3. Startup RM
> Call Rest API for RM {{ curl -i -k --insecure --negotiate -u : https IP
> /ws/v1/cluster/info"}}
> *Actual*
> Rest API failing
> {code}
> 2015-06-16 19:03:49,845 DEBUG
> org.apache.hadoop.security.authentication.server.AuthenticationFilter:
> Authentication exception: GSSException: No valid credentials provided
> (Mechanism level: Failed to find any Kerberos credentails)
> org.apache.hadoop.security.authentication.client.AuthenticationException:
> GSSException: No valid credentials provided (Mechanism level: Failed to find
> any Kerberos credentails)
> at
> org.apache.hadoop.security.authentication.server.KerberosAuthenticationHandler.authenticate(KerberosAuthenticationHandler.java:399)
> at
> org.apache.hadoop.security.token.delegation.web.DelegationTokenAuthenticationHandler.authenticate(DelegationTokenAuthenticationHandler.java:348)
> at
> org.apache.hadoop.security.authentication.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:519)
> at
> org.apache.hadoop.yarn.server.security.http.RMAuthenticationFilter.doFilter(RMAuthenticationFilter.java:82)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
