[
https://issues.apache.org/jira/browse/HADOOP-12732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15113116#comment-15113116
]
Arpit Agarwal commented on HADOOP-12732:
----------------------------------------
We've seen deployments where hosts are configured with multiple hostnames and
{{InetAddress.getLocalHost()}} does not always return the hostname you'd
expect. We have {{*.dns.interface}} settings for predictable reverse
resolution. I am not familiar with the {{addDelegationToken}} logic so I am not
sure if it needs something similar.
Also shouldn't it be {{InetAddress.getLocalHost().getCanonicalHostName()}} at
least?
> Filesystem.addDelegationToken() should automatically replace _HOST
> ------------------------------------------------------------------
>
> Key: HADOOP-12732
> URL: https://issues.apache.org/jira/browse/HADOOP-12732
> Project: Hadoop Common
> Issue Type: Improvement
> Components: fs
> Affects Versions: 2.7.1
> Reporter: Daniel Templeton
> Assignee: Daniel Templeton
> Priority: Critical
> Attachments: HADOOP-12732.001.patch
>
>
> It is currently the client's responsibility to call
> {{SecurityUtil.getServerPrincipal()}} to replace the _HOST placeholder in any
> principal name used for a delegation token. This is a non-optional operation
> and should not be pushed onto the client. As the
> {{SecurityUtil.getServerPrincipal()}} call is already designed to be both
> highly efficient and idempotent, I see no reason not to move the call into
> the {{FileSystem.addDelegationToken()}} call.
> As additional incentive, all client apps that followed the distributed shell
> as the canonical example failed to do the replacement because distributed
> shell fails to do the replacement. (See YARN-4629.) Rather than fixing the
> whole world, let's move the operation into the API where it belongs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
