Return-Path: X-Original-To: apmail-curator-user-archive@minotaur.apache.org Delivered-To: apmail-curator-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F2B6618BC9 for ; Wed, 16 Dec 2015 21:22:05 +0000 (UTC) Received: (qmail 35236 invoked by uid 500); 16 Dec 2015 21:22:00 -0000 Delivered-To: apmail-curator-user-archive@curator.apache.org Received: (qmail 35191 invoked by uid 500); 16 Dec 2015 21:22:00 -0000 Mailing-List: contact user-help@curator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@curator.apache.org Delivered-To: mailing list user@curator.apache.org Received: (qmail 35181 invoked by uid 99); 16 Dec 2015 21:22:00 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Dec 2015 21:22:00 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 2F03D180504 for ; Wed, 16 Dec 2015 21:22:00 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.9 X-Spam-Level: ** X-Spam-Status: No, score=2.9 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id m1MzMg1PINTa for ; Wed, 16 Dec 2015 21:21:51 +0000 (UTC) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id C612C2049F for ; Wed, 16 Dec 2015 21:21:50 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id to18so67444009igc.0 for ; Wed, 16 Dec 2015 13:21:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=XLTUlgW++rrnrdgHneq28yLajXk4COXbfAMa/rsewmk=; b=NKPnR/WUJoSQOSQpjsxIh87GCfl3HOvQ8HxWqDr8g50AhOurobGc7aQJXKROl+ofgc 2k94tGhOFeJ4rcgRq0poI21tIfUlSy0bjH9C5x9a7bHRefbEBiUnWwvYpEKW9WPfaBXC ZT/yL1V3R0C+i7mCMS+1CglnRf6pPDX+7M9OeAIseZqyqSKUPxoNatXCTZvOIRFOSfcl s0nUwgKQ/xbgxpg7DpRpqt4sFQrNuYginiv/X5GmbLDHVFZLT4suTcUge8IRVLoNN0Hv ETAHAoOL1yyIstKU6t5a3BRF30fV74PpRaHW10YJRQXc+k31o+5M8h2TSZ256K0B5ypA DboA== MIME-Version: 1.0 X-Received: by 10.50.7.102 with SMTP id i6mr2049882iga.64.1450300910317; Wed, 16 Dec 2015 13:21:50 -0800 (PST) Received: by 10.50.22.97 with HTTP; Wed, 16 Dec 2015 13:21:50 -0800 (PST) In-Reply-To: References: <9BE4535F-750E-4870-ADF8-8342F38DB426@jordanzimmerman.com> <827041D5-046B-4B40-A7CB-0068B2481670@jordanzimmerman.com> Date: Thu, 17 Dec 2015 08:21:50 +1100 Message-ID: Subject: Re: multiple curator frameworks mixed authentication modes From: Cameron McKenzie To: user@curator.apache.org Content-Type: multipart/alternative; boundary=089e0111b17093b86b05270a7e7e --089e0111b17093b86b05270a7e7e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 < jordan@jordanzimmerman.com> wrote: > Oh - that=E2=80=99s true. I didn=E2=80=99t think of that. Maybe we need a= new feature here. > > On Dec 16, 2015, at 4:15 PM, Cameron McKenzie > 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 < > jordan@jordanzimmerman.com> 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 wrote: >> >> Sorry, don't follow. Let me try and re-phrase: >> >> If I launch a JVM with -Djava.security.auth.login.config=3Djaas.conf >> >> and that jaas.conf contains: >> >> Client { >> com.sun.security.auth.module.Krb5LoginModule required >> useKeyTab=3Dtrue >> keyTab=3D"dariens.keytab" >> storeKey=3Dtrue >> useTicketCache=3Dfalse >> serviceName=3D"zookeeper" >> debug=3Dtrue >> principal=3D"dariens@MY.EXAMPLE "; >> }; >> >> 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 whe= n 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 Quoru= m >> 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 [jordan@jordanzimmerman.com] >> *Sent:* Wednesday, December 16, 2015 2:39 PM >> *To:* user@curator.apache.org >> *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 wrote: >> >> My Java application needs to talk to two ZK clusters. >> >> Cluster one is configured with >> `authProvider.1=3Dorg.apache.zookeeper.server.auth.SASLAuthenticationPro= vider >> 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? >> >> >> > > --089e0111b17093b86b05270a7e7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would think that anything implemented on the Curator sid= e would be prone to race conditions if there were multiple Curator instance= s running within a JVM instance. Because if we clear that global flag to ma= ke a connection for a Curator instance that doesn't want authentication= at the same time that another instance wanting to create / reconnect a con= nection with authentication, one of them is going to potentially go wrong.<= div>
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 <jordan@jordanzimmerman.com> wrote:
Oh - that=E2=80=99s true. I didn=E2=80=99t think of that. M= aybe we need a new feature here.


