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

Todd Lipcon commented on KUDU-2267:
-----------------------------------

I believe this problem is actualy worse than just some log spew, in two 
different cases:

(1) all masters have just restarted and have not yet elected a leader

In this case, if a client tries to connect by token, it will get an 
authentication failure from all masters. These are considered non-retriable, so 
the client will fail to connect to the cluster.

(2) the old leader has restarted and existing token-authenticated clients try 
to contact it

If a client is connected to the cluster using token auth, it will have cached 
its concept of which master is the leader master. The master then restarts and 
comes back up as a follower (quite likely). The next time the client tries to 
issue any master RPC, it will attempt to reconnect to its cached leader. In 
this case, that cached leader will not accept the token authentication method 
(because it has no CA cert) and thus the client will fail to authenticate. This 
failure is considered non-retryable, so it doesn't call ReconnectToCluster and 
attempt to find the new leader.

> Client may see negotiation failure when talks to master followers with only 
> self signed cert 
> ---------------------------------------------------------------------------------------------
>
>                 Key: KUDU-2267
>                 URL: https://issues.apache.org/jira/browse/KUDU-2267
>             Project: Kudu
>          Issue Type: Improvement
>          Components: client
>    Affects Versions: 1.6.0
>            Reporter: Hao Hao
>            Priority: Major
>
> Currently, if a master has never been a leader from the very start of the 
> cluster, it has just self-signed cert. And if a client does not have valid 
> Kerberos credential but only authenticated token, then the client may see 
> {{org.apache.kudu.client.NonRecoverableException: Server requires Kerberos, 
> but this client is not authenticated}} error when trying to connect to master 
> followers. Since in that case SASL authentication type is chosen instead of 
> token for authentication.
> It is safe to ignore this error, as long as client is able to connect to 
> master leader. However, for a long term fix, masters should probably attempt 
> to get a signed cert from the leader.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to