[jira] [Updated] (ZOOKEEPER-4051) Leader did not lose the quorum when a node left the quorum of 3 out of 5 nodes.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Badai Aqrandista updated ZOOKEEPER-4051:
Description:
This Zookeeper ensemble has 5 nodes: node 1, 2, 3, 4 and 5. At the time, leader
was node 4. The quorum consisted of node 3, 4 and 5. Node 1 and 2 kept
disconnecting from node 4, so they never joined the quorum.
At 2020-12-08 14:10:23, lost its quorum. But this only occurred after node 3
disconnected from node 4 multiple times. The disconnection message from node 3
had occurred more for more than 12 hours prior to this (but no logs prior to
that). But the quorum was not lost. Following is form node 4. It shows that
when the quorum was lost, there were only 2 nodes left in the quorum: node 4
and 5.
Note that all IP addresses are replaced with 0.0.0.0 to allow it to be included
in this bug report.
{noformat}
[2020-12-08 14:10:20,702] INFO Notification: 2 (message format version), 2
(n.leader), 0x5033 (n.zxid), 0x3c (n.round), LOOKING (n.state), 2
(n.sid), 0x5033 (n.peerEPoch), LEADING (my state)0 (n.config version)
(org.apache.zookeeper.server.quorum.FastLeaderElection)
[2020-12-08 14:10:20,918] INFO Notification: 2 (message format version), 2
(n.leader), 0x5033 (n.zxid), 0x3c (n.round), LOOKING (n.state), 2
(n.sid), 0x5033 (n.peerEPoch), LEADING (my state)0 (n.config version)
(org.apache.zookeeper.server.quorum.FastLeaderElection)
[2020-12-08 14:10:21,045] INFO Received connection request 0.0.0.0:41966
(org.apache.zookeeper.server.quorum.QuorumCnxManager)
[2020-12-08 14:10:21,056] INFO Notification: 2 (message format version), 2
(n.leader), 0x5033 (n.zxid), 0x3d (n.round), LOOKING (n.state), 2
(n.sid), 0x5033 (n.peerEPoch), LEADING (my state)0 (n.config version)
(org.apache.zookeeper.server.quorum.FastLeaderElection)
[2020-12-08 14:10:21,193] INFO Notification: 2 (message format version), 1
(n.leader), 0x42040004 (n.zxid), 0x3d (n.round), LOOKING (n.state), 1
(n.sid), 0x5033 (n.peerEPoch), LEADING (my state)0 (n.config version)
(org.apache.zookeeper.server.quorum.FastLeaderElection)
[2020-12-08 14:10:21,193] INFO Notification: 2 (message format version), 1
(n.leader), 0x42040004 (n.zxid), 0x3d (n.round), LOOKING (n.state), 1
(n.sid), 0x5033 (n.peerEPoch), LEADING (my state)0 (n.config version)
(org.apache.zookeeper.server.quorum.FastLeaderElection)
[2020-12-08 14:10:21,204] INFO Notification: 2 (message format version), 2
(n.leader), 0x5033 (n.zxid), 0x3d (n.round), LOOKING (n.state), 1
(n.sid), 0x5033 (n.peerEPoch), LEADING (my state)0 (n.config version)
(org.apache.zookeeper.server.quorum.FastLeaderElection)
[2020-12-08 14:10:22,180] INFO Received connection request 0.0.0.0:41970
(org.apache.zookeeper.server.quorum.QuorumCnxManager)
[2020-12-08 14:10:22,181] WARN Connection broken for id 3, my id = 4, error =
(org.apache.zookeeper.server.quorum.QuorumCnxManager)
java.net.SocketException: Socket closed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at
org.apache.zookeeper.server.quorum.QuorumCnxManager$RecvWorker.run(QuorumCnxManager.java:1212)
[2020-12-08 14:10:22,181] WARN Interrupting SendWorker
(org.apache.zookeeper.server.quorum.QuorumCnxManager)
[2020-12-08 14:10:22,182] ERROR Failed to send last message. Shutting down
thread. (org.apache.zookeeper.server.quorum.QuorumCnxManager)
java.net.SocketException: Socket closed
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:118)
at java.net.SocketOutputStream.write(SocketOutputStream.java:134)
at java.io.DataOutputStream.writeInt(DataOutputStream.java:197)
at
org.apache.zookeeper.server.quorum.QuorumCnxManager$SendWorker.send(QuorumCnxManager.java:1088)
at
org.apache.zookeeper.server.quorum.QuorumCnxManager$SendWorker.run(QuorumCnxManager.java:1115)
[2020-12-08 14:10:22,182] WARN Send worker leaving thread id 3 my id = 4
(org.apache.zookeeper.server.quorum.QuorumCnxManager)
[2020-12-08 14:10:22,402] INFO Received connection request 0.0.0.0:41974
(org.apache.zookeeper.server.quorum.QuorumCnxManager)
[2020-12-08 14:10:22,403] ERROR Failed to send last message. Shutting down
thread. (org.apache.zookeeper.server.quorum.QuorumCnxManager)
java.net.SocketException: Socket closed
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:118)
at java.net.SocketOutputStream.write(SocketOutputStream.java:134)
[jira] [Created] (ZOOKEEPER-4051) Leader did not lose the quorum when a node left the quorum of 3 out of 5 nodes.
Badai Aqrandista created ZOOKEEPER-4051:
---
Summary: Leader did not lose the quorum when a node left the
quorum of 3 out of 5 nodes.
Key: ZOOKEEPER-4051
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4051
Project: ZooKeeper
Issue Type: Bug
Affects Versions: 3.5.7
Reporter: Badai Aqrandista
This Zookeeper ensemble has 5 nodes: node 1, 2, 3, 4 and 5. At the time, leader
was node 4. The quorum consisted of node 3, 4 and 5. Node 1 and 2 kept
disconnecting from node 4, so they never joined the quorum.
At 2020-12-08 14:10:23, lost its quorum. But this only occurred after node 3
disconnected from node 4 multiple times. The disconnection message from node 3
had occurred more for more than 12 hours prior to this (but no logs prior to
that). But the quorum was not lost. Following is form node 4. It shows that
when the quorum was lost, there were only 2 nodes left in the quorum: node 4
and 5.
{noformat}
[2020-12-08 14:10:20,702] INFO Notification: 2 (message format version), 2
(n.leader), 0x5033 (n.zxid), 0x3c (n.round), LOOKING (n.state), 2
(n.sid), 0x5033 (n.peerEPoch), LEADING (my state)0 (n.config version)
(org.apache.zookeeper.server.quorum.FastLeaderElection)
[2020-12-08 14:10:20,918] INFO Notification: 2 (message format version), 2
(n.leader), 0x5033 (n.zxid), 0x3c (n.round), LOOKING (n.state), 2
(n.sid), 0x5033 (n.peerEPoch), LEADING (my state)0 (n.config version)
(org.apache.zookeeper.server.quorum.FastLeaderElection)
[2020-12-08 14:10:21,045] INFO Received connection request 0.0.0.0:41966
(org.apache.zookeeper.server.quorum.QuorumCnxManager)
[2020-12-08 14:10:21,056] INFO Notification: 2 (message format version), 2
(n.leader), 0x5033 (n.zxid), 0x3d (n.round), LOOKING (n.state), 2
(n.sid), 0x5033 (n.peerEPoch), LEADING (my state)0 (n.config version)
(org.apache.zookeeper.server.quorum.FastLeaderElection)
[2020-12-08 14:10:21,193] INFO Notification: 2 (message format version), 1
(n.leader), 0x42040004 (n.zxid), 0x3d (n.round), LOOKING (n.state), 1
(n.sid), 0x5033 (n.peerEPoch), LEADING (my state)0 (n.config version)
(org.apache.zookeeper.server.quorum.FastLeaderElection)
[2020-12-08 14:10:21,193] INFO Notification: 2 (message format version), 1
(n.leader), 0x42040004 (n.zxid), 0x3d (n.round), LOOKING (n.state), 1
(n.sid), 0x5033 (n.peerEPoch), LEADING (my state)0 (n.config version)
(org.apache.zookeeper.server.quorum.FastLeaderElection)
[2020-12-08 14:10:21,204] INFO Notification: 2 (message format version), 2
(n.leader), 0x5033 (n.zxid), 0x3d (n.round), LOOKING (n.state), 1
(n.sid), 0x5033 (n.peerEPoch), LEADING (my state)0 (n.config version)
(org.apache.zookeeper.server.quorum.FastLeaderElection)
[2020-12-08 14:10:22,180] INFO Received connection request 0.0.0.0:41970
(org.apache.zookeeper.server.quorum.QuorumCnxManager)
[2020-12-08 14:10:22,181] WARN Connection broken for id 3, my id = 4, error =
(org.apache.zookeeper.server.quorum.QuorumCnxManager)
java.net.SocketException: Socket closed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at
org.apache.zookeeper.server.quorum.QuorumCnxManager$RecvWorker.run(QuorumCnxManager.java:1212)
[2020-12-08 14:10:22,181] WARN Interrupting SendWorker
(org.apache.zookeeper.server.quorum.QuorumCnxManager)
[2020-12-08 14:10:22,182] ERROR Failed to send last message. Shutting down
thread. (org.apache.zookeeper.server.quorum.QuorumCnxManager)
java.net.SocketException: Socket closed
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:118)
at java.net.SocketOutputStream.write(SocketOutputStream.java:134)
at java.io.DataOutputStream.writeInt(DataOutputStream.java:197)
at
org.apache.zookeeper.server.quorum.QuorumCnxManager$SendWorker.send(QuorumCnxManager.java:1088)
at
org.apache.zookeeper.server.quorum.QuorumCnxManager$SendWorker.run(QuorumCnxManager.java:1115)
[2020-12-08 14:10:22,182] WARN Send worker leaving thread id 3 my id = 4
(org.apache.zookeeper.server.quorum.QuorumCnxManager)
[2020-12-08 14:10:22,402] INFO Received connection request 0.0.0.0:41974
(org.apache.zookeeper.server.quorum.QuorumCnxManager)
[2020-12-08 14:10:22,403] ERROR Failed to send last message. Shutting down
thread. (org.apache.zookeeper.server.quorum.QuorumCnxManager)
java.net.SocketException: Socket closed
at
[jira] [Commented] (ZOOKEEPER-4050) Zookeeper Inspector reports "List of default node viewers is empty" when not specifically run from the zookeeper-contrib/zookeeper-contrib-zooinspector directory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260844#comment-17260844 ] Damien Diederen commented on ZOOKEEPER-4050: [~brentwritescode]: Thank you for taking care of the ticket! > Zookeeper Inspector reports "List of default node viewers is empty" when not > specifically run from the zookeeper-contrib/zookeeper-contrib-zooinspector > directory > - > > Key: ZOOKEEPER-4050 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4050 > Project: ZooKeeper > Issue Type: Bug > Components: contrib >Affects Versions: 3.7.0 >Reporter: Brent >Priority: Major > > This is a follow-up to the issue ZOOKEEPER-3943 and the discussion on > [https://github.com/apache/zookeeper/pull/1551]. PR 1551 fixes the location > issue for all of the various Icons used by the UI, but does not address a > similar issue with the defaultNodeViewers.cfg and > defaultConnectionSettings.cfg files (as pointed out in the PR comments). > As a result, if one builds a "Fat JAR" of the Zookeeper Inspector application > and then moves it to a different directory, this error appears when > inspecting a node at runtime: > WARN [main] (ZooInspectorManagerImpl.java:851) - List of default node viewers > is empty" > And the node viewer window cannot populate correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (ZOOKEEPER-3426) ZK prime_connection(the Handshake) can complete without reading all the payload.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damien Diederen reassigned ZOOKEEPER-3426:
--
Assignee: Damien Diederen
Hi [~suhas.dantkale],
That is a nasty one, indeed. Have you actually experienced the problem, or did
you just spot it in the code? In any case, I agree with your analysis.
I have a proposed fix, but I still have to figure out how to include tests. (I
will submit a "pull request" once I am done.) In the meantime, here is a sneak
peek:
{code:c}
rc = zookeeper_recv(zh->fd, buff->buffer+off, buff->len-off, 0);
/* dirty hack to make new client work against old server
* old server sends 40 bytes to finish connection handshake,
* while we're expecting 41 (1 byte for read-only mode data) */
if (rc > 0 && buff == >primer_buffer) {
/* primer_buffer's curr_offset starts at 4 (see prime_connection) */
int avail = buff->curr_offset - sizeof(buff->len) + rc;
/* exactly 40 bytes (out of 41 expected) collected? */
if (avail == buff->len - 1) {
int32_t reply_len;
/* extract length of ConnectResponse (+ 1-byte flag?) */
memcpy(_len, buff->buffer, sizeof(reply_len));
reply_len = ntohl(reply_len);
/* if 1-byte flag was not sent, fake it (value 0) */
if ((int)(reply_len + sizeof(reply_len)) == buff->len - 1) {
++rc;
}
}
}
{code}
The gist of it is:
# We look at how much data has accumulated in the buffer (as opposed to
checking {{rc}});
# If the amount is sufficient, we look at the encoded {{length}} at offset 0.
Comments welcome!
> ZK prime_connection(the Handshake) can complete without reading all the
> payload.
>
>
> Key: ZOOKEEPER-3426
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3426
> Project: ZooKeeper
> Issue Type: Bug
> Components: c client
>Reporter: Suhas Dantkale
>Assignee: Damien Diederen
>Priority: Blocker
>
> /* returns:
> * -1 if recv call failed,
> * 0 if recv would block,
> * 1 if success
> */
> static int recv_buffer(zhandle_t *zh, buffer_list_t *buff)
> {
> int off = buff->curr_offset;
> int rc = 0;
> []
> if (buff == >primer_buffer && rc == buff->len - 1) ++rc; <==
> Handshake prematurely complete.
> On non-blocking socket, it's possible that socket has exactly "buff->len - 1"
> bytes to read.
> Because of the above line, the Handshake is prematurely completed.
> What this can lead to is:
> There will be one outstanding byte left on the socket and it might go as part
> of next message which could get corrupted.
> I think this can lead to ZRUNTIMEINCONSISTENCY issues later.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-4050) Zookeeper Inspector reports "List of default node viewers is empty" when not specifically run from the zookeeper-contrib/zookeeper-contrib-zooinspector directory
Brent created ZOOKEEPER-4050: Summary: Zookeeper Inspector reports "List of default node viewers is empty" when not specifically run from the zookeeper-contrib/zookeeper-contrib-zooinspector directory Key: ZOOKEEPER-4050 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4050 Project: ZooKeeper Issue Type: Bug Components: contrib Affects Versions: 3.7.0 Reporter: Brent This is a follow-up to the issue ZOOKEEPER-3943 and the discussion on [https://github.com/apache/zookeeper/pull/1551]. PR 1551 fixes the location issue for all of the various Icons used by the UI, but does not address a similar issue with the defaultNodeViewers.cfg and defaultConnectionSettings.cfg files (as pointed out in the PR comments). As a result, if one builds a "Fat JAR" of the Zookeeper Inspector application and then moves it to a different directory, this error appears when inspecting a node at runtime: WARN [main] (ZooInspectorManagerImpl.java:851) - List of default node viewers is empty" And the node viewer window cannot populate correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (ZOOKEEPER-3577) SSL support in ZooKeeper Dynamic Reconfiguration
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260521#comment-17260521
]
Mate Szalay-Beko edited comment on ZOOKEEPER-3577 at 1/7/21, 2:11 PM:
--
So as far as I understood, ZooKeeper Dynamic Reconfiguration currently doesn't
support ssl. It distributes the client port, but not the secure client port. An
example line from the configuration:
{code}
server.1=125.23.63.23:2780:2783:participant;2791
{code}
in this example, \{{2791}} is an un-secure (non-ssl) client port. So if any
client gets notification about configuration changes (e.g about a new quorum
member), then it won't be able to find out what SSL port to use.
The configuration format could be extended with the secure client ports, like:
{code}
server.1=125.23.63.23:2780:2783:participant;2791_2792ssl
{code}
Or something like this... It is important to note that in secure clusters it is
possible that we don't have any unsecure port open and only using secure port.
And also we can choose to have both unsecure and secure ports open in parallel.
(It is even possible to use the same port as secure and unsecure, if port
unification is enabled)
The tricky thing with changing the config syntax is backward and forward
compatibility during rolling upgrades. Maybe easier would be to simply add the
(currently static) secureClientPort configuration parameter to the dynamic
configuration parameters. So it would be distributed among the "server" and
"version" configurations.
Also this change would require the changing of the \{{EnsambleTracker}} class
in Curator.
ps. FYI [~eolivelli] : this ticket has Curator implications... Am I right that
the ZooKeeper dynamic reconfig doesn't work now with Curator on SSL-only
clusters?
was (Author: symat):
FYI [~eolivelli] : this ticket has Curator implications... Am I right that the
ZooKeeper dynamic reconfig doesn't work now with Curator on SSL-only clusters?
> SSL support in ZooKeeper Dynamic Reconfiguration
>
>
> Key: ZOOKEEPER-3577
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3577
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.5, 3.5.8, 3.6.2
>Reporter: zhaoyan
>Priority: Minor
>
> ZooKeeper Dynamic Reconfiguration is not support ssl
>
> {{server.1=125.23.63.23:2780:2783:participant;2791}}
>
> {{2791}} is must plaintext port， it not support ssl port
>
> reason:
> org.apache.zookeeper.server.quorum.QuorumPeerConfig#setupClientPort
> {{only {color:#9876aa}clientAddr{color}:}}
> {color:#cc7832}if {color}(qs != {color:#cc7832}null {color}&&
> qs.{color:#9876aa}clientAddr {color}!= {color:#cc7832}null{color})
> {color:#9876aa}clientPortAddress {color}=
> qs.{color:#9876aa}clientAddr{color}{color:#cc7832};{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3577) SSL support in ZooKeeper Dynamic Reconfiguration
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mate Szalay-Beko updated ZOOKEEPER-3577:
Description:
(note: the original description
ZooKeeper Dynamic Reconfiguration currently doesn't support ssl. It distributes
the client port, but not the secure client port. An example line from the
configuration:
{code}
server.1=125.23.63.23:2780:2783:participant;2791
{code}
in this example, {{2791}} is an un-secure (non-ssl) client port. So if any
client gets notification about configuration changes (e.g about a new quorum
member), then it won't be able to find out what SSL port to use.
The configuration format could be extended with the secure client ports, like:
{code}
server.1=125.23.63.23:2780:2783:participant;2791_2792ssl
{code}
Or something like this... It is important to note that in secure clusters it is
possible that we don't have any unsecure port open and only using secure port.
And also we can choose to have both unsecure and secure ports open in parallel.
(It is even possible to use the same port as secure and unsecure, if port
unification is enabled)
The tricky thing with changing the config syntax is backward and forward
compatibility during rolling upgrades. Maybe easier would be to simply add the
(currently static) secureClientPort configuration parameter to the dynamic
configuration parameters. So it would be distributed among the "server" and
"version" configurations.
Also this change would require the changing of the {{EnsambleTracker}} class in
Curator.
was:
ZooKeeper Dynamic Reconfiguration currently doesn't support ssl. It distributes
the client port, but not the secure client port. An example line from the
configuration:
{code}
server.1=125.23.63.23:2780:2783:participant;2791
{code}
in this example, {{2791}} is an un-secure (non-ssl) client port. So if any
client gets notification about configuration changes (e.g about a new quorum
member), then it won't be able to find out what SSL port to use.
The configuration format could be extended with the secure client ports, like:
{code}
server.1=125.23.63.23:2780:2783:participant;2791_2792ssl
{code}
Or something like this... It is important to note that in secure clusters it is
possible that we don't have any unsecure port open and only using secure port.
And also we can choose to have both unsecure and secure ports open in parallel.
(It is even possible to use the same port as secure and unsecure, if port
unification is enabled)
The tricky thing with changing the config syntax is backward and forward
compatibility during rolling upgrades. Maybe easier would be to simply add the
(currently static) secureClientPort configuration parameter to the dynamic
configuration parameters. So it would be distributed among the "server" and
"version" configurations.
Also this change would require the changing of the {{EnsambleTracker}} class in
Curator.
> SSL support in ZooKeeper Dynamic Reconfiguration
>
>
> Key: ZOOKEEPER-3577
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3577
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.5, 3.5.8, 3.6.2
>Reporter: zhaoyan
>Priority: Minor
>
> (note: the original description
> ZooKeeper Dynamic Reconfiguration currently doesn't support ssl. It
> distributes the client port, but not the secure client port. An example line
> from the configuration:
> {code}
> server.1=125.23.63.23:2780:2783:participant;2791
> {code}
> in this example, {{2791}} is an un-secure (non-ssl) client port. So if any
> client gets notification about configuration changes (e.g about a new quorum
> member), then it won't be able to find out what SSL port to use.
> The configuration format could be extended with the secure client ports, like:
> {code}
> server.1=125.23.63.23:2780:2783:participant;2791_2792ssl
> {code}
> Or something like this... It is important to note that in secure clusters it
> is possible that we don't have any unsecure port open and only using secure
> port. And also we can choose to have both unsecure and secure ports open in
> parallel. (It is even possible to use the same port as secure and unsecure,
> if port unification is enabled)
> The tricky thing with changing the config syntax is backward and forward
> compatibility during rolling upgrades. Maybe easier would be to simply add
> the (currently static) secureClientPort configuration parameter to the
> dynamic configuration parameters. So it would be distributed among the
> "server" and "version" configurations.
> Also this change would require the changing of the {{EnsambleTracker}} class
> in Curator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3577) SSL support in ZooKeeper Dynamic Reconfiguration
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mate Szalay-Beko updated ZOOKEEPER-3577:
Description:
ZooKeeper Dynamic Reconfiguration is not support ssl
{{server.1=125.23.63.23:2780:2783:participant;2791}}
{{2791}} is must plaintext port， it not support ssl port
reason:
org.apache.zookeeper.server.quorum.QuorumPeerConfig#setupClientPort
{{only {color:#9876aa}clientAddr{color}:}}
{color:#cc7832}if {color}(qs != {color:#cc7832}null {color}&&
qs.{color:#9876aa}clientAddr {color}!= {color:#cc7832}null{color})
{color:#9876aa}clientPortAddress {color}=
qs.{color:#9876aa}clientAddr{color}{color:#cc7832};{color}
was:
(note: the original description
ZooKeeper Dynamic Reconfiguration currently doesn't support ssl. It distributes
the client port, but not the secure client port. An example line from the
configuration:
{code}
server.1=125.23.63.23:2780:2783:participant;2791
{code}
in this example, {{2791}} is an un-secure (non-ssl) client port. So if any
client gets notification about configuration changes (e.g about a new quorum
member), then it won't be able to find out what SSL port to use.
The configuration format could be extended with the secure client ports, like:
{code}
server.1=125.23.63.23:2780:2783:participant;2791_2792ssl
{code}
Or something like this... It is important to note that in secure clusters it is
possible that we don't have any unsecure port open and only using secure port.
And also we can choose to have both unsecure and secure ports open in parallel.
(It is even possible to use the same port as secure and unsecure, if port
unification is enabled)
The tricky thing with changing the config syntax is backward and forward
compatibility during rolling upgrades. Maybe easier would be to simply add the
(currently static) secureClientPort configuration parameter to the dynamic
configuration parameters. So it would be distributed among the "server" and
"version" configurations.
Also this change would require the changing of the {{EnsambleTracker}} class in
Curator.
> SSL support in ZooKeeper Dynamic Reconfiguration
>
>
> Key: ZOOKEEPER-3577
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3577
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.5, 3.5.8, 3.6.2
>Reporter: zhaoyan
>Priority: Minor
>
> ZooKeeper Dynamic Reconfiguration is not support ssl
>
> {{server.1=125.23.63.23:2780:2783:participant;2791}}
>
> {{2791}} is must plaintext port， it not support ssl port
>
> reason:
> org.apache.zookeeper.server.quorum.QuorumPeerConfig#setupClientPort
> {{only {color:#9876aa}clientAddr{color}:}}
> {color:#cc7832}if {color}(qs != {color:#cc7832}null {color}&&
> qs.{color:#9876aa}clientAddr {color}!= {color:#cc7832}null{color})
> {color:#9876aa}clientPortAddress {color}=
> qs.{color:#9876aa}clientAddr{color}{color:#cc7832};{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3577) SSL support in ZooKeeper Dynamic Reconfiguration
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mate Szalay-Beko updated ZOOKEEPER-3577:
Description:
ZooKeeper Dynamic Reconfiguration currently doesn't support ssl. It distributes
the client port, but not the secure client port. An example line from the
configuration:
{code}
server.1=125.23.63.23:2780:2783:participant;2791
{code}
in this example, {{2791}} is an un-secure (non-ssl) client port. So if any
client gets notification about configuration changes (e.g about a new quorum
member), then it won't be able to find out what SSL port to use.
The configuration format could be extended with the secure client ports, like:
{code}
server.1=125.23.63.23:2780:2783:participant;2791_2792ssl
{code}
Or something like this... It is important to note that in secure clusters it is
possible that we don't have any unsecure port open and only using secure port.
And also we can choose to have both unsecure and secure ports open in parallel.
(It is even possible to use the same port as secure and unsecure, if port
unification is enabled)
The tricky thing with changing the config syntax is backward and forward
compatibility during rolling upgrades. Maybe easier would be to simply add the
(currently static) secureClientPort configuration parameter to the dynamic
configuration parameters. So it would be distributed among the "server" and
"version" configurations.
Also this change would require the changing of the {{EnsambleTracker}} class in
Curator.
was:
ZooKeeper Dynamic Reconfiguration currently doesn't support ssl. It distributes
the client port, but not the secure client port. An example line from the
configuration:
{code}
server.1=125.23.63.23:2780:2783:participant;2791
{code}
in this example, {{2791}} is an un-secure (non-ssl) client port. So if any
client gets notification about configuration changes (e.g about a new quorum
member), then it won't be able to find out what SSL port to use.
The configuration format should could be extended with the secure client ports,
like:
{code}
server.1=125.23.63.23:2780:2783:participant;2791_2792ssl
{code}
Or something like this... It is important to note that in secure clusters it is
possible that we don't have any unsecure port open and only using secure port.
The tricky thing with changing the config syntax is backward and forward
compatibility during rolling upgrades. Maybe easier would be to simply add the
(currently static) secureClientPort configuration parameter to the dynamic
configuration parameters. So it would be distributed among the "server" and
"version" configurations.
Also this change would require the changing of the {{EnsambleTracker}} class in
Curator.
> SSL support in ZooKeeper Dynamic Reconfiguration
>
>
> Key: ZOOKEEPER-3577
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3577
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.5, 3.5.8, 3.6.2
>Reporter: zhaoyan
>Priority: Minor
>
> ZooKeeper Dynamic Reconfiguration currently doesn't support ssl. It
> distributes the client port, but not the secure client port. An example line
> from the configuration:
> {code}
> server.1=125.23.63.23:2780:2783:participant;2791
> {code}
> in this example, {{2791}} is an un-secure (non-ssl) client port. So if any
> client gets notification about configuration changes (e.g about a new quorum
> member), then it won't be able to find out what SSL port to use.
> The configuration format could be extended with the secure client ports, like:
> {code}
> server.1=125.23.63.23:2780:2783:participant;2791_2792ssl
> {code}
> Or something like this... It is important to note that in secure clusters it
> is possible that we don't have any unsecure port open and only using secure
> port. And also we can choose to have both unsecure and secure ports open in
> parallel. (It is even possible to use the same port as secure and unsecure,
> if port unification is enabled)
> The tricky thing with changing the config syntax is backward and forward
> compatibility during rolling upgrades. Maybe easier would be to simply add
> the (currently static) secureClientPort configuration parameter to the
> dynamic configuration parameters. So it would be distributed among the
> "server" and "version" configurations.
> Also this change would require the changing of the {{EnsambleTracker}} class
> in Curator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3577) SSL support in ZooKeeper Dynamic Reconfiguration
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mate Szalay-Beko updated ZOOKEEPER-3577:
Issue Type: Improvement (was: Bug)
> SSL support in ZooKeeper Dynamic Reconfiguration
>
>
> Key: ZOOKEEPER-3577
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3577
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.5
>Reporter: zhaoyan
>Priority: Minor
>
> ZooKeeper Dynamic Reconfiguration currently doesn't support ssl. It
> distributes the client port, but not the secure client port. An example line
> from the configuration:
> {code}
> server.1=125.23.63.23:2780:2783:participant;2791
> {code}
> in this example, {{2791}} is an un-secure (non-ssl) client port. So if any
> client gets notification about configuration changes (e.g about a new quorum
> member), then it won't be able to find out what SSL port to use.
> The configuration format should could be extended with the secure client
> ports, like:
> {code}
> server.1=125.23.63.23:2780:2783:participant;2791_2792ssl
> {code}
> Or something like this... It is important to note that in secure clusters it
> is possible that we don't have any unsecure port open and only using secure
> port.
> The tricky thing with changing the config syntax is backward and forward
> compatibility during rolling upgrades. Maybe easier would be to simply add
> the (currently static) secureClientPort configuration parameter to the
> dynamic configuration parameters. So it would be distributed among the
> "server" and "version" configurations.
> Also this change would require the changing of the {{EnsambleTracker}} class
> in Curator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3577) SSL support in ZooKeeper Dynamic Reconfiguration
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mate Szalay-Beko updated ZOOKEEPER-3577:
Affects Version/s: 3.5.8
3.6.2
> SSL support in ZooKeeper Dynamic Reconfiguration
>
>
> Key: ZOOKEEPER-3577
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3577
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.5, 3.5.8, 3.6.2
>Reporter: zhaoyan
>Priority: Minor
>
> ZooKeeper Dynamic Reconfiguration currently doesn't support ssl. It
> distributes the client port, but not the secure client port. An example line
> from the configuration:
> {code}
> server.1=125.23.63.23:2780:2783:participant;2791
> {code}
> in this example, {{2791}} is an un-secure (non-ssl) client port. So if any
> client gets notification about configuration changes (e.g about a new quorum
> member), then it won't be able to find out what SSL port to use.
> The configuration format should could be extended with the secure client
> ports, like:
> {code}
> server.1=125.23.63.23:2780:2783:participant;2791_2792ssl
> {code}
> Or something like this... It is important to note that in secure clusters it
> is possible that we don't have any unsecure port open and only using secure
> port.
> The tricky thing with changing the config syntax is backward and forward
> compatibility during rolling upgrades. Maybe easier would be to simply add
> the (currently static) secureClientPort configuration parameter to the
> dynamic configuration parameters. So it would be distributed among the
> "server" and "version" configurations.
> Also this change would require the changing of the {{EnsambleTracker}} class
> in Curator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3577) SSL support in ZooKeeper Dynamic Reconfiguration
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260521#comment-17260521
]
Mate Szalay-Beko commented on ZOOKEEPER-3577:
-
FYI [~eolivelli] : this ticket has Curator implications... Am I right that the
ZooKeeper dynamic reconfig doesn't work now with Curator on SSL-only clusters?
> SSL support in ZooKeeper Dynamic Reconfiguration
>
>
> Key: ZOOKEEPER-3577
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3577
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.5
>Reporter: zhaoyan
>Priority: Minor
>
> ZooKeeper Dynamic Reconfiguration currently doesn't support ssl. It
> distributes the client port, but not the secure client port. An example line
> from the configuration:
> {code}
> server.1=125.23.63.23:2780:2783:participant;2791
> {code}
> in this example, {{2791}} is an un-secure (non-ssl) client port. So if any
> client gets notification about configuration changes (e.g about a new quorum
> member), then it won't be able to find out what SSL port to use.
> The configuration format should could be extended with the secure client
> ports, like:
> {code}
> server.1=125.23.63.23:2780:2783:participant;2791_2792ssl
> {code}
> Or something like this... It is important to note that in secure clusters it
> is possible that we don't have any unsecure port open and only using secure
> port.
> The tricky thing with changing the config syntax is backward and forward
> compatibility during rolling upgrades. Maybe easier would be to simply add
> the (currently static) secureClientPort configuration parameter to the
> dynamic configuration parameters. So it would be distributed among the
> "server" and "version" configurations.
> Also this change would require the changing of the {{EnsambleTracker}} class
> in Curator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3577) SSL support in ZooKeeper Dynamic Reconfiguration
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mate Szalay-Beko updated ZOOKEEPER-3577:
Description:
ZooKeeper Dynamic Reconfiguration currently doesn't support ssl. It distributes
the client port, but not the secure client port. An example line from the
configuration:
{code}
server.1=125.23.63.23:2780:2783:participant;2791
{code}
in this example, {{2791}} is an un-secure (non-ssl) client port. So if any
client gets notification about configuration changes (e.g about a new quorum
member), then it won't be able to find out what SSL port to use.
The configuration format should could be extended with the secure client ports,
like:
{code}
server.1=125.23.63.23:2780:2783:participant;2791_2792ssl
{code}
Or something like this... It is important to note that in secure clusters it is
possible that we don't have any unsecure port open and only using secure port.
The tricky thing with changing the config syntax is backward and forward
compatibility during rolling upgrades. Maybe easier would be to simply add the
(currently static) secureClientPort configuration parameter to the dynamic
configuration parameters. So it would be distributed among the "server" and
"version" configurations.
Also this change would require the changing of the {{EnsambleTracker}} class in
Curator.
was:
ZooKeeper Dynamic Reconfiguration is not support ssl
{{server.1=125.23.63.23:2780:2783:participant;2791}}
{{2791}} is must plaintext port， it not support ssl port
reason:
org.apache.zookeeper.server.quorum.QuorumPeerConfig#setupClientPort
{{only {color:#9876aa}clientAddr{color}:}}
{color:#cc7832}if {color}(qs != {color:#cc7832}null {color}&&
qs.{color:#9876aa}clientAddr {color}!= {color:#cc7832}null{color})
{color:#9876aa}clientPortAddress {color}=
qs.{color:#9876aa}clientAddr{color}{color:#cc7832};{color}
> SSL support in ZooKeeper Dynamic Reconfiguration
>
>
> Key: ZOOKEEPER-3577
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3577
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.5
>Reporter: zhaoyan
>Priority: Minor
>
> ZooKeeper Dynamic Reconfiguration currently doesn't support ssl. It
> distributes the client port, but not the secure client port. An example line
> from the configuration:
> {code}
> server.1=125.23.63.23:2780:2783:participant;2791
> {code}
> in this example, {{2791}} is an un-secure (non-ssl) client port. So if any
> client gets notification about configuration changes (e.g about a new quorum
> member), then it won't be able to find out what SSL port to use.
> The configuration format should could be extended with the secure client
> ports, like:
> {code}
> server.1=125.23.63.23:2780:2783:participant;2791_2792ssl
> {code}
> Or something like this... It is important to note that in secure clusters it
> is possible that we don't have any unsecure port open and only using secure
> port.
> The tricky thing with changing the config syntax is backward and forward
> compatibility during rolling upgrades. Maybe easier would be to simply add
> the (currently static) secureClientPort configuration parameter to the
> dynamic configuration parameters. So it would be distributed among the
> "server" and "version" configurations.
> Also this change would require the changing of the {{EnsambleTracker}} class
> in Curator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3577) SSL support in ZooKeeper Dynamic Reconfiguration
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mate Szalay-Beko updated ZOOKEEPER-3577:
Summary: SSL support in ZooKeeper Dynamic Reconfiguration (was: ZooKeeper
Dynamic Reconfiguration is not support ssl)
> SSL support in ZooKeeper Dynamic Reconfiguration
>
>
> Key: ZOOKEEPER-3577
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3577
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.5
>Reporter: zhaoyan
>Priority: Minor
>
> ZooKeeper Dynamic Reconfiguration is not support ssl
>
> {{server.1=125.23.63.23:2780:2783:participant;2791}}
>
> {{2791}} is must plaintext port， it not support ssl port
>
> reason:
> org.apache.zookeeper.server.quorum.QuorumPeerConfig#setupClientPort
> {{only {color:#9876aa}clientAddr{color}:}}
> {color:#cc7832}if {color}(qs != {color:#cc7832}null {color}&&
> qs.{color:#9876aa}clientAddr {color}!= {color:#cc7832}null{color})
> {color:#9876aa}clientPortAddress {color}=
> qs.{color:#9876aa}clientAddr{color}{color:#cc7832};{color}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-4049) C client test failure on docker
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260503#comment-17260503
]
Mate Szalay-Beko commented on ZOOKEEPER-4049:
-
I think I also saw this on other branches (3.6 and master), but it is possible
that I don't remember correctly. If someone is checking this, then please start
by trying to reproduce / fix it on the master branch first.
> C client test failure on docker
> ---
>
> Key: ZOOKEEPER-4049
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4049
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.8
>Reporter: Norbert Kalmár
>Priority: Major
>
> A c test is constantly failing on docker environment:
> {code}
> [exec]
> /Downloads/zk359/apache-zookeeper-3.5.9/zookeeper-client/zookeeper-client-c/tests/TestClient.cc:789:
> Assertion: equality assertion failed [Expected: 0, Actual : -4]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4049) C client test failure on docker
[
https://issues.apache.org/jira/browse/ZOOKEEPER-4049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Norbert Kalmár updated ZOOKEEPER-4049:
--
Description:
A c test is constantly failing on docker environment:
{code}
[exec]
/Downloads/zk359/apache-zookeeper-3.5.9/zookeeper-client/zookeeper-client-c/tests/TestClient.cc:789:
Assertion: equality assertion failed [Expected: 0, Actual : -4]
{code}
was:
A c test is constantly failing on docker environment:
{code}
[exec]
/Users/enrico.olivelli/Downloads/zk359/apache-zookeeper-3.5.9/zookeeper-client/zookeeper-client-c/tests/TestClient.cc:789:
Assertion: equality assertion failed [Expected: 0, Actual : -4]
{code}
> C client test failure on docker
> ---
>
> Key: ZOOKEEPER-4049
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4049
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.8
>Reporter: Norbert Kalmár
>Priority: Major
>
> A c test is constantly failing on docker environment:
> {code}
> [exec]
> /Downloads/zk359/apache-zookeeper-3.5.9/zookeeper-client/zookeeper-client-c/tests/TestClient.cc:789:
> Assertion: equality assertion failed [Expected: 0, Actual : -4]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-4049) C client test failure on docker
Norbert Kalmár created ZOOKEEPER-4049:
-
Summary: C client test failure on docker
Key: ZOOKEEPER-4049
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4049
Project: ZooKeeper
Issue Type: Bug
Affects Versions: 3.5.8
Reporter: Norbert Kalmár
A c test is constantly failing on docker environment:
{code}
[exec]
/Users/enrico.olivelli/Downloads/zk359/apache-zookeeper-3.5.9/zookeeper-client/zookeeper-client-c/tests/TestClient.cc:789:
Assertion: equality assertion failed [Expected: 0, Actual : -4]
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4048) Upgrade Mockito to 3.6.28 - allow builds on JDK16
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated ZOOKEEPER-4048: -- Labels: pull-request-available (was: ) > Upgrade Mockito to 3.6.28 - allow builds on JDK16 > - > > Key: ZOOKEEPER-4048 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4048 > Project: ZooKeeper > Issue Type: Improvement > Components: tests >Affects Versions: 3.7.0 >Reporter: Enrico Olivelli >Assignee: Enrico Olivelli >Priority: Minor > Labels: pull-request-available > Fix For: 3.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-4048) Upgrade Mockito to 3.6.28 - allow builds on JDK16
Enrico Olivelli created ZOOKEEPER-4048: -- Summary: Upgrade Mockito to 3.6.28 - allow builds on JDK16 Key: ZOOKEEPER-4048 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4048 Project: ZooKeeper Issue Type: Improvement Components: tests Affects Versions: 3.7.0 Reporter: Enrico Olivelli Assignee: Enrico Olivelli Fix For: 3.7.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-2265) zookeeper build fails while doing configuration for cppunit test
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad resolved ZOOKEEPER-2265.
Fix Version/s: (was: 3.5.10)
(was: 3.7.0)
Resolution: Invalid
After moving to maven this issue is no more valid
> zookeeper build fails while doing configuration for cppunit test
>
>
> Key: ZOOKEEPER-2265
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2265
> Project: ZooKeeper
> Issue Type: Bug
> Components: build
>Affects Versions: 3.5.1
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Minor
> Attachments: ZOOKEEPER-2265-01.patch
>
>
> running {color:red}ant tar{color} gives following error
> {code}
> D:\gitHome\zookeeper-trunk\build.xml:1432: Execute failed:
> java.io.IOException: Cannot run program "autoreconf" (in directory
> "D:\gitHome\zookeeper-trunk\src\c"):
> {code}
> This error is purely environment error and it can be fixed by installing
> appropriate software package.
> But does it really required to configure the cpp unit as {color:red}ant
> tar{color} target flow does not run cppunit test cases. Then why to configure?
> There should be no cppunit configurations for {color:red}ant tar{color}
> target flow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-2262) Admin commands do not include secure client information
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad resolved ZOOKEEPER-2262. Fix Version/s: (was: 3.5.10) (was: 3.7.0) Resolution: Won't Fix Secure client information included as part of ZOOKEEPER-3633 fix > Admin commands do not include secure client information > --- > > Key: ZOOKEEPER-2262 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2262 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.0 >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Labels: JettyAdminServer > > Admin commands do not include secure client information > connections, configuration, connection_stat_reset and stats admin should > include secure client informations > 1) configuration should include the secure client port also > 2) connections should include secure connections also > 3) connection_stat_reset should also reset secure connection > 4) stats command should accumulate both secure and non secure information -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-2456) Provide API to get user from different authentication providers
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mohammad Arshad resolved ZOOKEEPER-2456.
Fix Version/s: (was: 3.5.10)
(was: 3.7.0)
Resolution: Won't Fix
The API got added as part of ZOOKEEPER-1260.
{code:java}
org.apache.zookeeper.server.auth.AuthenticationProvider#getUserName
{code}
> Provide API to get user from different authentication providers
> ---
>
> Key: ZOOKEEPER-2456
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2456
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Major
>
> Currently zookeeper server same field is used to store both user name and
> password
> Provide a mechanism to separate the user and password either by adding new
> field or by adding new API
> DETAILS:
> org.apache.zookeeper.data.Id class is used to store scheme and id.
> {code}
> public Id( String scheme, String id)
> {code}
> id field holds only user in most cases but in some cases it holds user as
> well as password
> By default there are only four authentication provider
> DigestAuthenticationProvider
> IPAuthenticationProvider
> SASLAuthenticationProvider
> X509AuthenticationProvider
> In code we can check if scheme is digest then {{id.split(":")\[0\]}} is user
> otherwise id is user. This will work only if we are limited to above four
> authentication provider
> But Custom authentication provider are very important and are very commonly
> used. How the zookeeper code will know what is the user, is it id or
> {{id.split(":")\[0\]}} or anything else ?
> So there is need to add new API which AuthenticationProvider providers
> implement to define what is user.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-832) Invalid session id causes infinite loop during automatic reconnect
[ https://issues.apache.org/jira/browse/ZOOKEEPER-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260382#comment-17260382 ] Mohammad Arshad commented on ZOOKEEPER-832: --- [~george_zhu] there is no plan this commit this patch. If you are still facing the issue, please raise another jira with details and scenario. As this issue scenario is not valid for fix. > Invalid session id causes infinite loop during automatic reconnect > -- > > Key: ZOOKEEPER-832 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-832 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.4.5, 3.5.0, 3.4.11 > Environment: All >Reporter: Ryan Holmes >Assignee: Mohammad Arshad >Priority: Critical > Attachments: ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, > ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, > ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, > ZOOKEEPER-832.patch, ZOOKEEPER-832.patch > > > Steps to reproduce: > 1.) Connect to a standalone server using the Java client. > 2.) Stop the server. > 3.) Delete the contents of the data directory (i.e. the persisted session > data). > 4.) Start the server. > The client now automatically tries to reconnect but the server refuses the > connection because the session id is invalid. The client and server are now > in an infinite loop of attempted and rejected connections. While this > situation represents a catastrophic failure and the current behavior is not > incorrect, it appears that there is no way to detect this situation on the > client and therefore no way to recover. > The suggested improvement is to send an event to the default watcher > indicating that the current state is "session invalid", similar to how the > "session expired" state is handled. > Server log output (repeats indefinitely): > 2010-08-05 11:48:08,283 - INFO > [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn$Factory@250] - > Accepted socket connection from /127.0.0.1:63292 > 2010-08-05 11:48:08,284 - INFO > [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@751] - Refusing > session request for client /127.0.0.1:63292 as it has seen zxid 0x44 our last > zxid is 0x0 client must try another server > 2010-08-05 11:48:08,284 - INFO > [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1434] - Closed > socket connection for client /127.0.0.1:63292 (no session established for > client) > Client log output (repeats indefinitely): > 11:47:17 org.apache.zookeeper.ClientCnxn startConnect INFO line 1000 - > Opening socket connection to server localhost/127.0.0.1:2181 > 11:47:17 org.apache.zookeeper.ClientCnxn run WARN line 1120 - Session > 0x12a3ae4e893000a for server null, unexpected error, closing socket > connection and attempting reconnect > java.net.ConnectException: Connection refused > at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) > at > sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:574) > at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1078) > 11:47:17 org.apache.zookeeper.ClientCnxn cleanup DEBUG line 1167 - Ignoring > exception during shutdown input > java.nio.channels.ClosedChannelException > at > sun.nio.ch.SocketChannelImpl.shutdownInput(SocketChannelImpl.java:638) > at sun.nio.ch.SocketAdaptor.shutdownInput(SocketAdaptor.java:360) > at > org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1164) > at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1129) > 11:47:17 org.apache.zookeeper.ClientCnxn cleanup DEBUG line 1174 - Ignoring > exception during shutdown output > java.nio.channels.ClosedChannelException > at > sun.nio.ch.SocketChannelImpl.shutdownOutput(SocketChannelImpl.java:649) > at sun.nio.ch.SocketAdaptor.shutdownOutput(SocketAdaptor.java:368) > at > org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1171) > at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1129) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3561) Generalize target authentication scheme for ZooKeeper authentication enforcement.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260355#comment-17260355 ] Mohammad Arshad commented on ZOOKEEPER-3561: It is ok, let it be only in master branch > Generalize target authentication scheme for ZooKeeper authentication > enforcement. > - > > Key: ZOOKEEPER-3561 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3561 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.6.0 >Reporter: Michael Han >Assignee: Mohammad Arshad >Priority: Major > Labels: pull-request-available > Fix For: 3.7.0 > > Time Spent: 5h 50m > Remaining Estimate: 0h > > ZOOKEEPER-1634 introduced an option to allow user enforce authentication for > ZooKeeper clients, but the enforced authentication scheme in committed > implementation was SASL only. > This JIRA is to generalize the authentication scheme such that the > authentication enforcement on ZooKeeper clients could work with any supported > authentication scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-3558) Support authentication enforcement
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad resolved ZOOKEEPER-3558. Release Note: ZOOKEEPER-3561 implemented this jira functionality in master branch. Won't Fix in branch-3.5 Resolution: Won't Fix > Support authentication enforcement > -- > > Key: ZOOKEEPER-3558 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3558 > Project: ZooKeeper > Issue Type: New Feature >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Fix For: 3.5.10 > > Attachments: ZOOKEEPER-3558-01.patch > > > Provide authentication enforcement in ZooKeeper that is backward compatible > and can work for any authentication scheme, can work even with custom > authentication schemes. > *Problems:* > 1. Currently server is starting with default authentication > providers(DigestAuthenticationProvider, IPAuthenticationProvider). These > default authentication providers are not really secure. > 2. ZooKeeper server is not checking whether authentication is done or not > before performing any user operation. > *Solutions:* > 1. We should not start any authentication provider by default. But this would > be backward incompatible change. So we can provide configuration whether to > start default authentication provides are not. > By default we can start these authentication providers. > 2. Before any user operation server should check whether authentication > happened or not. At least client must be authenticated with one > authentication scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-4038) when logfile zxid equals to target zxid, should not iterate over the next logfile (FileTxnLog:653)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260329#comment-17260329 ] huangwenbo commented on ZOOKEEPER-4038: --- It doesn't matter. I'm really sorry for the recent interruption. I hope we can study together In addition, do you know who should be asked to review such problems? Or do I need to raise PR after modification and wait for others to pay attention to it? （没关系，非常抱歉最近的打扰:D，希望能共同学习。另外，你知道这样的问题需要找谁来review么？还是需要修改之后提pr，等待其他人来关注呢？） > when logfile zxid equals to target zxid, should not iterate over the next > logfile (FileTxnLog:653) > -- > > Key: ZOOKEEPER-4038 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4038 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: huangwenbo >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-4038) when logfile zxid equals to target zxid, should not iterate over the next logfile (FileTxnLog:653)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260318#comment-17260318 ] maoling commented on ZOOKEEPER-4038: [~nsnhuang] I'm very very very sorry for my late. A little busy recently. I must take a look when I'm free. In fact, I'm not a committer(我也是人民群众):):D. If you want to contribute more to ZooKeeper project, you can pick up [some tickets|https://issues.apache.org/jira/issues/?jql=project%20%3D%20ZOOKEEPER%20and%20creator%20%20%3D%20maoling%20ORDER%20BY%20%20created%20DESC] I created(e.g: ZOOKEEPER-4036, ZOOKEEPER-4029, ZOOKEEPER-4035, ZOOKEEPER-4007) > when logfile zxid equals to target zxid, should not iterate over the next > logfile (FileTxnLog:653) > -- > > Key: ZOOKEEPER-4038 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4038 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: huangwenbo >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4038) when logfile zxid equals to target zxid, should not iterate over the next logfile (FileTxnLog:653)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maoling updated ZOOKEEPER-4038: --- Priority: Minor (was: Blocker) > when logfile zxid equals to target zxid, should not iterate over the next > logfile (FileTxnLog:653) > -- > > Key: ZOOKEEPER-4038 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4038 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: huangwenbo >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (ZOOKEEPER-4038) when logfile zxid equals to target zxid, should not iterate over the next logfile (FileTxnLog:653)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maoling reassigned ZOOKEEPER-4038: -- Assignee: (was: maoling) > when logfile zxid equals to target zxid, should not iterate over the next > logfile (FileTxnLog:653) > -- > > Key: ZOOKEEPER-4038 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4038 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: huangwenbo >Priority: Blocker > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-3264) The benchmark tools for zookeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Diederen resolved ZOOKEEPER-3264. Resolution: Fixed Issue resolved by pull request 1558 [https://github.com/apache/zookeeper/pull/1558] > The benchmark tools for zookeeper > - > > Key: ZOOKEEPER-3264 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3264 > Project: ZooKeeper > Issue Type: New Feature > Components: documentation, server >Reporter: maoling >Assignee: maoling >Priority: Major > Labels: pull-request-available > Fix For: 3.7.0 > > Attachments: bm-clients.png, bm-read-histogram.png, > bm-update-histogram.png > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Reference: > https://github.com/etcd-io/etcd/blob/master/tools/benchmark/cmd/range.go > https://github.com/antirez/redis/blob/unstable/src/redis-benchmark.c > https://github.com/phunt/zk-smoketest/blob/master/zk-latencies.py > https://github.com/brownsys/zookeeper-benchmark/blob/master/src/main/java/edu/brown/cs/zkbenchmark/ZooKeeperBenchmark.java -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-4038) when logfile zxid equals to target zxid, should not iterate over the next logfile (FileTxnLog:653)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260304#comment-17260304 ] huangwenbo commented on ZOOKEEPER-4038: --- It's been a long time > when logfile zxid equals to target zxid, should not iterate over the next > logfile (FileTxnLog:653) > -- > > Key: ZOOKEEPER-4038 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4038 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: huangwenbo >Assignee: maoling >Priority: Blocker > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-4038) when logfile zxid equals to target zxid, should not iterate over the next logfile (FileTxnLog:653)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260303#comment-17260303 ] huangwenbo commented on ZOOKEEPER-4038: --- [~maoling] Can you help me? If not, who should I turn to for help? > when logfile zxid equals to target zxid, should not iterate over the next > logfile (FileTxnLog:653) > -- > > Key: ZOOKEEPER-4038 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4038 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: huangwenbo >Assignee: maoling >Priority: Blocker > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (ZOOKEEPER-4038) when logfile zxid equals to target zxid, should not iterate over the next logfile (FileTxnLog:653)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huangwenbo reassigned ZOOKEEPER-4038: - Assignee: maoling > when logfile zxid equals to target zxid, should not iterate over the next > logfile (FileTxnLog:653) > -- > > Key: ZOOKEEPER-4038 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4038 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: huangwenbo >Assignee: maoling >Priority: Blocker > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4038) when logfile zxid equals to target zxid, should not iterate over the next logfile (FileTxnLog:653)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huangwenbo updated ZOOKEEPER-4038: -- Priority: Blocker (was: Critical) > when logfile zxid equals to target zxid, should not iterate over the next > logfile (FileTxnLog:653) > -- > > Key: ZOOKEEPER-4038 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4038 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: huangwenbo >Priority: Blocker > -- This message was sent by Atlassian Jira (v8.3.4#803005)
