[
https://issues.apache.org/jira/browse/HADOOP-11017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140813#comment-14140813
]
Alejandro Abdelnur commented on HADOOP-11017:
---------------------------------------------
*AbstractDelegationTokenSecretManager.java*:
* line 55, whitespace change
* constructors, the conf constructor should call the exploded params
constructor.
* exploded params constructor, don’t rename formal parameters.
* line 394, whitespace change
*DelegationTokenAuthenticationHandler.java*:
* lines 21, 41, whitespace changes
* {{initTokenManager()}}, I don’t think you need to do the following, unless
I’m mistaken that has already been done and all properties in conf don’t have
the component prefix. can you please verify this debugging?
{code}
conf.setLong(SecretManager.UPDATE_INTERVAL,
conf.getLong(configPrefix + SecretManager.UPDATE_INTERVAL,
SecretManager.UPDATE_INTERVAL_DEFAULT));
conf.setLong(SecretManager.UPDATE_INTERVAL,
conf.getLong(configPrefix + SecretManager.MAX_LIFETIME,
SecretManager.MAX_LIFETIME_DEFAULT));
conf.setLong(SecretManager.UPDATE_INTERVAL,
conf.getLong(configPrefix + SecretManager.RENEW_INTERVAL,
SecretManager.RENEW_INTERVAL_DEFAULT));
conf.setLong(SecretManager.UPDATE_INTERVAL, conf.getLong(
configPrefix + SecretManager.REMOVAL_SCAN_INTERVAL,
SecretManager.REMOVAL_SCAN_INTERVAL_DEFAULT));
{code}
*SecretManager.java*:
* My bad on suggesting moving the conf props here and adding a constructor, we
shouldn’t touch this class, lets do this in the {{DelegationTokenManager}},
have the a new inner class with just the new constructor and the plain and ZK
subclasses extending from it.
*ZKDelegationTokenSecretManager.java*
* The {{ZK_DTSM_ZK_AUTH_TYPE_DEFAULT}} constant is not used.
* in the constructor, {{if (authType.equals("sasl")}}, the else should be
{{else if 'none' else EXCEPTION}}.
* the names peerKeys and peerTokens are a bit misleading, they should just be
keys and tokens.
* I understand why we have 2 Maps, one for Keys and one for Tokens, still, I
don’t think we should have 2 subtrees in ZK for them, in ZK we could have just
one containing the info for both, on watch/process we can use that info to
update the 2 local Maps.
* IMPORTANT: I think that having our own curator instance here will break
things on reconnect to ZK because of the other ZK connection used by
hadoop-auth, becuase we are setting different sysprop value with the config. We
should either use the same sysprop value for both and it to be the same
JaasConfiguration or we should use the same curator instance. It is a bummer
that ZK uses a sysprop for SASL setup, it should be instance configurable, we
should open a ZK JIRA for that. In the mean time, I would suggest using the
same sysprop value (unding my recommendation in HADOOP-10868, we should use
'Client' there and here we should use the hadoop-auth JaasConfiguration.
> KMS delegation token secret manager should be able to use zookeeper as store
> ----------------------------------------------------------------------------
>
> Key: HADOOP-11017
> URL: https://issues.apache.org/jira/browse/HADOOP-11017
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
> Affects Versions: 2.6.0
> Reporter: Alejandro Abdelnur
> Assignee: Arun Suresh
> Attachments: HADOOP-11017.1.patch, HADOOP-11017.2.patch,
> HADOOP-11017.3.patch, HADOOP-11017.4.patch, HADOOP-11017.5.patch,
> HADOOP-11017.WIP.patch
>
>
> This will allow supporting multiple KMS instances behind a load balancer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
