'zkServer.sh status' connects only to local node ?

[prashantkumar dhotre]

Hi,
Could you please help me with a basic query regarding 'zkServer.sh status' ?
>From zkServer.sh, it appears that this cmd tries to connect to server at
local node and get info.
If the local server is down, does it connect to next available server (as
specified in config file )  and returns status ?
Or is this cmd intended to only report status of local server and not
status of zookeeper quorum ?
My use case is, my client app needs to connect to zookeeper and create
znode.
connect routine ( which does zookeeper_init2) has retries and in case of
connect failure, it sleeps and retries for number of times.
But if zookeeper quorum is down (zookeeper not running ) then I don't want
to even attempt connection ( hence avoid wait delay in connect api)
Regards,
Prashant

Re: default value for quorum.auth.kerberos.servicePrincipal

[Rakesh Radhakrishnan]

Hi Ram,

ZooKeeper Quorum authentication support two schemes, Kerberos or
DIGEST-MD5. User has to configure either Kerb or digest configuration
values. Both together not required.

I'd recommend you to go through Kerberos, digest simulation unit test cases
where we have valid and invalid scenarios. Hope this would get idea about
the required configs.

https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/test/java/org/apache/zookeeper/server/quorum/auth/QuorumDigestAuthTest.java
https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/test/java/org/apache/zookeeper/server/quorum/auth/QuorumKerberosHostBasedAuthTest.java

Could you describe the issues that troubles you in setting up quorum auth,
if any.

Thanks,
Rakesh

On Fri, Dec 13, 2019 at 3:49 AM rammohan ganapavarapu <
rammohanga...@gmail.com> wrote:

