Hello Dan Burkert, Jean-Daniel Cryans, Kudu Jenkins,
I'd like you to reexamine a change. Please visit
http://gerrit.cloudera.org:8080/5922
to look at the new patch set (#3).
Change subject: java: fix ability to connect to a real Kerberized cluster
......................................................................
java: fix ability to connect to a real Kerberized cluster
This fixes a couple issues seen when I tried to run the Java client
from within Impala against a Kerberized Kudu cluster:
* Previously, the ServerInfo class remembered the already-resolved
address of the server rather than its hostname. This meant that we
would try to connect to a Kerberos principal "kudu/1.2.3.4" rather
than "kudu/foo.example.com". This typically would not match the actual
principal the server was using, resulting in an error that the server
principal was not found in the database.
* We previously were using 'subject.doAs()' when initializing the SASL
server, but not when evaluating challenges. It turns out that the
GSSAPI mechanism only looks for the Kerberos credentials while
evaluating the challenge. This moves the 'doAs()' to wrap the
challenge.
* Another issue with the SASL setup was that we were passing all of the
available client mechanisms into Sasl.createSaslClient() before seeing
which mechanisms the server was advertised. the SASL library seems to
always prefer GSSAPI over PLAIN when available. This meant that, if
the server had Kerberos credentials, it would attempt to use GSSAPI
and not PLAIN even if connecting to a server which only advertised
plain. This fixes the negotiation to no longer ignore the server-side
advertised mechanisms, and instead actually negotiate by picking the
best mechanism which is both advertised by the server and
initializable by the client.
* We previously assumed that Kerberos credentials would be available
from the 'Subject' without any explicit login call. This isn't the
case: we have to explicitly set up a LoginContext and Configuration to
log in from the credentials cache. This changes the client constructor
to login from the ccache if there is no Subject available with
Kerberos credentials.
With these changes I was able to run an Impala query against a cluster
with -server_require_kerberos.
Change-Id: I6b96fad3cfb40500d7a75e5070ea21bc8e00cbd8
---
M java/kudu-client/src/main/java/org/apache/kudu/client/AsyncKuduClient.java
M java/kudu-client/src/main/java/org/apache/kudu/client/ConnectionCache.java
M java/kudu-client/src/main/java/org/apache/kudu/client/SecureRpcHelper.java
M java/kudu-client/src/main/java/org/apache/kudu/client/ServerInfo.java
A java/kudu-client/src/main/java/org/apache/kudu/util/SecurityUtil.java
M java/kudu-client/src/test/java/org/apache/kudu/client/MiniKdc.java
M java/kudu-client/src/test/java/org/apache/kudu/client/MiniKuduCluster.java
M java/kudu-client/src/test/java/org/apache/kudu/client/TestConnectionCache.java
M java/kudu-client/src/test/java/org/apache/kudu/client/TestMiniKdc.java
M java/kudu-client/src/test/java/org/apache/kudu/client/TestMiniKuduCluster.java
M java/kudu-client/src/test/java/org/apache/kudu/client/TestRemoteTablet.java
11 files changed, 281 insertions(+), 129 deletions(-)
git pull ssh://gerrit.cloudera.org:29418/kudu refs/changes/22/5922/3
--
To view, visit http://gerrit.cloudera.org:8080/5922
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I6b96fad3cfb40500d7a75e5070ea21bc8e00cbd8
Gerrit-PatchSet: 3
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-Owner: Todd Lipcon <t...@apache.org>
Gerrit-Reviewer: Dan Burkert <danburk...@apache.org>
Gerrit-Reviewer: Jean-Daniel Cryans <jdcry...@apache.org>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Todd Lipcon <t...@apache.org>
