Alejandro Abdelnur created HDFS-4457:
----------------------------------------
Summary: WebHDFS obtains/sets delegation token service hostname
using wrong config leading to issues when NN is configured with 0.0.0.0 RPC IP
Key: HDFS-4457
URL: https://issues.apache.org/jira/browse/HDFS-4457
Project: Hadoop HDFS
Issue Type: Bug
Components: webhdfs
Affects Versions: 2.0.2-alpha, 1.1.1
Reporter: Alejandro Abdelnur
Priority: Critical
If the NameNode RPC address is configured with an wildcard IP 0.0.0.0, then
delegationotkens are configured with 0.0.0.0 as service and this breaks clients
trying to use those tokens.
Looking at NamenodeWebHdfsMethods#generateDelegationToken() the problem is
SecurityUtil.setTokenService(t, namenode.getHttpAddress());, tracing back what
is being used to resolve getHttpAddress() the NameNodeHttpServer is resolving
the httpAddress doing a *httpAddress = new
InetSocketAddress(bindAddress.getAddress(), httpServer.getPort());
*, and if using "0.0.0.0" in the configuration, you get 0.0.0.0 from
bindAddress.getAddress().
Normally (non webhdfs) this is not an issue because it is the responsibility of
the client, but in the case of WebHDFS, WebHDFS does it before returning the
string version of the token (it must be this way because the client may not be
a java client at all and cannot manipulate the DelegationToken as such).
The solution (thanks to Eric Sammer for helping figure this out) is for WebHDFS
to use the exacty hostname that came in the HTTP request as the service to set
in the delegation tokens.
--
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
