kudu-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Serbin <aser...@cloudera.com>
Subject Re: I got an "authentication token expired" error.
Date Fri, 16 Jun 2017 01:42:19 GMT
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 <aserbin@cloudera.com 
> <mailto:aserbin@cloudera.com>>:
>
>     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
>
>
>


Mime
View raw message