I would think that anything implemented on the Curator side would be prone to race conditions if there were multiple Curator instances running within a JVM instance. Because if we clear that global flag to make a connection for a Curator instance that doesn't want authentication at the same time that another instance wanting to create / reconnect a connection with authentication, one of them is going to potentially go wrong.
I guess the simple solution for the initial poster (Dave) is to run in separate VMs, but I guess that's not an option? On Thu, Dec 17, 2015 at 8:18 AM, Jordan Zimmerman < [email protected]> wrote: > Oh - that’s true. I didn’t think of that. Maybe we need a new feature here. > > On Dec 16, 2015, at 4:15 PM, Cameron McKenzie <[email protected]> > wrote: > > Would that cause problems on an attempt to reconnect (doesn't Curator > recreate the ZK client under some circumstances?)? > > On Thu, Dec 17, 2015 at 7:37 AM, Jordan Zimmerman < > [email protected]> wrote: > >> I just check in the ZK code. It does: >> >> System.getProperty(Environment.JAAS_CONF_KEY) >> >> So, just manual set/clear this property before creating the Curator >> instance. >> >> -JZ >> >> On Dec 16, 2015, at 3:00 PM, Dave Ariens <[email protected]> wrote: >> >> Sorry, don't follow. Let me try and re-phrase: >> >> If I launch a JVM with -Djava.security.auth.login.config=jaas.conf >> >> and that jaas.conf contains: >> >> Client { >> com.sun.security.auth.module.Krb5LoginModule required >> useKeyTab=true >> keyTab="dariens.keytab" >> storeKey=true >> useTicketCache=false >> serviceName="zookeeper" >> debug=true >> principal="[email protected] <[email protected]>"; >> }; >> >> When my application starts I instantiate a CuratorFramework object >> connection to a ZK cluster that authenticates new connections via >> SASLAuthenticationProvider and of course this works as expected. >> >> I now need to instantiate another new CuratorFramework object to another >> ZK cluster that does not perform SASL authentication and any attempt to >> get/set data results in the errors below. >> >> Is there a configuration that I can apply when instantiating >> CuratorFrameworks that will not automatically use SaslAuthentication when a >> JAAS login context is present? >> >> [2015-12-16 19:47:15,427] ERROR An error: >> (java.security.PrivilegedActionException: >> javax.security.sasl.SaslException: GSS initiate failed [Caused by >> GSSException: No valid credentials provided (Mechanism level: Fail to >> create credential. (63) - No service creds)]) occurred when evaluating >> Zookeeper Quorum Member's received SASL token. Zookeeper Client will go to >> AUTH_FAILED state. (org.apache.zookeeper.client.ZooKeeperSaslClient) >> [2015-12-16 19:47:15,427] ERROR SASL authentication with Zookeeper Quorum >> member failed: javax.security.sasl.SaslException: An error: >> (java.security.PrivilegedActionException: >> javax.security.sasl.SaslException: GSS initiate failed [Caused by >> GSSException: No valid credentials provided (Mechanism level: Fail to >> create credential. (63) - No service creds)]) occurred when evaluating >> Zookeeper Quorum Member's received SASL token. Zookeeper Client will go to >> AUTH_FAILED state. (org.apache.zookeeper.ClientCnxn) >> [2015-12-16 19:47:15,427] ERROR Authentication failed >> (org.apache.curator.ConnectionState) >> >> >> >> >> >> ------------------------------ >> *From:* Jordan Zimmerman [[email protected]] >> *Sent:* Wednesday, December 16, 2015 2:39 PM >> *To:* [email protected] >> *Subject:* Re: multiple curator frameworks mixed authentication modes >> >> Check your code. There are no static/global values in Curator. >> >> -JZ >> >> On Dec 16, 2015, at 2:29 PM, Dave Ariens <[email protected]> wrote: >> >> My Java application needs to talk to two ZK clusters. >> >> Cluster one is configured with >> `authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider >> SASLAuthenticationProvider` and cluster two is not. >> >> At first glance it would appear that this isn't possible as all curator >> frameworks instantiated in my JVM are attempting to perform SASL >> authentication when the JVM is launched with the JAAS configuration >> containing 'Client' configuration. >> >> Any chance I'm missing something or is this a known restriction? >> >> >> > >
