"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 <eolive...@gmail.com> 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. 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. >> > > Unfortunately we do not have that setup anymore, we had to drop it because > at that time (and still nowadays) from the same JVMs we had also to connect > to an HBase cluster with ZK 3.4 > that does not support TLS. > > Currently we are using only SASL and not TLS > Sorry > > Enrico > > >> >> According to this, the scenario should work. Maybe we just misconfigured >> something, or this was something got broken in a later version? Can you >> share the config you use? Maybe you are setting `zookeeper.ssl.clientAuth` >> and `zookeeper.ssl.quorum.clientAuth` to `none` or `want` ? >> >> Regards, >> Mate >> >> On Tue, Dec 17, 2019 at 10:48 AM Andor Molnar <an...@apache.org> wrote: >> >>> 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: >>> >>> 2019-12-17 01:43:30,984 [myid:barbaresco-1.vpc.cloudera.com:2182] - WARN >>> [Thread-39:Login$1@197] - TGT renewal thread has been interrupted and >>> will exit. >>> 2019-12-17 01:43:30,987 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO >>> [main-SendThread(barbaresco-1.vpc.cloudera.com:2182):Login@302] - Client >>> successfully logged in. >>> 2019-12-17 01:43:30,987 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO >>> [Thread-40:Login$1@135] - TGT refresh thread started. >>> 2019-12-17 01:43:30,987 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO >>> [main-SendThread(barbaresco-1.vpc.cloudera.com:2182):SecurityUtils$1@124 >> ] >>> - Client will use GSSAPI as SASL mechanism. >>> 2019-12-17 01:43:30,988 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO >>> [main-SendThread(barbaresco-1.vpc.cloudera.com:2182 >>> ):ClientCnxn$SendThread@1112] - Opening socket connection to server >>> barbaresco-1.vpc.cloudera.com/10.65.25.98:2182. Will attempt to >>> SASL-authenticate using Login Context section 'Client' >>> 2019-12-17 01:43:30,988 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO >>> [main-SendThread(barbaresco-1.vpc.cloudera.com:2182 >>> ):ClientCnxn$SendThread@959] - Socket connection established, initiating >>> session, client: /10.65.25.98:45362, server: >>> barbaresco-1.vpc.cloudera.com/10.65.25.98:2182 >>> 2019-12-17 >>> <http://barbaresco-1.vpc.cloudera.com/10.65.25.98:21822019-12-17> >>> 01:43:30,989 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO >>> [Thread-40:Login@320] - TGT valid starting at: Tue Dec 17 >> 01:43:30 >>> PST 2019 >>> 2019-12-17 01:43:30,989 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO >>> [Thread-40:Login@321] - TGT expires: Thu Jan 16 >> 01:43:30 >>> PST 2020 >>> 2019-12-17 01:43:30,989 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO >>> [Thread-40:Login$1@193] - TGT refresh sleeping until: Fri Jan 10 >> 20:23:33 >>> PST 2020 >>> 2019-12-17 01:43:30,989 [myid:barbaresco-1.vpc.cloudera.com:2182] - INFO >>> [main-SendThread(barbaresco-1.vpc.cloudera.com:2182 >>> ):ClientCnxn$SendThread@1240] - Unable to read additional data from >>> server sessionid 0x0, likely server has closed socket, closing socket >>> connection and attempting reconnect >>> >>> And the following error on server side: >>> >>> 2019-12-17 01:43:33,002 INFO >>> org.apache.zookeeper.server.NettyServerCnxnFactory: SSL handler added for >>> channel: [id: 0xcf37c14b, L:/10.65.25.98:2182 - R:/10.65.25.98:45380] >>> 2019-12-17 01:43:33,003 ERROR >>> org.apache.zookeeper.server.NettyServerCnxnFactory: Unsuccessful >> handshake >>> with session 0x0 >>> 2019-12-17 01:43:33,003 WARN >>> org.apache.zookeeper.server.NettyServerCnxnFactory: Exception caught >>> io.netty.handler.codec.DecoderException: >>> io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record: >>> >> 0000002d000000000000000000000000000075300000000000000000000000100000000000000000000000000000000000 >>> at >>> >> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:475) >>> at >>> >> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:283) >>> at >>> >> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374) >>> at >>> >> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360) >>> at >>> >> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352) >>> at >>> >> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1422) >>> at >>> >> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374) >>> at >>> >> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360) >>> at >>> >> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:931) >>> at >>> >> io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:792) >>> at >>> >> io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:483) >>> at >>> io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:383) >>> at >>> >> io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1044) >>> at >>> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) >>> at >>> >> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) >>> at java.lang.Thread.run(Thread.java:748) >>> >>> I will update the Jira too. >>> >>> Andor >>> >>> >>> >>> >>> >>>> On 2019. Nov 8., at 20:31, Jörn Franke <jornfra...@gmail.com> wrote: >>>> >>>> Thanks. Can you please share the configuration file? >>>> >>>> I tried with 3.5.5 - without SSL Kerberos works, but once I configured >>> client ssl it said authentication fail (I have to check if I can dig up >> the >>> log files) and as far as I remember this was related to x509 >>> authentication. The certificate and truststore themselves are fine (I >> think >>> I needed to convert the truststore to jks). >>>> Sorry it was some time ago, I should have separated the log files. >>>> For me it did not matter that the ports are separated, but it worked on >>> the non-ssl port fine. >>>> >>>>> Am 06.11.2019 um 23:08 schrieb Enrico Olivelli <eolive...@gmail.com>: >>>>> >>>>> Jorn, >>>>> IIRC 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. >>>>> >>>>> Do you have a specific error? >>>>> >>>>> I can also add that in 3.6.0 we will have port-unification, this way >> you >>>>> can configure only one client port and accept plain text and TLS >>> connection >>>>> from clients (this helps the ttransition to TLS) >>>>> >>>>> Enrico >>>>> >>>>> Il mer 6 nov 2019, 22:28 Jörn Franke <jornfra...@gmail.com> ha >> scritto: >>>>> >>>>>> Dear all, >>>>>> >>>>>> it seems that ZooKeeper 3.5 with SSL enabled does not support >> Kerberos >>>>>> authentication, but only X509 authentication. Kerberos is used in >> many >>>>>> Enterprise environments and is supported by Apache Solr. Is this a >>> bug? Or >>>>>> am I missing something? >>>>>> >>>>>> >>>>>> I created a Jira for this: >>>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-3482 >>>>>> >>>>>> >>>>>> thank you. >>>>>> >>>>>> best regards >>>>>> >>> >>> >>
