[
https://issues.apache.org/jira/browse/HADOOP-10519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13985703#comment-13985703
]
Daryn Sharp commented on HADOOP-10519:
--------------------------------------
I never liked the way hdfs tokens are managed. There is no difference between
a hdfs, (s)webhdfs, hftp, etc token so the token kind should be the same.
Unfortunately the service field represents the issuer's address for renewal, as
well as the key for token selection for connections so token duping hacks are
currently used. I've always meant to move to servers returning an opaque
server-id for token selection that would make the protocol irrelevant... For
HA servers, the opaque server-id would be the HA logical name so the same token
would work with both hdfs and webhdfs. But I digress.
All that said, the short answer for now is the service for logical HA webhdfs
tokens should be "ha-webhdfs:hostname".
> In HDFS HA mode, Distcp/SLive with webhdfs on secure cluster fails with
> Client cannot authenticate via:[TOKEN, KERBEROS] error
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-10519
> URL: https://issues.apache.org/jira/browse/HADOOP-10519
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Reporter: Jian He
>
> Opening on [~arpitgupta]'s behalf.
> We observed that, in HDFS HA mode, running Distcp/SLive with webhdfs will
> fail on YARN. In non-HA mode, it'll pass.
> The reason is in HA mode, only webhdfs delegation token is generated for the
> job, but YARN also requires the regular hdfs token to do localization,
> log-aggregation etc.
> In non-HA mode, both tokens are generated for the job.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
