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]
> <mailto:[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]
>> <mailto:[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] <mailto:[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]
>>> <mailto:[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] <mailto:[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]
>>> <mailto:[email protected]>]
>>> Sent: Wednesday, December 16, 2015 2:39 PM
>>> To: [email protected] <mailto:[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]
>>>> <mailto:[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?
>>
>>
>
>
