[
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)