Would that cause prob= lems 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 <jordan@jordanzimmerman.com> wrote:
I just check in the ZK code.= It does:

<= span style=3D"font-family:Courier;font-size:10.5pt;background-color:rgb(255= ,255,255)">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 <dariens@blackberry.com> wrote:

Sorry, don't follow.=C2=A0 Let me try and re-phrase:
If I launch a JVM with -Djava.security.auth.login.config=3Djaas.conf
and that jaas.conf contains:

Client {
=C2=A0 com.sun.security.a= uth.module.Krb5LoginModule required
=C2=A0 useKeyTab=3Dtrue
=C2=A0 ke= yTab=3D"dariens.keytab"
=C2=A0 storeKey=3Dtrue
=C2=A0 useTi= cketCache=3Dfalse
=C2=A0 serviceName=3D"zookeeper"
=C2=A0 d= ebug=3Dtrue
=C2=A0 principal=3D"dariens@MY.EXAMPLE";
};

When my app= lication starts I instantiate a CuratorFramework object connection to a ZK = cluster that authenticates new connections via SASLAuthenticationProvider a= nd of course this works as expected.=C2=A0=C2=A0

I now = need to instantiate another new CuratorFramework object to another ZK clust= er that does not perform SASL authentication and any attempt to get/set dat= a results in the errors below.

Is there a configuration that I can a= pply when instantiating CuratorFrameworks that will not automatically use S= aslAuthentication when a JAAS login context is present?

[2015-12-16 = 19:47:15,427] ERROR An error: (java.security.PrivilegedActionException: jav= ax.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 Memb= er's=C2=A0 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.PrivilegedActio= nException: javax.security.sasl.SaslException: GSS initiate failed [Caused = by GSSException: No valid credentials provided (Mechanism level: Fail to cr= eate credential. (63) - No service creds)]) occurred when evaluating Zookee= per Quorum Member's=C2=A0 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)=




<= br>
<= b>From:=C2=A0Jordan Zimmerman [jordan@jordanzimmerman.com]
= Sent:=C2=A0Wednesday, December 16, 2015 2:39 PM
To:<= /b>=C2=A0user@curator.apache.org
Subject:=C2=A0Re= : multiple curator frameworks mixed authentication modes

Check your code. There are no static/global values i= n Curator.

-JZ

On Dec 16, 2015, at 2:29 PM, Dave Ariens <dariens@blackberry.com> wrot= e:

My Java application needs to talk to = two ZK clusters.

Cluster one is configured with `authProvider.1=3Dor= g.apache.zookeeper.server.auth.SASLAuthenticationProvider SASLAuthenticatio= nProvider` and cluster two is not.

At first glance it would appear t= hat this isn't possible as all curator frameworks instantiated in my JV= M are attempting to perform SASL authentication when the JVM is launched wi= th the JAAS configuration containing 'Client' configuration.
Any chance I'm missing something or is this a known restriction?
=



--089e0111b17093b86b05270a7e7e--