> Hi,
>
> Even if i enable sasl but md5-diget what should be this property set to,
> this property only take effect for kerberos or for both?
>
> Ram
>
> On Fri, Dec 6, 2019 at 7:55 AM rammohan ganapavarapu <
> rammohanga...@gmail.com> wrote:
>
> > Mate,
> >
> > Thank you, I did search source code found the same, I am trying to create
> > a zoo conf with all default properties.
> >
> > Ram
> >
> > On Fri, Dec 6, 2019, 2:44 AM Mate Szalay-Beko
> 
> > wrote:
> >
> >> Hi Ram,
> >>
> >> this parameter is needed to be defined when you want to enable secure
> >> authentication in the communication between ZooKeeper servers. In
> general,
> >> the 'principal' is a 'username' what you want your ZooKeeper servers to
> >> use
> >> when they talk with each other. Ideally you have a central Kereros
> service
> >> somewhere where this principal is already registered.
> >> A kerberos principal is usually in the form of
> >> "user_or_service_name/host@realm" (some more explanation:
> >> https://ssimo.org/blog/id_016.html)
> >>
> >> According to the source code, the default value of
> >> quorum.auth.kerberos.servicePrincipal is "zkquorum/localhost". But I
> think
> >> if you don't enable the quorum SASL in ZooKeeper, then this property
> will
> >> never be actually used.
> >>
> >> Please see this page about SASL in ZooKeeper:
> >>
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+and+SASL
> >>
> >> I also found a Cloudera blogpost on the topic:
> >>
> >>
> https://blog.cloudera.com/hardening-apache-zookeeper-security-sasl-quorum-peer-mutual-authentication-and-authorization/
> >>
> >> Cheers,
> >> Mate
> >>
> >>
> >> On Thu, Dec 5, 2019 at 11:50 PM rammohan ganapavarapu <
> >> rammohanga...@gmail.com> wrote:
> >>
> >> > Hi,
> >> >
> >> > What is the default value for this property, if i don't  enable sasl
> >> and if
> >> > i don't define what will be the value?
> >> >
> >> > quorum.auth.kerberos.servicePrincipal
> >> >
> >> > Also what does this means "servicename/_HOST"
> >> >
> >> > Thanks,
> >> > Ram
> >> >
> >>
> >
>

Re: clientCnxnSocket#updateLastSendAndHeard() method usage

[Michael Han]

We had some prod issues previously related to the usage of cached "now"
variable (and lacking of consistent accessing pattern for updateNow) used
in java client - we had a patch internally (basically what's described in
ZOOKEEPER-2471) that removed usage of the cache value and instead calculate
"now" whenever we need.

On Wed, Dec 11, 2019 at 8:35 PM Karan Mehta 
wrote:

> Hello,
>
> On this line in ClientCnxn.java
> <
> https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/ClientCnxn.java#L1183
> >,
> we are calling clientCnxnSocket.updateLastSendAndHeard() method but we
> didn't call clientCnxnSocket.updateNow() method before that. Is there a
> possiblity that can result in incorrect calculation
> of clientCnxnSocket.getIdleRecv(), causing it to
> throw SessionTimeoutException?
>
> --
> Karan Mehta
>
> 
>

Re: Snapshot creation after 3.4.14 -> 3.5.6 upgrade

[Michael Han]

>> My question is: Is there a way to force the snapshot creation / sync
from the leader?

3.5.6 will automatically create a clean snapshot as part of server start up
process. So a snapshot should be available after initial upgrade and there
is no need to force a snapshot creation.

On Mon, Dec 9, 2019 at 2:11 AM Thomas Cooper  wrote:

> Hi,
>
> I am working on upgrading a Kubernetes based 3.4.14 cluster to 3.5.6.
>
> I are hitting the issue where the new snapshot checks prevent the newly
> upgraded 3.5.6 cluster from starting. This usually happens in our test
> set-up as the 3.4.14 cluster is not very old and has not hit the snapCount
> limit yet. Typically only one node (presumable the leader) has a snapshot
> file but the other do not.
>
> I can disable the snapshot checks via the config value for the upgrade to
> 3.5.6, however we obviously need to re-enable the checks ASAP. The issue is
> making sure all of the ZK nodes have snapshots so that the checks can be
> re-enabled.
>
> My question is: Is there a way to force the snapshot creation / sync from
> the leader?
>
> As part of our upgrade process we need to restart the servers soon after
> the initial upgrade of the ZK container images to enable config changes. If
> the snapshot creation / sync hasn't happened by this point then obviously
> the checks will fail. If we can force a snapshot creation, after the
> initial upgrade, we can re-enable the checks as part of the upgrade
> process. If not, we will need to create some method to check if the
> snapshots have been created and periodically inspect the ZK server file
> system, re-enabling the checks once they all have snapshots.
>
> Any pointers would be appreciated.
>
> Thanks in advance,
>
> Tom Cooper
>

Re: default value for quorum.auth.kerberos.servicePrincipal

[rammohan ganapavarapu]

Hi,

Even if i enable sasl but md5-diget what should be this property set to,
this property only take effect for kerberos or for both?

Ram

On Fri, Dec 6, 2019 at 7:55 AM rammohan ganapavarapu <
rammohanga...@gmail.com> wrote:

> Mate,
>
> Thank you, I did search source code found the same, I am trying to create
> a zoo conf with all default properties.
>
> Ram
>
> On Fri, Dec 6, 2019, 2:44 AM Mate Szalay-Beko 
> wrote:
>
>> Hi Ram,
>>
>> this parameter is needed to be defined when you want to enable secure
>> authentication in the communication between ZooKeeper servers. In general,
>> the 'principal' is a 'username' what you want your ZooKeeper servers to
>> use
>> when they talk with each other. Ideally you have a central Kereros service
>> somewhere where this principal is already registered.
>> A kerberos principal is usually in the form of
>> "user_or_service_name/host@realm" (some more explanation:
>> https://ssimo.org/blog/id_016.html)
>>
>> According to the source code, the default value of
>> quorum.auth.kerberos.servicePrincipal is "zkquorum/localhost". But I think
>> if you don't enable the quorum SASL in ZooKeeper, then this property will
>> never be actually used.
>>
>> Please see this page about SASL in ZooKeeper:
>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+and+SASL
>>
>> I also found a Cloudera blogpost on the topic:
>>
>> https://blog.cloudera.com/hardening-apache-zookeeper-security-sasl-quorum-peer-mutual-authentication-and-authorization/
>>
>> Cheers,
>> Mate
>>
>>
>> On Thu, Dec 5, 2019 at 11:50 PM rammohan ganapavarapu <
>> rammohanga...@gmail.com> wrote:
>>
>> > Hi,
>> >
>> > What is the default value for this property, if i don't  enable sasl
>> and if
>> > i don't define what will be the value?
>> >
>> > quorum.auth.kerberos.servicePrincipal
>> >
>> > Also what does this means "servicename/_HOST"
>> >
>> > Thanks,
>> > Ram
>> >
>>
>

Re: quorum.cnxn.threads.size

[rammohan ganapavarapu]

No, my loglevel setting is INFO.

 ps -ef |grep zoo|awk '{print $10}'
-Dzookeeper.root.logger=INFO,CONSOLE

Just to clarify, i am upgrading from 3.4.5 to 3.4.14 and i am upgrading
observers firs then followers (yet to do) and see this flood of log
messages in observer logs.

Observer: 3.4.14 version
Leader: 3.4.5 version

On Thu, Dec 12, 2019 at 9:13 AM Flavio Junqueira  wrote:

> If you set up logging at DEBUG level and you see this message:
>"Not initializing connection executor as quorum sasl auth is disabled"
> then you are good.
>
> -Flavio
>
> > On 12 Dec 2019, at 18:06, rammohan ganapavarapu 
> wrote:
> >
> > I am assuming its only logging, is there any way i can verify its not
> > opening cnxn threads?
> >
> >
> >
> > On Thu, Dec 12, 2019 at 7:15 AM Flavio Junqueira  wrote:
> >
> >> If it is just logging the value of the property, then it is fine because
> >> the property is set, but it is not used if SASL is disabled.
> >>
> >> -Flavio
> >>
> >>> On 12 Dec 2019, at 16:01, rammohan ganapavarapu <
> rammohanga...@gmail.com>
> >> wrote:
> >>>
> >>> Flavio,
> >>>
> >>> Thanks for clarification, I have a cluster with sasl disabled but in
> >> start
> >>> up log I still see number of threads set to default 20.
> >>>
> >>> Thanks,
> >>> Ram
> >>> On Thu, Dec 12, 2019, 6:43 AM Flavio Junqueira  wrote:
> >>>
>  Hi Ram,
> 
>  Yes, this parameter is only applicable when SASL is enabled, see in
>  QuorumCnxManager#initializeAuth how it doesn't have a chance to use
> the
>  parameter when SASL is disabled.
> 
>  Your assessment is correct about it being based on the number of
>  participants, excluding observers. This parameter is used in
>  QuorumCnxManager, which manages connections for leader election, and
>  observers do not participate in the election.
> 
>  -Flavio
> 
> > On 12 Dec 2019, at 14:41, rammohan ganapavarapu <
> >> rammohanga...@gmail.com>
>  wrote:
> >
> > Any idea?
> >
> > On Wed, Dec 11, 2019, 2:23 PM rammohan ganapavarapu <
>  rammohanga...@gmail.com>
> > wrote:
> >
> >> And to add more on the same property, the description says
> >>
> >>
> >>
> >>
> >>
> >> *"For example, consider a 3-node cluster,# during quorum formation
> at
> >> least 3 outgoing connection requests and 3 incoming connection#
> >> requests
> >> will occur. So total 6 threads will be used. It is recommended to
>  configure
> >> 2x# number of threads for smooth execution, where 'x' represents the
> >> cluster size"*
> >>
> >> Here* cluster size* is number of *followers* right not both
> followers
>  and
> >> observers??
> >>
> >> Ram
> >>
> >> On Wed, Dec 11, 2019 at 2:19 PM rammohan ganapavarapu <
> >> rammohanga...@gmail.com> wrote:
> >>
> >>> Is this property only applicable in case of sasl auth enabled? or
> >> does
>  it
> >>> work even when we turn off authentication?
> >>>
> >>>
> >>> *quorum.cnxn.threads.size*
> >>>
> >>> Thanks,
> >>> Ram
> >>>
> >>
> 
> 
> >>
> >>
>
>

Re: quorum.cnxn.threads.size

[Flavio Junqueira]

If you set up logging at DEBUG level and you see this message:
   "Not initializing connection executor as quorum sasl auth is disabled"
then you are good.

-Flavio

> On 12 Dec 2019, at 18:06, rammohan ganapavarapu  
> wrote:
> 
> I am assuming its only logging, is there any way i can verify its not
> opening cnxn threads?
> 
> 
> 
> On Thu, Dec 12, 2019 at 7:15 AM Flavio Junqueira  wrote:
> 
>> If it is just logging the value of the property, then it is fine because
>> the property is set, but it is not used if SASL is disabled.
>> 
>> -Flavio
>> 
>>> On 12 Dec 2019, at 16:01, rammohan ganapavarapu 
>> wrote:
>>> 
>>> Flavio,
>>> 
>>> Thanks for clarification, I have a cluster with sasl disabled but in
>> start
>>> up log I still see number of threads set to default 20.
>>> 
>>> Thanks,
>>> Ram
>>> On Thu, Dec 12, 2019, 6:43 AM Flavio Junqueira  wrote:
>>> 
 Hi Ram,
 
 Yes, this parameter is only applicable when SASL is enabled, see in
 QuorumCnxManager#initializeAuth how it doesn't have a chance to use the
 parameter when SASL is disabled.
 
 Your assessment is correct about it being based on the number of
 participants, excluding observers. This parameter is used in
 QuorumCnxManager, which manages connections for leader election, and
 observers do not participate in the election.
 
 -Flavio
 
> On 12 Dec 2019, at 14:41, rammohan ganapavarapu <
>> rammohanga...@gmail.com>
 wrote:
> 
> Any idea?
> 
> On Wed, Dec 11, 2019, 2:23 PM rammohan ganapavarapu <
 rammohanga...@gmail.com>
> wrote:
> 
>> And to add more on the same property, the description says
>> 
>> 
>> 
>> 
>> 
>> *"For example, consider a 3-node cluster,# during quorum formation at
>> least 3 outgoing connection requests and 3 incoming connection#
>> requests
>> will occur. So total 6 threads will be used. It is recommended to
 configure
>> 2x# number of threads for smooth execution, where 'x' represents the
>> cluster size"*
>> 
>> Here* cluster size* is number of *followers* right not both followers
 and
>> observers??
>> 
>> Ram
>> 
>> On Wed, Dec 11, 2019 at 2:19 PM rammohan ganapavarapu <
>> rammohanga...@gmail.com> wrote:
>> 
>>> Is this property only applicable in case of sasl auth enabled? or
>> does
 it
>>> work even when we turn off authentication?
>>> 
>>> 
>>> *quorum.cnxn.threads.size*
>>> 
>>> Thanks,
>>> Ram
>>> 
>> 
 
 
>> 
>> 

Re: Notification messages in log

[rammohan ganapavarapu]

Any thoughts?

On Wed, Dec 11, 2019 at 7:48 PM rammohan ganapavarapu <
rammohanga...@gmail.com> wrote:

> Hi Enrico,
>
> Since i have log  rotation, i am not worried about size but i see ~14 such
> messages for a second which seems unusual for me.
>
> grep "Notification: 0 (message format version)"  zookeeper.log|awk '{print
> $1" "$2}'|awk -F "," '{print $1}'|sort |uniq -c
>   9 2019-12-12 03:11:14
>  14 2019-12-12 03:11:15
>  13 2019-12-12 03:11:16
>  14 2019-12-12 03:11:17
>  14 2019-12-12 03:11:18
>  14 2019-12-12 03:11:19
>  14 2019-12-12 03:11:20
>  13 2019-12-12 03:11:21
>  14 2019-12-12 03:11:22
>  14 2019-12-12 03:11:23
>  14 2019-12-12 03:11:24
>  14 2019-12-12 03:11:25
>  13 2019-12-12 03:11:26
>  14 2019-12-12 03:11:27
>  14 2019-12-12 03:11:28
>  14 2019-12-12 03:11:29
>  14 2019-12-12 03:11:30
>  13 2019-12-12 03:11:31
>  14 2019-12-12 03:11:32
>  14 2019-12-12 03:11:33
>  14 2019-12-12 03:11:34
>  14 2019-12-12 03:11:35
>
> FYI: I  am in upgrade processes where leader is still on 3.4.5 version and
> this observer is  3.4.14 version does it cause such behavior?
>
> Thanks,
> Ram
>
> On Wed, Dec 11, 2019 at 3:22 PM Enrico Olivelli 
> wrote:
>
>> Ram,
>> How many GB of logs do you have?
>> Those messages are not scary but they shouldn't be so many.
>>
>> Enrico
>>
>>
>> Il mer 11 dic 2019, 23:16 rammohan ganapavarapu 
>> ha scritto:
>>
>> > After 3.4.14 version upgrade i am seeing continuous messages as bellow
>> in
>> > logs, is it normal?
>> >
>> >
>> > 2019-12-11 22:12:44,036 [myid:104] - INFO
>> >  [WorkerReceiver[myid=104]:FastLeaderElection@595] - Notification: 0
>> > (message format version), 100 (n.leader), 0x0 (n.zxid), 0x1 (n.round),
>> > LOOKING (n.state), 100 (n.sid), 0x0 (n.peerEpoch) OBSERVING (my state)
>> > 2019-12-11 22:12:44,108 [myid:104] - INFO
>> >  [WorkerReceiver[myid=104]:FastLeaderElection@595] - Notification: 0
>> > (message format version), 100 (n.leader), 0x0 (n.zxid), 0x1 (n.round),
>> > LOOKING (n.state), 100 (n.sid), 0x0 (n.peerEpoch) OBSERVING (my state)
>> > 2019-12-11 22:12:44,180 [myid:104] - INFO
>> >  [WorkerReceiver[myid=104]:FastLeaderElection@595] - Notification: 0
>> > (message format version), 100 (n.leader), 0x0 (n.zxid), 0x1 (n.round),
>> > LOOKING (n.state), 100 (n.sid), 0x0 (n.peerEpoch) OBSERVING (my state)
>> > 2019-12-11 22:12:44,252 [myid:104] - INFO
>> >  [WorkerReceiver[myid=104]:FastLeaderElection@595] - Notification: 0
>> > (message format version), 100 (n.leader), 0x0 (n.zxid), 0x1 (n.round),
>> > LOOKING (n.state), 100 (n.sid), 0x0 (n.peerEpoch) OBSERVING (my state)
>> > 2019-12-11 22:12:44,323 [myid:104] - INFO
>> >  [WorkerReceiver[myid=104]:FastLeaderElection@595] - Notification: 0
>> > (message format version), 100 (n.leader), 0x0 (n.zxid), 0x1 (n.round),
>> > LOOKING (n.state), 100 (n.sid), 0x0 (n.peerEpoch) OBSERVING (my state)
>> > 2019-12-11 22:12:44,395 [myid:104] - INFO
>> >  [WorkerReceiver[myid=104]:FastLeaderElection@595] - Notification: 0
>> > (message format version), 100 (n.leader), 0x0 (n.zxid), 0x1 (n.round),
>> > LOOKING (n.state), 100 (n.sid), 0x0 (n.peerEpoch) OBSERVING (my state)
>> > 2019-12-11 22:12:44,467 [myid:104] - INFO
>> >  [WorkerReceiver[myid=104]:FastLeaderElection@595] - Notification: 0
>> > (message format version), 100 (n.leader), 0x0 (n.zxid), 0x1 (n.round),
>> > LOOKING (n.state), 100 (n.sid), 0x0 (n.peerEpoch) OBSERVING (my state)
>> > 2019-12-11 22:12:44,538 [myid:104] - INFO
>> >  [WorkerReceiver[myid=104]:FastLeaderElection@595] - Notification: 0
>> > (message format version), 100 (n.leader), 0x0 (n.zxid), 0x1 (n.round),
>> > LOOKING (n.state), 100 (n.sid), 0x0 (n.peerEpoch) OBSERVING (my state)
>> > 2019-12-11 22:12:44,610 [myid:104] - INFO
>> >  [WorkerReceiver[myid=104]:FastLeaderElection@595] - Notification: 0
>> > (message format version), 100 (n.leader), 0x0 (n.zxid), 0x1 (n.round),
>> > LOOKING (n.state), 100 (n.sid), 0x0 (n.peerEpoch) OBSERVING (my state)
>> > 2019-12-11 22:12:44,682 [myid:104] - INFO
>> >  [WorkerReceiver[myid=104]:FastLeaderElection@595] - Notification: 0
>> > (message format version), 100 (n.leader), 0x0 (n.zxid), 0x1 (n.round),
>> > LOOKING (n.state), 100 (n.sid), 0x0 (n.peerEpoch) OBSERVING (my state)
>> > 2019-12-11 22:12:44,754 [myid:104] - INFO
>> >  [WorkerReceiver[myid=104]:FastLeaderElection@595] - Notification: 0
>> > (message format version), 100 (n.leader), 0x0 (n.zxid), 0x1 (n.round),
>> > LOOKING (n.state), 100 (n.sid), 0x0 (n.peerEpoch) OBSERVING (my state)
>> > 2019-12-11 22:12:44,825 [myid:104] - INFO
>> >  [WorkerReceiver[myid=104]:FastLeaderElection@595] - Notification: 0
>> > (message format version), 100 (n.leader), 0x0 (n.zxid), 0x1 (n.round),
>> > LOOKING (n.state), 100 (n.sid), 0x0 (n.peerEpoch) OBSERVING (my state)
>> > 2019-12-11 22:12:44,897 [myid:104] - INFO
>> >  [WorkerReceiver[myid=104]:FastLeaderElection@595] - Notification: 0
>> > (message format 

Re: quorum.cnxn.threads.size

[rammohan ganapavarapu]

I am assuming its only logging, is there any way i can verify its not
opening cnxn threads?



On Thu, Dec 12, 2019 at 7:15 AM Flavio Junqueira  wrote:

> If it is just logging the value of the property, then it is fine because
> the property is set, but it is not used if SASL is disabled.
>
> -Flavio
>
> > On 12 Dec 2019, at 16:01, rammohan ganapavarapu 
> wrote:
> >
> > Flavio,
> >
> > Thanks for clarification, I have a cluster with sasl disabled but in
> start
> > up log I still see number of threads set to default 20.
> >
> > Thanks,
> > Ram
> > On Thu, Dec 12, 2019, 6:43 AM Flavio Junqueira  wrote:
> >
> >> Hi Ram,
> >>
> >> Yes, this parameter is only applicable when SASL is enabled, see in
> >> QuorumCnxManager#initializeAuth how it doesn't have a chance to use the
> >> parameter when SASL is disabled.
> >>
> >> Your assessment is correct about it being based on the number of
> >> participants, excluding observers. This parameter is used in
> >> QuorumCnxManager, which manages connections for leader election, and
> >> observers do not participate in the election.
> >>
> >> -Flavio
> >>
> >>> On 12 Dec 2019, at 14:41, rammohan ganapavarapu <
> rammohanga...@gmail.com>
> >> wrote:
> >>>
> >>> Any idea?
> >>>
> >>> On Wed, Dec 11, 2019, 2:23 PM rammohan ganapavarapu <
> >> rammohanga...@gmail.com>
> >>> wrote:
> >>>
>  And to add more on the same property, the description says
> 
> 
> 
> 
> 
>  *"For example, consider a 3-node cluster,# during quorum formation at
>  least 3 outgoing connection requests and 3 incoming connection#
> requests
>  will occur. So total 6 threads will be used. It is recommended to
> >> configure
>  2x# number of threads for smooth execution, where 'x' represents the
>  cluster size"*
> 
>  Here* cluster size* is number of *followers* right not both followers
> >> and
>  observers??
> 
>  Ram
> 
>  On Wed, Dec 11, 2019 at 2:19 PM rammohan ganapavarapu <
>  rammohanga...@gmail.com> wrote:
> 
> > Is this property only applicable in case of sasl auth enabled? or
> does
> >> it
> > work even when we turn off authentication?
> >
> >
> > *quorum.cnxn.threads.size*
> >
> > Thanks,
> > Ram
> >
> 
> >>
> >>
>
>

Re: ZK makes apache 2019 "top 5" projects

[Norbert Kalmar]

Kudos to everyone!
Also, nice to see so many contributions. And not just veterans, but plenty
of new community members! Thank you all!

Regards,
Norbert

On Thu, Dec 12, 2019 at 2:00 PM Jordan Zimmerman 
wrote:

> Fantastic
>
> 
> Jordan Zimmerman
>
> > On Dec 12, 2019, at 3:49 AM, Flavio Junqueira  wrote:
> >
> > +1, thank you all for the hard work.
> >
> > -Flavio
> >
> >> On 12 Dec 2019, at 08:36, Enrico Olivelli  wrote:
> >>
> >> Yes, great.
> >>
> >> Please also note that Kafka and Lucene/Solr that are still listed in
> that
> >> list  are using Zookeeper :)
> >>
> >>
> >> Enrico
> >>
> >> Il gio 12 dic 2019, 05:46 tison  ha scritto:
> >>
> >>> Kudos!
> >>>
> >>> Best,
> >>> tison.
> >>>
> >>>
> >>> Patrick Hunt  于2019年12月12日周四 上午11:32写道：
> >>>
>  This is really awesome, check it out:
>  https://twitter.com/phunt/status/1204966326118141952
> 
>  Kudos ZooKeeper community on all the hard work and efforts!
> 
>  Patrick
> 
> >>>
> >
>

Re: Disable non-secured client port

[Chris T.]

Great, thanks.

On Thu, Dec 12, 2019 at 3:53 PM Szalay-Bekő Máté 
wrote:

> Hi Chris,
>
> The short answer is yes, all you need to do is don't specify the clientPort
> in the zoo.cfg.
>
> An example for the zoo.cfg in this case:
>
> tickTime=3000
> initLimit=10
> syncLimit=5
> dataDir=/data/zkdata
>
> secureClientPort=2191
> serverCnxnFactory=org.apache.zookeeper.server.NettyServerCnxnFactory
> ssl.keyStore.location=/etc/zookeeper/ssl/server.jks
> ssl.keyStore.password=password
> ssl.trustStore.location=/etc/zookeeper/ssl/servertrust.jks
> ssl.trustStore.password=password
>
> These are the main options you can choose from, when configuring client
> SSL:
>
> - option 1: only unsecure (this is when you specify only the clientPort in
> the zoo.cfg)
> - option 2: only SSL (I think this is what you want... this happens if you
> don't specify clientPort in the zoo.cfg, but you specify the
> secureClientPort. Of course in this case you also have to set a few other
> parameters, like setting the serverCnxnFactory to netty and defining the
> ssl.keyStore / ssl.trustStore locations and passwords - see the example
> above)
> - option 3: both secure and unsecure client connections on different server
> ports (this happens when you set both the clientPort and
> the secureClientPort in the zoo.cfg to different ports)
> - option 4: both secure and unsecure client connections using the same
> server port (this happens when you set the 'client.portUnification=true' in
> the config file and set the clientPort in the zoo.cfg. In this case the
> clientPort will be able to serve both unsecure and SSL connections. Of
> course, in this case you still have to set the other SSL related
> parameters, like the serverCnxnFactory and the ssl.keyStore /
> ssl.trustStore locations and passwords)
>
> AFAIK, the option 4 is not available yet in any released 3.5 version. It
> will be part of the first 3.6 release candidate soon. Also there is a
> backport PR for it just under review (
> https://github.com/apache/zookeeper/pull/1174) so it's likely to be in the
> next 3.5.7 release, if / whenever that will happen.
>
> Regards,
> Mate
>
> On Thu, Dec 12, 2019 at 2:31 PM Chris T.  wrote:
>
> > Hi,
> >
> > we're working on securing our clusters. For quorum, once we set
> > sslQuorum=true, there is no more unsecured quorum port.
> > Is such an option available or in the works for the client port as well ?
> > Or is ssl client port always in addition to unsecured client port ?
> >
> > Regards,
> >
> > Chris
> >
>

Re: quorum.cnxn.threads.size

[Flavio Junqueira]

If it is just logging the value of the property, then it is fine because the 
property is set, but it is not used if SASL is disabled.

-Flavio

> On 12 Dec 2019, at 16:01, rammohan ganapavarapu  
> wrote:
> 
> Flavio,
> 
> Thanks for clarification, I have a cluster with sasl disabled but in start
> up log I still see number of threads set to default 20.
> 
> Thanks,
> Ram
> On Thu, Dec 12, 2019, 6:43 AM Flavio Junqueira  wrote:
> 
>> Hi Ram,
>> 
>> Yes, this parameter is only applicable when SASL is enabled, see in
>> QuorumCnxManager#initializeAuth how it doesn't have a chance to use the
>> parameter when SASL is disabled.
>> 
>> Your assessment is correct about it being based on the number of
>> participants, excluding observers. This parameter is used in
>> QuorumCnxManager, which manages connections for leader election, and
>> observers do not participate in the election.
>> 
>> -Flavio
>> 
>>> On 12 Dec 2019, at 14:41, rammohan ganapavarapu 
>> wrote:
>>> 
>>> Any idea?
>>> 
>>> On Wed, Dec 11, 2019, 2:23 PM rammohan ganapavarapu <
>> rammohanga...@gmail.com>
>>> wrote:
>>> 
 And to add more on the same property, the description says
 
 
 
 
 
 *"For example, consider a 3-node cluster,# during quorum formation at
 least 3 outgoing connection requests and 3 incoming connection# requests
 will occur. So total 6 threads will be used. It is recommended to
>> configure
 2x# number of threads for smooth execution, where 'x' represents the
 cluster size"*
 
 Here* cluster size* is number of *followers* right not both followers
>> and
 observers??
 
 Ram
 
 On Wed, Dec 11, 2019 at 2:19 PM rammohan ganapavarapu <
 rammohanga...@gmail.com> wrote:
 
> Is this property only applicable in case of sasl auth enabled? or does
>> it
> work even when we turn off authentication?
> 
> 
> *quorum.cnxn.threads.size*
> 
> Thanks,
> Ram
> 
 
>> 
>> 

Re: quorum.cnxn.threads.size

[rammohan ganapavarapu]

Flavio,

Thanks for clarification, I have a cluster with sasl disabled but in start
up log I still see number of threads set to default 20.

Thanks,
Ram
On Thu, Dec 12, 2019, 6:43 AM Flavio Junqueira  wrote:

> Hi Ram,
>
> Yes, this parameter is only applicable when SASL is enabled, see in
> QuorumCnxManager#initializeAuth how it doesn't have a chance to use the
> parameter when SASL is disabled.
>
> Your assessment is correct about it being based on the number of
> participants, excluding observers. This parameter is used in
> QuorumCnxManager, which manages connections for leader election, and
> observers do not participate in the election.
>
> -Flavio
>
> > On 12 Dec 2019, at 14:41, rammohan ganapavarapu 
> wrote:
> >
> > Any idea?
> >
> > On Wed, Dec 11, 2019, 2:23 PM rammohan ganapavarapu <
> rammohanga...@gmail.com>
> > wrote:
> >
> >> And to add more on the same property, the description says
> >>
> >>
> >>
> >>
> >>
> >> *"For example, consider a 3-node cluster,# during quorum formation at
> >> least 3 outgoing connection requests and 3 incoming connection# requests
> >> will occur. So total 6 threads will be used. It is recommended to
> configure
> >> 2x# number of threads for smooth execution, where 'x' represents the
> >> cluster size"*
> >>
> >> Here* cluster size* is number of *followers* right not both followers
> and
> >> observers??
> >>
> >> Ram
> >>
> >> On Wed, Dec 11, 2019 at 2:19 PM rammohan ganapavarapu <
> >> rammohanga...@gmail.com> wrote:
> >>
> >>> Is this property only applicable in case of sasl auth enabled? or does
> it
> >>> work even when we turn off authentication?
> >>>
> >>>
> >>> *quorum.cnxn.threads.size*
> >>>
> >>> Thanks,
> >>> Ram
> >>>
> >>
>
>

Re: Disable non-secured client port

[Szalay-Bekő Máté]

Hi Chris,

The short answer is yes, all you need to do is don't specify the clientPort
in the zoo.cfg.

An example for the zoo.cfg in this case:

tickTime=3000
initLimit=10
syncLimit=5
dataDir=/data/zkdata

secureClientPort=2191
serverCnxnFactory=org.apache.zookeeper.server.NettyServerCnxnFactory
ssl.keyStore.location=/etc/zookeeper/ssl/server.jks
ssl.keyStore.password=password
ssl.trustStore.location=/etc/zookeeper/ssl/servertrust.jks
ssl.trustStore.password=password

These are the main options you can choose from, when configuring client SSL:

- option 1: only unsecure (this is when you specify only the clientPort in
the zoo.cfg)
- option 2: only SSL (I think this is what you want... this happens if you
don't specify clientPort in the zoo.cfg, but you specify the
secureClientPort. Of course in this case you also have to set a few other
parameters, like setting the serverCnxnFactory to netty and defining the
ssl.keyStore / ssl.trustStore locations and passwords - see the example
above)
- option 3: both secure and unsecure client connections on different server
ports (this happens when you set both the clientPort and
the secureClientPort in the zoo.cfg to different ports)
- option 4: both secure and unsecure client connections using the same
server port (this happens when you set the 'client.portUnification=true' in
the config file and set the clientPort in the zoo.cfg. In this case the
clientPort will be able to serve both unsecure and SSL connections. Of
course, in this case you still have to set the other SSL related
parameters, like the serverCnxnFactory and the ssl.keyStore /
ssl.trustStore locations and passwords)

AFAIK, the option 4 is not available yet in any released 3.5 version. It
will be part of the first 3.6 release candidate soon. Also there is a
backport PR for it just under review (
https://github.com/apache/zookeeper/pull/1174) so it's likely to be in the
next 3.5.7 release, if / whenever that will happen.

Regards,
Mate

On Thu, Dec 12, 2019 at 2:31 PM Chris T.  wrote:

> Hi,
>
> we're working on securing our clusters. For quorum, once we set
> sslQuorum=true, there is no more unsecured quorum port.
> Is such an option available or in the works for the client port as well ?
> Or is ssl client port always in addition to unsecured client port ?
>
> Regards,
>
> Chris
>

Re: quorum.cnxn.threads.size

[Flavio Junqueira]

Hi Ram,

Yes, this parameter is only applicable when SASL is enabled, see in 
QuorumCnxManager#initializeAuth how it doesn't have a chance to use the 
parameter when SASL is disabled.

Your assessment is correct about it being based on the number of participants, 
excluding observers. This parameter is used in QuorumCnxManager, which manages 
connections for leader election, and observers do not participate in the 
election.

-Flavio 

> On 12 Dec 2019, at 14:41, rammohan ganapavarapu  
> wrote:
> 
> Any idea?
> 
> On Wed, Dec 11, 2019, 2:23 PM rammohan ganapavarapu 
> wrote:
> 
>> And to add more on the same property, the description says
>> 
>> 
>> 
>> 
>> 
>> *"For example, consider a 3-node cluster,# during quorum formation at
>> least 3 outgoing connection requests and 3 incoming connection# requests
>> will occur. So total 6 threads will be used. It is recommended to configure
>> 2x# number of threads for smooth execution, where 'x' represents the
>> cluster size"*
>> 
>> Here* cluster size* is number of *followers* right not both followers and
>> observers??
>> 
>> Ram
>> 
>> On Wed, Dec 11, 2019 at 2:19 PM rammohan ganapavarapu <
>> rammohanga...@gmail.com> wrote:
>> 
>>> Is this property only applicable in case of sasl auth enabled? or does it
>>> work even when we turn off authentication?
>>> 
>>> 
>>> *quorum.cnxn.threads.size*
>>> 
>>> Thanks,
>>> Ram
>>> 
>> 

Re: quorum.cnxn.threads.size

[rammohan ganapavarapu]

Any idea?

On Wed, Dec 11, 2019, 2:23 PM rammohan ganapavarapu 
wrote:

> And to add more on the same property, the description says
>
>
>
>
>
> *"For example, consider a 3-node cluster,# during quorum formation at
> least 3 outgoing connection requests and 3 incoming connection# requests
> will occur. So total 6 threads will be used. It is recommended to configure
> 2x# number of threads for smooth execution, where 'x' represents the
> cluster size"*
>
> Here* cluster size* is number of *followers* right not both followers and
> observers??
>
> Ram
>
> On Wed, Dec 11, 2019 at 2:19 PM rammohan ganapavarapu <
> rammohanga...@gmail.com> wrote:
>
>> Is this property only applicable in case of sasl auth enabled? or does it
>> work even when we turn off authentication?
>>
>>
>> *quorum.cnxn.threads.size*
>>
>> Thanks,
>> Ram
>>
>

Disable non-secured client port

[Chris T.]

Hi,

we're working on securing our clusters. For quorum, once we set
sslQuorum=true, there is no more unsecured quorum port.
Is such an option available or in the works for the client port as well ?
Or is ssl client port always in addition to unsecured client port ?

Regards,

Chris

Re: ZK makes apache 2019 "top 5" projects

[Jordan Zimmerman]

Fantastic 


Jordan Zimmerman

> On Dec 12, 2019, at 3:49 AM, Flavio Junqueira  wrote:
> 
> +1, thank you all for the hard work.
> 
> -Flavio
> 
>> On 12 Dec 2019, at 08:36, Enrico Olivelli  wrote:
>> 
>> Yes, great.
>> 
>> Please also note that Kafka and Lucene/Solr that are still listed in that
>> list  are using Zookeeper :)
>> 
>> 
>> Enrico
>> 
>> Il gio 12 dic 2019, 05:46 tison  ha scritto:
>> 
>>> Kudos!
>>> 
>>> Best,
>>> tison.
>>> 
>>> 
>>> Patrick Hunt  于2019年12月12日周四 上午11:32写道：
>>> 
 This is really awesome, check it out:
 https://twitter.com/phunt/status/1204966326118141952
 
 Kudos ZooKeeper community on all the hard work and efforts!
 
 Patrick
 
>>> 
> 

Re: Zookeeper SSL C Client Support

[Szalay-Bekő Máté]

Hi Pradeep,

based on the logs, it seems working. It is great to see that you will use
it :) Let us know if you would see any issue with it.

FYI, we already have a few improvements under review around these areas:
- https://issues.apache.org/jira/browse/ZOOKEEPER-3567 (Add SSL support for
the zk python client)
- https://issues.apache.org/jira/browse/ZOOKEEPER-3630 (Autodetection of
SSL library during Zookeeper C client build)
- https://issues.apache.org/jira/browse/ZOOKEEPER-3640 (Implement "batch
mode" in cli_mt)

