accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: kerberos auth, getDelegationToken
Date Sat, 06 Jun 2015 21:04:20 GMT
Simon,

Did you create a client configuration file (~/.accumulo/config or 
$ACCUMULO_CONF_DIR/client.conf)? You need to configure Accumulo clients 
to actually use SASL when you're trying to use Kerberos authentication. 
Your server is expecting that, but I would venture a guess that your 
client isn't.

See 
http://accumulo.apache.org/1.7/accumulo_user_manual.html#_configuration_3

Xu (Simon) Chen wrote:
> Josh,
>
> Thanks. It makes sense...
>
> I used a KerberosToken, but my program got stuck when running the following:
> new ZooKeeperInstance(instance, zookeepers).getConnector(user, krbToken)
>
> It looks like my client is stuck here:
> https://github.com/apache/accumulo/blob/master/core/src/main/java/org/apache/accumulo/core/client/impl/ConnectorImpl.java#L70
> failing in the receive part of
> org.apache.accumulo.core.client.impl.thrift.ClientService.Client.authenticate().
>
> On my tservers, I see the following:
>
> 2015-06-06 18:58:19,616 [server.TThreadPoolServer] ERROR: Error
> occurred during processing of message.
> java.lang.RuntimeException:
> org.apache.thrift.transport.TTransportException:
> java.net.SocketTimeoutException: Read timed out
>          at org.apache.thrift.transport.TSaslServerTransport$Factory.getTransport(TSaslServerTransport.java:219)
>          at org.apache.accumulo.core.rpc.UGIAssumingTransportFactory$1.run(UGIAssumingTransportFactory.java:51)
>          at org.apache.accumulo.core.rpc.UGIAssumingTransportFactory$1.run(UGIAssumingTransportFactory.java:48)
>          at java.security.AccessController.doPrivileged(Native Method)
>          at javax.security.auth.Subject.doAs(Subject.java:356)
>          at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1622)
>          at org.apache.accumulo.core.rpc.UGIAssumingTransportFactory.getTransport(UGIAssumingTransportFactory.java:48)
>          at org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:208)
>          at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>          at org.apache.accumulo.fate.util.LoggingRunnable.run(LoggingRunnable.java:35)
>          at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.thrift.transport.TTransportException:
> java.net.SocketTimeoutException: Read timed out
>          at org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:129)
>          at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
>          at org.apache.thrift.transport.TSaslTransport.receiveSaslMessage(TSaslTransport.java:182)
>          at org.apache.thrift.transport.TSaslServerTransport.handleSaslStartMessage(TSaslServerTransport.java:125)
>          at org.apache.thrift.transport.TSaslTransport.open(TSaslTransport.java:253)
>          at org.apache.thrift.transport.TSaslServerTransport.open(TSaslServerTransport.java:41)
>          at org.apache.thrift.transport.TSaslServerTransport$Factory.getTransport(TSaslServerTransport.java:216)
>          ... 11 more
> Caused by: java.net.SocketTimeoutException: Read timed out
>          at java.net.SocketInputStream.socketRead0(Native Method)
>          at java.net.SocketInputStream.read(SocketInputStream.java:152)
>          at java.net.SocketInputStream.read(SocketInputStream.java:122)
>          at java.io.BufferedInputStream.read1(BufferedInputStream.java:273)
>          at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
>          at org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:127)
>          ... 17 more
>
> Any ideas why?
>
> Thanks.
> -Simon
>
>
>
>
> On Sat, Jun 6, 2015 at 2:19 PM, Josh Elser<josh.elser@gmail.com>  wrote:
>> Make sure you read the JavaDoc on DelegationToken:
>>
>> <snip>
>> Obtain a delegation token by calling {@link
>> SecurityOperations#getDelegationToken(org.apache.accumulo.core.client.admin.DelegationTokenConfig)}
>> </snip>
>>
>> You cannot create a usable DelegationToken as the client itself.
>>
>> Anyways, DelegationTokens are only relevant in cases where the client
>> Kerberos credentials are unavailable. The most common case is running
>> MapReduce jobs. If you are just interacting with Accumulo through the Java
>> API, the KerberosToken is all you need to use.
>>
>> The user-manual likely just needs to be updated. I believe the
>> DelegationTokenConfig was added after I wrote the initial documentation.
>>
>>
>> Xu (Simon) Chen wrote:
>>> Hi folks,
>>>
>>> The latest kerberos doc seems to indicate that getDelegationToken can be
>>> called without any parameters:
>>>
>>> https://github.com/apache/accumulo/blob/1.7/docs/src/main/asciidoc/chapters/kerberos.txt#L410
>>>
>>> Yet the source code indicates a DelegationTokenConfig object must be
>>> passed in:
>>>
>>> https://github.com/apache/accumulo/blob/1.7/core/src/main/java/org/apache/accumulo/core/client/admin/SecurityOperations.java#L359
>>>
>>> Any ideas on how I should construct the DelegationTokenConfig object?
>>>
>>> For context, I've been trying to get geomesa to work on my accumulo 1.7
>>> with kerberos turned on. Right now, the code is somewhat tied to
>>> password auth:
>>>
>>> https://github.com/locationtech/geomesa/blob/rc7_a1.7_h2.5/geomesa-core/src/main/scala/org/locationtech/geomesa/core/data/AccumuloDataStoreFactory.scala#L177
>>> My thought is that I should get a KerberosToken first, and then try
>>> generate a DelegationToken, which is passed back for later interactions
>>> between geomesa and accumulo.
>>>
>>> Thanks.
>>> -Simon

Mime
View raw message