[
https://issues.apache.org/jira/browse/HADOOP-9299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13597781#comment-13597781
]
Alejandro Abdelnur commented on HADOOP-9299:
--------------------------------------------
Daryn, Arun,
I don't know when this broke as the previous version of Hadoop 2 we tested
successfully in Apache Oozie was 0.23.x.
When testing oozie/hadoop in bigtop for the prev release, using hadoop
2.0.2-alpha this was not a problem, so I assume something went wrong after that.
By looking at the code, o.a.h.security.User constructor always does
KerberosName resolution by calling 'new KerberosName(name).getShortName()'
This does not seem correct to me. IMO, the correct way -because of the fallback
from secure to unsecure of the client- is:
* If hadoop client is configured with Kerberos and the cluster has kerberos
enabled, then the kerberos shortName should be used.
* Regardless of the hadoop client configuration, if the cluster is unsecure,
the Java System Property 'user.name' should be used.
What change make things to break, I don't know, but unless I'm missing
something, if the logic just described is not done then you may end up in all
sort of weird issues depending of KRB5 settings and rules settings in the
core-site.xml
Thoughts?
> 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
> Priority: Blocker
>
> 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
