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...@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/_h...@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-f...@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
