[
https://issues.apache.org/jira/browse/HADOOP-10016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13900585#comment-13900585
]
Daryn Sharp commented on HADOOP-10016:
--------------------------------------
bq. it (client) tries to do a kerberos based authentication; this fails because
it has no kerberos credentials (it is running as a MR job) - even the fallback
to insecure does not work because it fails before the RPC-connection.
To clarify, this is the behavior of the v8 client, correct? v9 clients should
not attempt kerberos unless requested. If the client conf claims security is
enabled, it will fortunately create a ugi that claims it's kerberos even if
there's no tgt. I think that causes the v9 client to attempt and fail kerberos
in a task. I thought I fixed UGI to not return kerberos when it is really
simple, but it was either undone or not committed.
bq. Solution - have the NN in Insecure2.x return an artificial-token.
Solution that doesn't involve adding more code paths - always enable the secret
manager irregardless of security setting.
> Distcp should support copy from a secure Hadoop 1 cluster to an insecure
> Hadoop 2 cluster
> -----------------------------------------------------------------------------------------
>
> Key: HADOOP-10016
> URL: https://issues.apache.org/jira/browse/HADOOP-10016
> Project: Hadoop Common
> Issue Type: Sub-task
> Reporter: Haohui Mai
> Assignee: Haohui Mai
>
> Distcp should be able to copy from a secure cluster to an insecure cluster.
> This functionality is important for operators to migrate data to a new Hadoop
> installation.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