I also created this improvement idea:
https://issues.apache.org/jira/browse/ZOOKEEPER-3646, "Executing multiple
commands non-interactively with the C client cli "
No one is working on it right now AFAIK, but let me know if it would be
important / helpful for you.

Regards,
Mate

On Thu, Dec 12, 2019 at 8:07 AM Pradeep Choudhary
 wrote:

> Hi Enrico,
>
> I have just tested the cli_st utility as of now. It seems to work ok. I
> haven't integrated this code in our software yet.  Please check the logs
> below.
>
>
> git clone g...@github.com:apache/zookeeper.git
> cd zookeeper
> yum install java-1.8.0-openjdk
> yum install ant
> yum install autoconf
> yum install automake
> yum install cppunit
> yum install cppunit-devel
> ant compile_jute
> cd zookeeper-client/zookeeper-client-c/
> ./configure
> vi Makefile
> ** Uncomment following 2 lines and set OPENSSL_DIR **
> #OPENSSL_CPPFLAGS = -DHAVE_OPENSSL_H -I$(OPENSSL_DIR)
> #OPENSSL_LIB_LDFLAGS = -lssl -lcrypto
> make
> make install
>
>
> Run cli_st utility
> [root@noden9 zookeeper-client-c]# ./cli_st -h 127.0.0.1:2182 -s
> /root/zookeeper_tls/zookeeper+tls/ca-cert.pem,/root/zookeeper_tls/zookeeper+tls/server.pem,/root/zookee
> per_tls/zookeeper+tls/server-privkey.pem,c0ntrail123 -d
> logging level set to DEBUG
> 2019-12-06 23:30:03,005:26406:ZOO_INFO@log_env@1147: Client
> environment:zookeeper.version=zookeeper C client 3.6.0
> 2019-12-06 23:30:03,005:26406:ZOO_INFO@log_env@1151: Client environment:
> host.name=noden9
> 2019-12-06 23:30:03,005:26406:ZOO_INFO@log_env@1158: Client environment:
> os.name=Linux
> 2019-12-06 23:30:03,005:26406:ZOO_INFO@log_env@1159: Client
> environment:os.arch=3.10.0-1062.1.2.el7.x86_64
> 2019-12-06 23:30:03,005:26406:ZOO_INFO@log_env@1160: Client
> environment:os.version=#1 SMP Mon Sep 30 14:19:46 UTC 2019
> 2019-12-06 23:30:03,005:26406:ZOO_INFO@log_env@1168: Client environment:
> user.name=root
> 2019-12-06 23:30:03,005:26406:ZOO_INFO@log_env@1176: Client
> environment:user.home=/root
> 2019-12-06 23:30:03,005:26406:ZOO_INFO@log_env@1188: Client
> environment:user.dir=/root/zookeeper_tls/zookeeper/zookeeper-client/zookeeper-client-c
> 2019-12-06 23:30:03,005:26406:ZOO_INFO@zookeeper_init_internal@1241:
> Initiating client connection, host=127.0.0.1:2182 sessionTimeout=3
> watcher=0x402640 sessionId=
> 0 sessionPasswd= context=(nil) flags=0
> 2019-12-06 23:30:03,005:26406:ZOO_DEBUG@get_next_server_in_reconfig@1401:
> [OLD] count=0 capacity=0 next=0 hasnext=0
> 2019-12-06 23:30:03,005:26406:ZOO_DEBUG@get_next_server_in_reconfig@1404:
> [NEW] count=1 capacity=16 next=0 hasnext=1
> 2019-12-06 23:30:03,005:26406:ZOO_DEBUG@get_next_server_in_reconfig@1413:
> Using next from NEW=127.0.0.1:2182
> 2019-12-06 23:30:03,005:26406:ZOO_DEBUG@zookeeper_connect@2319: [zk]
> connect()
>
> 2019-12-06 23:30:03,006:26406:ZOO_INFO@init_ssl_for_socket@2592: FIPS
> mode is OFF
> 2019-12-06 23:30:03,019:26406:ZOO_INFO@check_events@2737: initiated
> connection to server 127.0.0.1:2182
> 2019-12-06 23:30:03,046:26406:ZOO_INFO@check_events@2790: session
> establishment complete on server 127.0.0.1:2182,
> sessionId=0x100e87594e50004, negotiated timeout=3000
> 0
> 2019-12-06 23:30:03,046:26406:ZOO_DEBUG@check_events@2796: Calling a
> watcher for a ZOO_SESSION_EVENT and the state=ZOO_CONNECTED_STATE
> 2019-12-06 23:30:03,046:26406:ZOO_DEBUG@process_completions@3062: Calling
> a watcher for node [], type = -1 event=ZOO_SESSION_EVENT
> Watcher SESSION_EVENT state = CONNECTED_STATE
> Got a new session id: 0x100e87594e50004
>
>
>
>
> On 12/12/19, 12:13 PM, "Enrico Olivelli"  wrote:
>
> Pradeep
>
> Il gio 12 dic 2019, 07:02 Pradeep Choudhary  .invalid>
> ha scritto:
>
> > Dear Experts,
> >
> > I see that this PR https://github.com/apache/zookeeper/pull/625 is
> merged
> > to master to enable Zookeeper C Client SSL support. We are planning
> to use
> > this in our software. Do you have any plan to release a new version
> of
> > Zookeeper with this support ?
> >
>
> Yes.
>
> Did you try it?
> Knowing that it works for you would be a great feedback
>
> Stay tuned.
> Please test the release candidate of 3.6.0 when we will start a VOTE on
> d...@zookeeper.apache.org
>
> It will happen within a couple of weeks.
> I
>
> >
> > Thanks,
> > Pradeep
> >
>
>
>

Re: ZK makes apache 2019 "top 5" projects

[Flavio Junqueira]

+1, thank you all for the hard work.

-Flavio

> On 12 Dec 2019, at 08:36, Enrico Olivelli  wrote:
> 
> Yes, great.
> 
> Please also note that Kafka and Lucene/Solr that are still listed in that
> list  are using Zookeeper :)
> 
> 
> Enrico
> 
> Il gio 12 dic 2019, 05:46 tison  ha scritto:
> 
>> Kudos!
>> 
>> Best,
>> tison.
>> 
>> 
>> Patrick Hunt  于2019年12月12日周四 上午11:32写道：
>> 
>>> This is really awesome, check it out:
>>> https://twitter.com/phunt/status/1204966326118141952
>>> 
>>> Kudos ZooKeeper community on all the hard work and efforts!
>>> 
>>> Patrick
>>> 
>>