[jira] [Commented] (ZOOKEEPER-1000) Provide SSL in zookeeper to be able to run cross colos.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15484538#comment-15484538 ] Jason Rosenberg commented on ZOOKEEPER-1000: Hi [~fpj] since 3.5.X is still alpha, it would of course be great to get this out under 3.4.X as well! Also, for 3.5.X, can we see about also including the mods I referenced above as well, in order to support a more general configuration for certs (e.g. different file formats/file locations)? > Provide SSL in zookeeper to be able to run cross colos. > --- > > Key: ZOOKEEPER-1000 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1000 > Project: ZooKeeper > Issue Type: Improvement >Reporter: Mahadev konar >Assignee: Mahadev konar > Fix For: 3.5.3, 3.6.0 > > > This jira is to track SSL for zookeeper. The inter zookeeper server > communication and the client to server communication should be over ssl so > that zookeeper can be deployed over WAN's. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1000) Provide SSL in zookeeper to be able to run cross colos.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15426727#comment-15426727 ] Jason Rosenberg commented on ZOOKEEPER-1000: We've been using this branch now in production for some time now, it's working well. I did have to extend it a bit with this PR: https://github.com/geek101/zookeeper/pull/1 which makes it a bit more generic in the configuration of the certs, etc. I'd love to see this upstreamed for 3.4.X (and eventually 3.5.X) > Provide SSL in zookeeper to be able to run cross colos. > --- > > Key: ZOOKEEPER-1000 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1000 > Project: ZooKeeper > Issue Type: Improvement >Reporter: Mahadev konar >Assignee: Mahadev konar > Fix For: 3.5.3, 3.6.0 > > > This jira is to track SSL for zookeeper. The inter zookeeper server > communication and the client to server communication should be over ssl so > that zookeeper can be deployed over WAN's. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2398) Config options should not be only available via system property
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15206424#comment-15206424 ] Jason Rosenberg commented on ZOOKEEPER-2398: Well, would be nice to have it sooner than later (but I'm working around it at the moment). > Config options should not be only available via system property > --- > > Key: ZOOKEEPER-2398 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2398 > Project: ZooKeeper > Issue Type: Improvement >Reporter: Jason Rosenberg >Priority: Minor > Fix For: 3.6.0, 3.5.3 > > > Some config options (such as enabling readonly mode) are only settable via a > system property. This feels clunky, and makes it less seamless for testing, > or for apps which embed a ZooKeeper inside a java container, etc. > I ran into this issue specifically in the case of creating unit tests to test > read-only mode client side behavior. In this case, I want to run multiple > QuorumPeer's in the same jvm, and have some of them enabled for read-only and > some not enabled. This is not possible with the current System.setProperty > approach. > In general, I question the need for using system properties for > configuration, since it makes embedding a server within a dependency > injection framework more difficult, and is in general less easy to integrate > into generic deployment systems. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2398) Config options should not be only available via system property
Jason Rosenberg created ZOOKEEPER-2398: -- Summary: Config options should not be only available via system property Key: ZOOKEEPER-2398 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2398 Project: ZooKeeper Issue Type: Bug Reporter: Jason Rosenberg Some config options (such as enabling readonly mode) are only settable via a system property. This feels clunky, and makes it less seamless for testing, or for apps which embed a ZooKeeper inside a java container, etc. I ran into this issue specifically in the case of creating unit tests to test read-only mode client side behavior. In this case, I want to run multiple QuorumPeer's in the same jvm, and have some of them enabled for read-only and some not enabled. This is not possible with the current System.setProperty approach. In general, I question the need for using system properties for configuration, since it makes embedding a server within a dependency injection framework more difficult, and is in general less easy to integrate into generic deployment systems. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2383) Startup race in ZooKeeperServer
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15206310#comment-15206310
]
Jason Rosenberg commented on ZOOKEEPER-2383:
Yes, agreed, you wouldn't use a FakeMBeanRegistry for tests that are actually
testing the jmx functionality!
However, I think it makes sense to have it be something easily
configurable/settable for most tests (and especially for tests which launch
multiple peers in the same jvm).
> Startup race in ZooKeeperServer
> ---
>
> Key: ZOOKEEPER-2383
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2383
> Project: ZooKeeper
> Issue Type: Bug
> Components: jmx, server
>Affects Versions: 3.4.8
>Reporter: Steve Rowe
>Priority: Blocker
> Fix For: 3.4.9
>
> Attachments: TestZkStandaloneJMXRegistrationRaceConcurrent.java,
> release-3.4.8-extra-logging.patch, zk-3.4.8-MBeanRegistry.log,
> zk-3.4.8-NPE.log
>
>
> In attempting to upgrade Solr's ZooKeeper dependency from 3.4.6 to 3.4.8
> (SOLR-8724) I ran into test failures where attempts to create a node in a
> newly started standalone ZooKeeperServer were failing because of an assertion
> in MBeanRegistry.
> ZooKeeperServer.startup() first sets up its request processor chain then
> registers itself in JMX, but if a connection comes in before the server's JMX
> registration happens, registration of the connection will fail because it
> trips the assertion that (effectively) its parent (the server) has already
> registered itself.
> {code:java|title=ZooKeeperServer.java}
> public synchronized void startup() {
> if (sessionTracker == null) {
> createSessionTracker();
> }
> startSessionTracker();
> setupRequestProcessors();
> registerJMX();
> state = State.RUNNING;
> notifyAll();
> }
> {code}
> {code:java|title=MBeanRegistry.java}
> public void register(ZKMBeanInfo bean, ZKMBeanInfo parent)
> throws JMException
> {
> assert bean != null;
> String path = null;
> if (parent != null) {
> path = mapBean2Path.get(parent);
> assert path != null;
> }
> {code}
> This problem appears to be new with ZK 3.4.8 - AFAIK Solr never had this
> issue with ZK 3.4.6.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2383) Startup race in ZooKeeperServer
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15198781#comment-15198781
]
Jason Rosenberg commented on ZOOKEEPER-2383:
I've run into similar issues, with the register call causing an AssertionError,
which is not caught anywhere, which results in test failures (especially if you
have multiple QuorumPeers running in the same jvm during tests). JMX
registration gets confused if you have individual nodes starting and stopping.
(Asserts are only enabled for us during testing/ci, so it doesn't affect
production).
I worked around it be calling {code}MBeanRegistry.setInstance(new
FakeMBeanRegistry()){code}. Where {code}FakeMBeanRegistry{code} looks like:
{code}
public static class FakeMBeanRegistry extends MBeanRegistry {
@Override public void register(ZKMBeanInfo bean, ZKMBeanInfo parent) throws
JMException {}
@Override public void unregister(ZKMBeanInfo bean) {}
@Override public void unregisterAll() {}
}
{code}
Maybe there should be a flag to disable all JMX registrations (e.g. for most
tests), and it could be handled with something like this fake class.
> Startup race in ZooKeeperServer
> ---
>
> Key: ZOOKEEPER-2383
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2383
> Project: ZooKeeper
> Issue Type: Bug
> Components: jmx, server
>Affects Versions: 3.4.8
>Reporter: Steve Rowe
>Priority: Blocker
> Fix For: 3.4.9
>
> Attachments: TestZkStandaloneJMXRegistrationRaceConcurrent.java,
> release-3.4.8-extra-logging.patch, zk-3.4.8-MBeanRegistry.log,
> zk-3.4.8-NPE.log
>
>
> In attempting to upgrade Solr's ZooKeeper dependency from 3.4.6 to 3.4.8
> (SOLR-8724) I ran into test failures where attempts to create a node in a
> newly started standalone ZooKeeperServer were failing because of an assertion
> in MBeanRegistry.
> ZooKeeperServer.startup() first sets up its request processor chain then
> registers itself in JMX, but if a connection comes in before the server's JMX
> registration happens, registration of the connection will fail because it
> trips the assertion that (effectively) its parent (the server) has already
> registered itself.
> {code:java|title=ZooKeeperServer.java}
> public synchronized void startup() {
> if (sessionTracker == null) {
> createSessionTracker();
> }
> startSessionTracker();
> setupRequestProcessors();
> registerJMX();
> state = State.RUNNING;
> notifyAll();
> }
> {code}
> {code:java|title=MBeanRegistry.java}
> public void register(ZKMBeanInfo bean, ZKMBeanInfo parent)
> throws JMException
> {
> assert bean != null;
> String path = null;
> if (parent != null) {
> path = mapBean2Path.get(parent);
> assert path != null;
> }
> {code}
> This problem appears to be new with ZK 3.4.8 - AFAIK Solr never had this
> issue with ZK 3.4.6.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2389) read-only observer doesn't load transaction log when transitioning to read-only
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Rosenberg updated ZOOKEEPER-2389: --- Description: I have rediscovered an issue, that was apparently posted a while back (link below). It seems that if I configure an Observer node to be enabled for read-only mode, with syncEnabled = true, it properly syncs its transaction log with the quorum. However, if I shut down the quorum participants, and the Observer automatically transitions to read-only mode, it does not load the saved transaction log, and thus rejects any client connection with a zxid > 0. But If I restart the Observer node, it reloads it's persisted transaction log and serves read-only requests at the latest zxid. Is this the correct behavior? Things run fine if instead of an observer, I do the same with a read-only participant. In this case, it transitions without issue to a read-only server, and serves the current transaction log. It seems to me this issue renders read-only observers completely useless. What am I missing here? I'm seeing this with 3.4.8 It seems this was discovered and reported a long time ago here: http://grokbase.com/t/zookeeper/user/14c16b1d22/issue-with-zxid-during-observer-failover-to-read-only was: I have rediscovered an issue, that was apparently posted a while back (link below). It seems that if I configure a Observer node to be enabled for read-only mode, with syncEnabled = true, it properly syncs its transaction log with the quorum. However, if I shut down the quorum participants, and the Observer automatically transitions to read-only mode, it does not load the saved transaction log, and thus rejects any client connection with a zxid > 0. But If I restart the Observer node, it reloads it's persisted transaction log and serves read-only requests at the latest zxid. Is this the correct behavior? Things run fine if instead of an observer, I do the same with a read-only participant. In this case, it transitions without issue to a read-only server, and serves the current transaction log. It seems to me this issue renders read-only observers completely useless. What am I missing here? I'm seeing this with 3.4.8 It seems this was discovered and reported a long time ago here: http://grokbase.com/t/zookeeper/user/14c16b1d22/issue-with-zxid-during-observer-failover-to-read-only > read-only observer doesn't load transaction log when transitioning to > read-only > --- > > Key: ZOOKEEPER-2389 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2389 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.8 >Reporter: Jason Rosenberg > > I have rediscovered an issue, that was apparently posted a while back (link > below). It seems that if I configure an Observer node to be enabled for > read-only mode, with syncEnabled = true, it properly syncs its transaction > log with the quorum. However, if I shut down the quorum participants, and > the Observer automatically transitions to read-only mode, it does not load > the saved transaction log, and thus rejects any client connection with a zxid > > 0. But If I restart the Observer node, it reloads it's persisted > transaction log and serves read-only requests at the latest zxid. Is this > the correct behavior? Things run fine if instead of an observer, I do the > same with a read-only participant. In this case, it transitions without > issue to a read-only server, and serves the current transaction log. > It seems to me this issue renders read-only observers completely useless. > What am I missing here? > I'm seeing this with 3.4.8 > It seems this was discovered and reported a long time ago here: > http://grokbase.com/t/zookeeper/user/14c16b1d22/issue-with-zxid-during-observer-failover-to-read-only -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2389) read-only observer doesn't load transaction log when transitioning to read-only
Jason Rosenberg created ZOOKEEPER-2389: -- Summary: read-only observer doesn't load transaction log when transitioning to read-only Key: ZOOKEEPER-2389 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2389 Project: ZooKeeper Issue Type: Bug Affects Versions: 3.4.8 Reporter: Jason Rosenberg I have rediscovered an issue, that was apparently posted a while back (link below). It seems that if I configure a Observer node to be enabled for read-only mode, with syncEnabled = true, it properly syncs its transaction log with the quorum. However, if I shut down the quorum participants, and the Observer automatically transitions to read-only mode, it does not load the saved transaction log, and thus rejects any client connection with a zxid > 0. But If I restart the Observer node, it reloads it's persisted transaction log and serves read-only requests at the latest zxid. Is this the correct behavior? Things run fine if instead of an observer, I do the same with a read-only participant. In this case, it transitions without issue to a read-only server, and serves the current transaction log. It seems to me this issue renders read-only observers completely useless. What am I missing here? I'm seeing this with 3.4.8 It seems this was discovered and reported a long time ago here: http://grokbase.com/t/zookeeper/user/14c16b1d22/issue-with-zxid-during-observer-failover-to-read-only -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-830) forrest docs for read-only mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134536#comment-15134536 ] Jason Rosenberg commented on ZOOKEEPER-830: --- Is there a reason this ticket has not been resolved? > forrest docs for read-only mode > --- > > Key: ZOOKEEPER-830 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-830 > Project: ZooKeeper > Issue Type: Sub-task >Reporter: Sergey Doroshenko >Assignee: Sergey Doroshenko > Attachments: ZOOKEEPER-830.patch, ZOOKEEPER-830.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1045) Quorum Peer mutual authentication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15097025#comment-15097025 ] Jason Rosenberg commented on ZOOKEEPER-1045: I think simple TLS/SSL is more important to have, and I expect significantly easier to implement and test, and to use operationally. A kerberos might be a nice to have feature (but should not be prioritized ahead of basic SSL, IMHO). > Quorum Peer mutual authentication > - > > Key: ZOOKEEPER-1045 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1045 > Project: ZooKeeper > Issue Type: New Feature > Components: server >Reporter: Eugene Koontz >Assignee: Rakesh R > Attachments: ZOOKEEPER-1045-00.patch, ZOOKEEPER-1045-Rolling Upgrade > Design Proposal.pdf > > > ZOOKEEPER-938 addresses mutual authentication between clients and servers. > This bug, on the other hand, is for authentication among quorum peers. > Hopefully much of the work done on SASL integration with Zookeeper for > ZOOKEEPER-938 can be used as a foundation for this enhancement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2347) Deadlock shutting down zookeeper
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15063076#comment-15063076
]
Jason Rosenberg commented on ZOOKEEPER-2347:
What are the conditions that trigger this issue? We've been running with 3.4.7
and so far have not seen any dead-locks with routine server shutdowns, or with
tests. Trying to judge whether we should revert or not.
> Deadlock shutting down zookeeper
>
>
> Key: ZOOKEEPER-2347
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2347
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.7
>Reporter: Ted Yu
>Assignee: Rakesh R
>Priority: Blocker
> Fix For: 3.4.8
>
> Attachments: ZOOKEEPER-2347-br-3.4.patch, testSplitLogManager.stack
>
>
> HBase recently upgraded to zookeeper 3.4.7
> In one of the tests, TestSplitLogManager, there is reproducible hang at the
> end of the test.
> Below is snippet from stack trace related to zookeeper:
> {code}
> "main-EventThread" daemon prio=5 tid=0x7fd27488a800 nid=0x6f1f waiting on
> condition [0x00011834b000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007c5b8d3a0> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501)
> "main-SendThread(localhost:59510)" daemon prio=5 tid=0x7fd274eb4000
> nid=0x9513 waiting on condition [0x000118042000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:101)
> at
> org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:997)
> at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1060)
> "SyncThread:0" prio=5 tid=0x7fd274d02000 nid=0x730f waiting for monitor
> entry [0x0001170ac000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.zookeeper.server.ZooKeeperServer.decInProcess(ZooKeeperServer.java:512)
> - waiting to lock <0x0007c5b62128> (a
> org.apache.zookeeper.server.ZooKeeperServer)
> at
> org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:144)
> at
> org.apache.zookeeper.server.SyncRequestProcessor.flush(SyncRequestProcessor.java:200)
> at
> org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:131)
> "main-EventThread" daemon prio=5 tid=0x7fd2753a3800 nid=0x711b waiting on
> condition [0x000117a3]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007c9b106b8> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501)
> "main" prio=5 tid=0x7fd27600 nid=0x1903 in Object.wait()
> [0x000108aa1000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x0007c5b66400> (a
> org.apache.zookeeper.server.SyncRequestProcessor)
> at java.lang.Thread.join(Thread.java:1281)
> - locked <0x0007c5b66400> (a
> org.apache.zookeeper.server.SyncRequestProcessor)
> at java.lang.Thread.join(Thread.java:1355)
> at
> org.apache.zookeeper.server.SyncRequestProcessor.shutdown(SyncRequestProcessor.java:213)
> at
> org.apache.zookeeper.server.PrepRequestProcessor.shutdown(PrepRequestProcessor.java:770)
> at
> org.apache.zookeeper.server.ZooKeeperServer.shutdown(ZooKeeperServer.java:478)
> - locked <0x0007c5b62128> (a
> org.apache.zookeeper.server.ZooKeeperServer)
> at
> org.apache.zookeeper.server.NIOServerCnxnFactory.shutdown(NIOServerCnxnFactory.java:266)
> at
> org.apache.hadoop.hbase.zookeeper.MiniZooKeeperCluster.shutdown(MiniZooKeeperCluster.java:301)
> {code}
> Note the address (0x0007c5b66400) in the last hunk which seems to
> indicate some form of deadlock.
> According to Camille Fournier:
> We made shutdown synchronized. But decrementing the requests is
> also synchronized and called from a different thread. So yeah,
[jira] [Commented] (ZOOKEEPER-235) SSL Support for clients
[ https://issues.apache.org/jira/browse/ZOOKEEPER-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15049076#comment-15049076 ] Jason Rosenberg commented on ZOOKEEPER-235: --- Is this still an issue, now that client-server ssl is now supported (over netty) in 3.5.1-alpha? > SSL Support for clients > --- > > Key: ZOOKEEPER-235 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-235 > Project: ZooKeeper > Issue Type: New Feature > Components: c client, java client, server >Reporter: Benjamin Reed >Priority: Minor > > ZooKeeper should be able to support SSL for ZooKeeper clients. As part of the > implementation we should also add an X509AuthenticationProvider so that > client side certifications can be used for authentication. > The tricky part of the implementation will be integrating with the > non-blocking NIO calls that we use. There are various web pages that describe > how to do it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1045) Quorum Peer mutual authentication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15045241#comment-15045241 ] Jason Rosenberg commented on ZOOKEEPER-1045: Mutual SSL support, seems simpler (if I'm not mistaken), and is adequate for the basic blocker we have, of wanting to have a cluster with nodes spanning multiple datacenters (e.g. with remote observer nodes, etc.). SASL is probably overkill for that. > Quorum Peer mutual authentication > - > > Key: ZOOKEEPER-1045 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1045 > Project: ZooKeeper > Issue Type: New Feature > Components: server >Reporter: Eugene Koontz > > ZOOKEEPER-938 addresses mutual authentication between clients and servers. > This bug, on the other hand, is for authentication among quorum peers. > Hopefully much of the work done on SASL integration with Zookeeper for > ZOOKEEPER-938 can be used as a foundation for this enhancement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1000) Provide SSL in zookeeper to be able to run cross colos.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15044371#comment-15044371 ] Jason Rosenberg commented on ZOOKEEPER-1000: [~hdeng] Wondering if you are still working on this, what the time frame might be? If not, is there some work in progress that another could take up and work on? > Provide SSL in zookeeper to be able to run cross colos. > --- > > Key: ZOOKEEPER-1000 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1000 > Project: ZooKeeper > Issue Type: Improvement >Reporter: Mahadev konar >Assignee: Mahadev konar > Fix For: 3.5.2, 3.6.0 > > > This jira is to track SSL for zookeeper. The inter zookeeper server > communication and the client to server communication should be over ssl so > that zookeeper can be deployed over WAN's. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1045) Quorum Peer mutual authentication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15044375#comment-15044375 ] Jason Rosenberg commented on ZOOKEEPER-1045: How does this ticket compare to ZOOKEEPER-1000? Do they solve different problems? Or alternate solutions to the same problem? > Quorum Peer mutual authentication > - > > Key: ZOOKEEPER-1045 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1045 > Project: ZooKeeper > Issue Type: New Feature > Components: server >Reporter: Eugene Koontz > > ZOOKEEPER-938 addresses mutual authentication between clients and servers. > This bug, on the other hand, is for authentication among quorum peers. > Hopefully much of the work done on SASL integration with Zookeeper for > ZOOKEEPER-938 can be used as a foundation for this enhancement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
