As the name says, "quorum.auth.kerberos.servicePrincipal" property is
specifically for Kerberos based quorum authentication and no need to set
anything if you are enabling digest-md5.
Like mentioned earlier, its default value is "zkquorum/localhost" and it
will never be used if you
Thanks a lot for the invesrtigation. I did not find again the time to
install it somewhere. I observed the issue with 3.5.5
On Tue, Dec 17, 2019 at 6:58 PM Andor Molnar wrote:
> "We were using early 3.5.3 or something like that.”
>
> Netty stack had a major refactor in 3.5.5
>
> Andor
>
>
>
> >
"We were using early 3.5.3 or something like that.”
Netty stack had a major refactor in 3.5.5
Andor
> On 2019. Dec 17., at 16:40, Enrico Olivelli wrote:
>
> Il giorno mar 17 dic 2019 alle ore 16:26 Szalay-Bekő Máté <
> szalay.beko.m...@gmail.com> ha scritto:
>
>> I added a comment on Jira.
Il giorno mar 17 dic 2019 alle ore 16:26 Szalay-Bekő Máté <
szalay.beko.m...@gmail.com> ha scritto:
> I added a comment on Jira. This is something we will also need to fix in my
> company soon.
>
> @enrico you wrote:
> > in my company we set up some ZK with TLS and SASL, using TLS for
>
I added a comment on Jira. This is something we will also need to fix in my
company soon.
@enrico you wrote:
> in my company we set up some ZK with TLS and SASL, using TLS for
encryption and SASL for auth. We were using early 3.5.3 or something like
that.
According to this, the scenario should
Hi Jorn,
Sorry for coming back late to this. I’ve just validated the scenario on my test
cluster. Looks like the issue is valid: Kerberos auth and SSL are mutually
exclusive currently. When Kerberos is set up and trying to connect to secure
port I got an infinite loop on client side:
