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 <[email protected]> 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
