[ 
https://issues.apache.org/jira/browse/HADOOP-9299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13602438#comment-13602438
 ] 

Alejandro Abdelnur commented on HADOOP-9299:
--------------------------------------------

on the rules setting, you got it.

on using the kerberos principal short name instead the uid for non-secure 
cluster, you are right that you are not changing behavior or making it worse, 
that is the current behavior. still it seems wrong to me as it would mean that 
a client depending on being kinit-ed or not it could be a different user for a 
non-secure cluster. we should not fix this as part of this ticket, but I think 
we should fix that.


                
> kerberos name resolution is kicking in even when kerberos is not configured
> ---------------------------------------------------------------------------
>
>                 Key: HADOOP-9299
>                 URL: https://issues.apache.org/jira/browse/HADOOP-9299
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 2.0.3-alpha
>            Reporter: Roman Shaposhnik
>            Assignee: Daryn Sharp
>            Priority: Blocker
>         Attachments: HADOOP-9299.patch
>
>
> Here's what I'm observing on a fully distributed cluster deployed via Bigtop 
> from the RC0 2.0.3-alpha tarball:
> {noformat}
> 528077-oozie-tucu-W@mr-node] Error starting action [mr-node]. ErrorType 
> [TRANSIENT], ErrorCode [JA009], Message [JA009: 
> org.apache.hadoop.security.authentication.util.KerberosName$NoMatchingRule: 
> No rules applied to yarn/localhost@LOCALREALM
>         at 
> org.apache.hadoop.security.token.delegation.AbstractDelegationTokenIdentifier.<init>(AbstractDelegationTokenIdentifier.java:68)
>         at 
> org.apache.hadoop.mapreduce.v2.api.MRDelegationTokenIdentifier.<init>(MRDelegationTokenIdentifier.java:51)
>         at 
> org.apache.hadoop.mapreduce.v2.hs.HistoryClientService$HSClientProtocolHandler.getDelegationToken(HistoryClientService.java:336)
>         at 
> org.apache.hadoop.mapreduce.v2.api.impl.pb.service.MRClientProtocolPBServiceImpl.getDelegationToken(MRClientProtocolPBServiceImpl.java:210)
>         at 
> org.apache.hadoop.yarn.proto.MRClientProtocol$MRClientProtocolService$2.callBlockingMethod(MRClientProtocol.java:240)
>         at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:454)
>         at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1014)
>         at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1735)
>         at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1731)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at javax.security.auth.Subject.doAs(Subject.java:396)
>         at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1441)
>         at org.apache.hadoop.ipc.Server$Handler.run(Server.java:1729)
> Caused by: 
> org.apache.hadoop.security.authentication.util.KerberosName$NoMatchingRule: 
> No rules applied to yarn/localhost@LOCALREALM
>         at 
> org.apache.hadoop.security.authentication.util.KerberosName.getShortName(KerberosName.java:378)
>         at 
> org.apache.hadoop.security.token.delegation.AbstractDelegationTokenIdentifier.<init>(AbstractDelegationTokenIdentifier.java:66)
>         ... 12 more
> ]
> {noformat}
> This is submitting a mapreduce job via Oozie 3.3.1. The reason I think this 
> is a Hadoop issue rather than the oozie one is because when I hack 
> /etc/krb5.conf to be:
> {noformat}
> [libdefaults]
>    ticket_lifetime = 600
>    default_realm = LOCALHOST
>    default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc
>    default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc
> [realms]
>    LOCALHOST = {
>        kdc = localhost:88
>        default_domain = .local
>    }
> [domain_realm]
>    .local = LOCALHOST
> [logging]
>    kdc = FILE:/var/log/krb5kdc.log
>    admin_server = FILE:/var/log/kadmin.log
>    default = FILE:/var/log/krb5lib.log
> {noformat}
> The issue goes away. 
> Now, once again -- the kerberos auth is NOT configured for Hadoop, hence it 
> should NOT pay attention to /etc/krb5.conf to begin with.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to