> On 15 Nov 2018, at 15:16, ZongtianHou <zongtian...@icloud.com.INVALID> wrote:
> 
> Hi, everyone,
> When I access insecure hdfs cluster, call getDelegationToken interface, then 
> namenode give me a token anyway, but when I send a token cancel request, it 
> report the error below, 
> It seem wired, why not return NULL since the cluster is insecure and now that 
> the token has been given, why cancelling it will cause error. Is there some 
> ways to avoid it? 
> I am working on many clusters with same application, which cannot distinguish 
> bettween the secure and insecure. Any hint will be very appreciated.  

HDFS will issue DTs if Kerberos *or* web auth is enabled; though if you look 
closely MapReduce, Spark, etc only collect them when UGI.isSecurityEnabled() == 
true. 

Filesystems are expected to return null from getCanonicalServiceName() if they 
aren't issuing DTs; returning a string means they are issuing tokens. You 
should be able to check that before collecting DTs.

Look at TokenCache.obtainTokensForNamenodes() to see their logic
> 
> 2018-11-15 22:20:49,464 WARN org.apache.hadoop.security.UserGroupInformation: 
> No groups available for user postgres
> 90112 2018-11-15 22:20:49,494 WARN 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem: trying to get DT with no 
> secret manager running
> 90113 2018-11-15 22:20:49,517 INFO org.apache.hadoop.ipc.Server: IPC Server 
> handler 1 on 8020, call 
> org.apache.hadoop.hdfs.protocol.ClientProtocol.cancelDelegationToken from 
> 127.      0.0.1:58969 Call#5 Retry#-1
> 90114 java.io.EOFException
> 90115         at java.io.DataInputStream.readByte(DataInputStream.java:267)
> 90116         at 
> org.apache.hadoop.security.token.delegation.AbstractDelegationTokenIdentifier.readFields(AbstractDelegationTokenIdentifier.java:191)
> 90117         at 
> org.apache.hadoop.security.token.delegation.AbstractDelegationTokenSecretManager.cancelToken(AbstractDelegationTokenSecretManager.java:519)
> 90118         at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.cancelDelegationToken(FSNamesystem.java:7436)
> 90119         at 
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.cancelDelegationToken(NameNodeRpcServer.java:542)
> 90120         at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.cancelDelegationToken(ClientNamenodeProtocolServerSideTranslatorPB.java:995)
> 90121         at 
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
> 90122         at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:619)
> 90123         at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:975)
> 90124         at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2040)
> 90125         at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2036)
> 90126         at java.security.AccessController.doPrivileged(Native Method)
> 90127         at javax.security.auth.Subject.doAs(Subject.java:422)
> 90128         at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1692)
> 90129         at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2034)
> 90130 2018-11-15 22:21:05,589 INFO 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem: Roll Edit Log from 
> 127.0.0.1
> 90131 2018-11-15 22:21:05,589 INFO 
> org.apache.hadoop.hdfs.server.namenode.FSEditLog: Rolling edit logs
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
> For additional commands, e-mail: common-dev-h...@hadoop.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

Reply via email to