Thanks, I think that helps. If I'm no longer updating the Hadoop user, do I have to use doAs for any operation that touches Accumulo? I fear there are lots...
James On Thu, 13 Jun 2019 at 20:21, Josh Elser <[email protected]> wrote: > > Hi James, > > A thread calling checkTGTAndReloginFromKeytab() is still what you want > for renewals. Just make sure you wrap that in a UGI.doAs() for the user > whose ticket you want to renew. > > In general, you just want to wrap any Accumulo-related calls in a doAs() > to avoid fallback onto the "loginUser" semantics that UGI has. Being > explicit with a doAs() for the user you want to run some code as is the > trick. > > Does that help? > > On 6/13/19 3:10 PM, James Srinivasan wrote: > > Hi all, > > > > I'm finally getting around to fixing up some deprecation issues with > > our use of Kerberos with Accumulo and GeoMesa > > (https://github.com/locationtech/geomesa/). Because I didn't know any > > better at the time, I used the KerberosToken ctor specifying that the > > Hadoop user should be replaced. Combined with a thread to periodically > > renew the ticket (calling > > UserGroupInformation.getCurrentUser.checkTGTAndReloginFromKeytab()), > > this has worked nicely for us. > > > > However, there are some unfortunate side effects of updating the > > Hadoop user - for instance, subsequent HDFS operations use the new > > user, who may not have the same permissions as the original user in a > > Zeppelin-type notebook environment. Plus the replaceCurrentUser param > > is deprecated and removed in Accumulo 2.0. So I'm keen on not > > replacing the Hadoop user, but how do I handle ticket renewal? > > > > Thanks very much, > > > > James > >
