hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zhijie Shen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-2049) Delegation token stuff for the timeline sever
Date Thu, 22 May 2014 22:35:03 GMT

    [ https://issues.apache.org/jira/browse/YARN-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14006542#comment-14006542

Zhijie Shen commented on YARN-2049:

Thanks for review, Vinod and Varun! Please see the response bellow:

bq. 1. In the function managementOperation, should there be a null check for token?

There're following code before processing each dtOp:
if (dtOp.requiresKerberosCredentials() && token == null) {
                  "Operation [{0}] requires SPNEGO authentication established",
          requestContinues = false;
Get and renew both require kerberos credentials, such that if token == null, the code will
fall into this part. Cancel didn't require credentials before refer to HttpFS's code. However,
I think we should enforce kerberos credentials for cancel as well. After that, the NPE risk
is gone.

bq. In the function managementOperation, you call secretManager.cancelToken(dt, UserGroupInformation.getCurrentUser().getUserName())
- should you use getCurrentuser().getUserName? or ownerUGI.getUserName()? 

Good catch, we should use token.getUserName here as well.

bq. TimelineKerberosAuthenticator

Some errors may cause TimelineAuthenticator not getting the correct response. If the status
code is not 200, the json content may contain the exception information from the server, we
can use the information recover exception object. This is inspired by HttpFSUtils.validateResponse,
but I changed to use Jackson to parse the json content here.

bq. TimelineAuthenticationFilter

In the configuration we can simply set the authentication type to "kerberos", but in the timeline
sever, we want to replace it with the class name of the customized authentication service.
Otherwise, the standard authentication handler will be used instead. I added the code comments

bq. TimelineKerberosAuthenticationHandler
bq. TimelineDelegationTokenSecretManagerService.

Yeah, we need to look into how to reuse the existing code, but how about postpone it later?
I'm going to file a separate Jira for code refactoring.

bq. TestDistributedShell change is unnecessary


bq. TimelineDelegationTokenSelector: Wrap the debug logging in debugEnabled checks.

Added the debugEnabled checks.

bq. ApplicationHistoryServer.java

Actually it will not override the other initializers. Instead, I just append a TimelineAuthenticationFilterInitializer.
Anyway, I enhance the condition here: not only the security should be enabled, but also "kerberos"
authentication is desired.

bq. TimelineKerberosAuthenticationHandler


bq. TimelineKerberosAuthenticator.

Good suggestion. I split the code accordingly.

bq. TimelineAuthenticationFilterInitializer

AuthenticationFilterInitializer has a single method to do everything, and the prefix is a
static variable, which makes me a bit difficult to override part of code without changing
AuthenticationFilterInitializer. One another issue is that AuthenticationFilterInitializer
requires user to supply a secret file, which is not actually required by AuthenticationFilter

> Delegation token stuff for the timeline sever
> ---------------------------------------------
>                 Key: YARN-2049
>                 URL: https://issues.apache.org/jira/browse/YARN-2049
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Zhijie Shen
>            Assignee: Zhijie Shen
>         Attachments: YARN-2049.1.patch, YARN-2049.2.patch, YARN-2049.3.patch, YARN-2049.4.patch,
YARN-2049.5.patch, YARN-2049.6.patch

This message was sent by Atlassian JIRA

View raw message