hadoop-common-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Toebbicke <...@pclella.cern.ch>
Subject Re: Client mapred tries to renew a token with renewer specified as nobody
Date Mon, 09 Dec 2013 09:13:20 GMT

Le 5 déc. 2013 à 05:30, Vinod Kumar Vavilapalli a écrit :

> 
> It is clearly mentioning that the renewer is wrong (renewer marked is 'nobody' but mapred
is trying to renew the token), you may want to check this.
> 
> Thanks,
> +Vinod
> 
> On Dec 2, 2013, at 8:25 AM, Rainer Toebbicke wrote:
> 
>> 2013-12-02 15:57:08,541 ERROR org.apache.hadoop.security.UserGroupInformation: PriviledgedActionException
as:mapred/xxx.cern.ch@CERN.CH (auth:KERBEROS) cause:org.apache.hadoop.security.AccessControlException:
Client mapred tries to renew a token with renewer specified as nobody
> 

Thanks, I had already guessed so far and finally the problem turned out a subtle bug in the
Cloudera "Configuring MRv1 Security" instructions: they recommend to specify mapreduce.jobtracker.kerberos.principal
as mapred/_HOST@YOUR-REALM.COM in mapred-site.xml. That won't work.

It confuses TokenCache.obtainTokensForNamenodesInternal() when it tries to obtain mapred's
HadoopKerberosName.getShortname(): it finds the untranslated _HOST which a correctly configured
hadoop.security.auth_to_local would not recognize as valid cluster node. That's where "nobody"
comes in. 

Solution: mapreduce.jobtracker.kerberos.principal should really be full a fully resolved mapred/jobtracker-fqdn@YOUR-REALM.COM
and thus would usually pass the hadoop.security.auth_to_local rules.

One could argue that TokenCache.obtainTokensForNamenodesInternal() actually uses getShortname()
from the wrong side of the fence but the little change fixes the problem.

Thanks, Rainer
Mime
View raw message