So how is the best way to Get an accumulo connector if the cluster is kerberized ? I have done the following: 1- add a jaas.conf for zookeeper 2 create an instance (that logs in via sasl into zookeeper) 3- generate an AuthToken from KerberosToken class which logs the user in the ugi in but keeps the object on KerberosToken class 3 UserGroupInformation.loginwithkeythat(...,...) - this is needed because the thrift Client server just get’s the user from ugi but it is not there(because KerberosToken keeps the state) 4 - get the connector and passing the token
Would be nicer that we let the state on the ugi instead of the KerberosToken We could create a public method from KerberosToken that logs the user in via ugi.... what you mean with side effects ? Jorge Machado jo...@jmachado.me<mailto:jo...@jmachado.me> Am 27.10.2017 um 18:31 schrieb Josh Elser <els...@apache.org<mailto:els...@apache.org>>: Nearly all components in the Hadoop ecosystem require you to perform a login with your credentials when writing Java code. The only exception I'm aware of is ZooKeeper which can automatically perform a login via JAAS. Supporting automatic login via JAAS would be the best path forward here. Creating unique side-effects around security credentials in Accumulo is a bad idea (which is why the method you're referring to on KerberosToken was marked as Deprecated so that we eventually remove it). On 10/27/17 12:06 PM, Jorge Machado wrote: Hi Guys, I just started developing a Accumulo Client with Kerberos and sasl. It was a hell to figure out that you need to call yourself UserGroupInformation.loginfromkeytab(principal,keytab) and then you can call KerberosToken(principal,keytab) this all because we deprecated the replaceuser from the ugi. Later on when we get the connector this breaks apart mainly because for example my keytab is has not the same user as the os account where I’m developing. It would be nice to just login the user. What are the are you guys thinking about this ? Regards Jorge
