Indeed! I guess you could do some static synchronization, but I think that it would be error prone and pretty ugly. I think that the ZK client is the sensible place for it to be fixed. The constructor could presumably just take a flag indicating whether authentication is desired or not.
On Thu, Dec 17, 2015 at 8:22 AM, Jordan Zimmerman < [email protected]> wrote: > jinx > > On Dec 16, 2015, at 4:21 PM, Cameron McKenzie <[email protected]> > wrote: > > 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? >>> >>> >>> >> >> > >
