zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Wood <bw...@mesosphere.io>
Subject Re: Zookeeper client reverse lookup issue
Date Mon, 20 Nov 2017 23:11:59 GMT
Do you think a patch targeting 3.4.11 or 3.4.12 that backports this lookup
change (as minimally as possible) would be accepted?

In order to do ZK in containers (yes, slightly terrifying), it's not
_necessary_ but a lot easier!

On Mon, Nov 20, 2017 at 12:34 PM, Abraham Fine <afine@apache.org> wrote:

> Hi Ben-
>
> Unfortunately 3.5 is still in beta and not recommended for production.
>
> Thanks,
> Abe
>
> On Mon, Nov 20, 2017, at 11:13, Ben Wood wrote:
> > Hey Abraham,
> >
> > We've been using 3.4.11.[
> >
> > That's great news the reverse lookup has already been taken out in 3.5!
> > We
> > found another ticket https://issues.apache.org/
> jira/browse/ZOOKEEPER-2858
> > that suggested there were some workarounds but hadn't found that one (and
> > hadn't had a chance to test 3.5).
> >
> > This raises an interesting question for us, admitted ZK neophytes, is ZK
> > 3.5 "safe" to use in production?
> >
> > On Fri, Nov 17, 2017 at 3:11 PM, Abraham Fine <afine@apache.org> wrote:
> >
> > > This change occurred due to
> > > https://issues.apache.org/jira/browse/ZOOKEEPER-2171
> > >
> > > On Fri, Nov 17, 2017, at 15:10, Abraham Fine wrote:
> > > > Hi Ben-
> > > >
> > > > What version of ZooKeeper are you using? In my testing it looks like
> 3.4
> > > > does a reverse lookup when creating the server principal
> > > > (https://github.com/apache/zookeeper/blob/branch-3.4/src/
> > > java/main/org/apache/zookeeper/ClientCnxn.java#L1011)
> > > > but 3.5/master do not
> > > > (https://github.com/apache/zookeeper/blob/branch-3.5/src/
> > > java/main/org/apache/zookeeper/ClientCnxn.java#L1104).
> > > >
> > > > Let me know if that helps.
> > > >
> > > > Thanks,
> > > > Abe
> > > >
> > > > On Fri, Nov 17, 2017, at 12:01, Ben Wood wrote:
> > > > > Hey Folks,
> > > > >
> > > > > My team and I are working on a containerized Zookeeper service on
> top
> > > of
> > > > > DC/OS. We're running into an issue with Kerberos in the following
> > > > > scenario.
> > > > >
> > > > > Simplified, we have a zk server with the DNS address zk-server.dcos
> > > (e.g.
> > > > > the dns address of the ZK task) and actual hostname zk-server.aws
> > > > > (Shortened here, but really a standard resolvable AWS private dns
> > > > > address)
> > > > > and a kafka broker, kafka.dcos.
> > > > >
> > > > > We can easily setup our Zookeeper and Kafka services to work
> together,
> > > > > until we try to enable Kerberos. ZK itself works just fine with
> > > Kerberos,
> > > > > but the Kafka broker is not able to connect to the ZK server:
> > > > >
> > > > > 0. kafka.dcos is started with a zk server list of zk-server.dcos.
> > > > > 1. kafka.dcos starts up, initializing its ZK client.
> > > > > 2. kafka.dcos then attempts to retrieve a ticket from the KDC in
> order
> > > to
> > > > > talk to zk-server.aws, however the only zk principal known to the
> kdc
> > > is
> > > > > zk-server.dcos.
> > > > >
> > > > > From reading the source (
> > > > > https://github.com/apache/zookeeper/blob/master/src/
> > > java/main/org/apache/zookeeper/client/StaticHostProvider.java#L112)
> > > > > it appears that the zk client is winding up with the actual
> hostname of
> > > > > the
> > > > > ZK server.
> > > > >
> > > > > Being new to the codebase, is this because of a client reverse
> lookup?
> > > Or
> > > > > because the zk server is telling the client about its hostname? It
> > > > > appears
> > > > > to be the former.
> > > > >
> > > > > Thanks!
> > > > > Ben
> > >
> >
> >
> >
> > --
> > Ben Wood
> > Software Engineer - Data Agility
> > Mesosphere
>



-- 
Ben Wood
Software Engineer - Data Agility
Mesosphere

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message