[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16632211#comment-16632211
 ] 

Robert Joseph Evans commented on ZOOKEEPER-3156:
------------------------------------------------

[~andorm],

Sorry I was on a plane all day yesterday so I didn't respond sooner.  I have 
been doing some debugging trying to get a patch, but I have not come up with 
one yet.  I originally wanted to see if I could match the behavior from before 
by moving the host name resolution code later in the process, but despite the 
data structures being the same it is not possible as some information is lost 
in the current process.  I think having a flag that would optionally call 
{{getCannicalHostName}} would be great. If someone else has a patch I am happy 
to test it out, otherwise I will put together a patch myself.

Be aware though that a global flag is not 100% backwards compatible, and there 
is a very small possibility that a single process will want to talk to multiple 
different zookeeper ensembles, i.e. apache storm + older kafka client, which 
could run into an issue where each ensemble wants something different.  It is a 
small enough chance, and there are ways to work around it so I am fine with it, 
but it is possible.

 

 

> ZOOKEEPER-2184 causes kerberos principal to not have resolved host name
> -----------------------------------------------------------------------
>
>                 Key: ZOOKEEPER-3156
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3156
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: java client
>    Affects Versions: 3.6.0, 3.4.13, 3.5.5
>            Reporter: Robert Joseph Evans
>            Assignee: Robert Joseph Evans
>            Priority: Blocker
>
> Prior to ZOOKEEPER-2184 the zookeeper client would canonicalize a configured 
> host name before creating the SASL client which is used to create the 
> principal name.  After ZOOKEEPER-2184 that canonicalization does not happen 
> so the principal that the ZK client tries to use when it is configured to 
> talk to a CName is different between 3.4.13 and all previous versions of ZK.
>  
> For example
>  
> zk1.mycluster.mycompany.com maps to real-node.mycompany.com.
>  
> 3.4.13 will want the server to have 
> [zookeeper/zk1.mycluster....@kdc.mycompany.com|mailto:zookeeper/zk1.mycluster....@kdc.mycompany.com]
> 3.4.12 wants the server to have 
> [zookeeper/real-node.mycompany....@kdc.mycompany.com|mailto:zookeeper/real-node.mycompany....@kdc.mycompany.com]
>  
> This makes 3.4.13 incompatible with many ZK setups currently in existence.  
> It would be nice to have that resolution be optional because in some cases it 
> might be nice to have a single principal tied to the cname.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to