Woops, that's my typo -- I should have copied-pasted the name of the
flag, like I did with the rest of them.
I'm glad it worked for you.
On 6/15/17 6:29 PM, Jason Heo wrote:
Hi Alexey,
Thank you for helping me.
validity seconds works like a charm!
But I found that 'n' is missing,so that
"--auth*n*_token_validity_seconds" is valid.
Thanks!
2017-06-15 3:37 GMT+09:00 Alexey Serbin <[email protected]
<mailto:[email protected]>>:
Hi Jason,
It seems your Java Kudu client hit the authn token expiration
issue. As you mentioned, that's a well known issue and it is
described in the docs. Just FYI, the Kudu C++ client starting
1.4.0 automatically re-acquires authn token when needed, and I
hope the Java client will do so as well in next release. If you
are interested in details, the issue is tracked by
https://issues.apache.org/jira/browse/KUDU-2013
<https://issues.apache.org/jira/browse/KUDU-2013> and is being
actively worked on (there is a WIP patch for that).
As for a temporary workaround, you could try one the following:
* Set authn token expiration time to some huge value, i.e. run
the Kudu masters with custom value for the
--auth_token_validity_seconds flag. The default is 7 days (604800
seconds); you could try to set it to, say, 300 days:
'--auth_token_validity_seconds=25920000'. That would be a good
option if your use-case requires a secure Kudu cluster with
authentication. For this workaround, once Kudu masters are
restarted with new flags, you also need to restart your Java
clients to acquire a new token with longer TTL if you don't want
them to hit the issue in one week.
* Disable RPC authentication and encryption, i.e. run both Kudu
masters and tablet servers with '--rpc_authentication=disabled
--rpc_encryption=disabled' flags (you need to disable both authn
and encryption). That would be an option if your use-case does
not require a secure Kudu cluster. In this case you don't need to
restart your Java clients once you restarted Kudu server-side
components.
Hope this helps.
Kind regards,
Alexey
On 6/14/17 2:44 AM, Jason Heo wrote:
Hi.
I'm using Apache Kudu 1.4.0.
And I have a long running Java Daemon which is a kudu client
at the same time.
Today (7 days has been past since the Java Daemon has been
started) I suddenly got an following error.
W0614 15:29:11.934401 62459 negotiation.cc:310] Unauthorized
connection attempt: Server connection negotiation failed:
server connection from ip_addr:56604: authentication token expired
W0614 15:29:11.956845 62459 negotiation.cc:310] Unauthorized
connection attempt: Server connection negotiation failed:
server connection from ip_addr:56606: authentication token expired
...
...
...
W0614 17:47:18.347970 74099 negotiation.cc:310] Unauthorized
connection attempt: Server connection negotiation failed:
server connection from ip_addr:56172: authentication token expired
W0614 17:47:20.488306 74100 negotiation.cc:310] Unauthorized
connection attempt: Server connection negotiation failed:
server connection from ip_addr:56180: authentication token expired
Kudu is started with this options
--unlock_experimental_flags=true
...
--superuser_acl=user1,user2
The Java Daemon is started with user2 account.
How can I prevent from happening this error again.
I've read this manual.
https://kudu.apache.org/docs/security.html#known-limitations
<https://kudu.apache.org/docs/security.html#known-limitations>
It says that "so long-lived clients in secure clusters are not
supported" Then Should I set `--rpc-authentication=disable`?
Thanks.
Regards,
Jason
