[
https://issues.apache.org/jira/browse/HADOOP-7510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13106764#comment-13106764
]
Daryn Sharp commented on HADOOP-7510:
-------------------------------------
{{HftpFileSystem}}
bq. getCanonicalServiceName in this case uses hftpUri, instead of getUri.
Yes, the prior code's {{getCanonicalServiceName}} did use {{hftpUri}}.
However, {{getUri()}} returns {{hftpUri}}, so the default implementation of
{{getCanonicalServiceName}} is sufficient. Am I overlooking a detail?
bq. I think the difference is that hftpUri uses https port, while getUri uses
nnAddr.getPort(). It doesn't seem to be identical to the default implementation
in FileSystem.
No, {{hftpUri}} uses {{nnAddr.getPort()}}. The {{nnHttpUrl}} contains the
https port. The {{FileSystem}} api expects {{FileSystem.getUri(fs.getUri(),
conf)}} to return the same object, which I believe it does in this case.
{{DFSClient/JobClient}}
{quote}
bq. We need to renew/cancel tokens with the same configuration used to get the
token.
This is not a requirement, particularly because delegation tokens are usually
obtained at the client, while they are renewed at JT. We can't expect same
configurations.
{quote}
Maybe I'm overlooking something, but aren't the client and the JT operating
with the same jobConf? The revamp of token renewal changed the
behavior/instantiation of the client to omit settings by calling a lower-level
method that used to be indirectly invoked by the client ctor. The ctor is
performing configuration that is now lost.
bq. Lets just focus on what needs to be fixed for this jira.
I am concerned about the impact on reconnection, hence why I felt it is
relevant to this jira. I am only trying to instantiate the client exactly as
before to minimize unexpected risk.
All said, I'll investigate the impact of the settings that token renewal is
omitting. If they have no impact on the reliability of reconnect and
renew/cancel, I'll consider leaving it as-is, even though I feel it was not a
good design decision to sacrifice previous flexibility under the assumption
it's not needed for a particular use case.
> Tokens should use original hostname provided instead of ip
> ----------------------------------------------------------
>
> Key: HADOOP-7510
> URL: https://issues.apache.org/jira/browse/HADOOP-7510
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Fix For: 0.20.205.0
>
> Attachments: HADOOP-7510-2.patch, HADOOP-7510-3.patch,
> HADOOP-7510-4.patch, HADOOP-7510-5.patch, HADOOP-7510-6.patch,
> HADOOP-7510.patch
>
>
> Tokens currently store the ip:port of the remote server. This precludes
> tokens from being used after a host's ip is changed. Tokens should store the
> hostname used to make the RPC connection. This will enable new processes to
> use their existing tokens.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
