- Subscribe to RSS Feed
- Mark Question as New
- Mark Question as Read
- Float this Question for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Impala JDBC with username & password Does not work[Non-Kerberos & Non LDAP]
- Labels:
-
Apache Impala
Created on ‎01-07-2017 09:19 AM - edited ‎09-16-2022 03:53 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I need to implement the JDBC connection for Impala with username and password[I guess here username=host user on which Impala daemon is running and Password=corresponding user password] for our client cluster. As per my understanding we do not need to make any specific change in Impala server configs or on server for the same.
What I tried:
1. Cluster is without Kerberos.
2, Tried two types of drivers.
a] Driver Type 1]
JDBC:hive2 - When I uses connection string;
DriverManager.getConnection("jdbc:hive2://server:21050/default;","hostuser","password").
It does not work at all and ends in connection timeout.
When I uses connection string;
DriverManager.getConnection("jdbc:hive2://server:21050/default;auth=noSasl;")
It works and gets connected to impala.
b] Driver Type 2]
JDBC:impala -
When I uses connection string;
DriverManager.getConnection("jdbc:impala://Server:21050/default;AuthMech=3;UID=hostuser;PWD=password")
It does not work at all and ends in connection timeout.
When I uses connection string;
DriverManager.getConnection("jdbc:impala://Server:21050/default;AuthMech=0;")
It works and gets connected to impala.
Questions:
1. For Implementing the Impala JDBC username & password based connection, is it mandatory to have either Kerberos or LDAP or Sentry Implented?
2. If not, then using JDBC with Impala local user credentials does need any additional parameters or change at the server level or change in Impala local user permission?
3. Can you please provide any example to implement it, like any server level or client level changes if my implementation is wrong.
Thank you in advance.
Amit
Created ‎01-09-2017 12:38 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. For Implementing the Impala JDBC username & password based connection, is it mandatory to have either Kerberos or LDAP or Sentry Implented?
You need to have LDAP auth enabled for Impala.
2. If not, then using JDBC with Impala local user credentials does need any additional parameters or change at the server level or change in Impala local user permission?
No changes to Impala or the local user beyond installing and configuring the JDBC driver and connection.
3. Can you please provide any example to implement it, like any server level or client level changes if my implementation is wrong.
Driver type1
Impala with LDAP
DriverManager.getConnection("jdbc:hive2://server:21050/default;auth=noSasl;","hostuser","password")
Impala without any auth
DriverManager.getConnection("jdbc:hive2://server:21050/default;auth=noSasl;")
Note: noSasl is required when SSL is not configured
Driver type2
Impala with LDAP
DriverManager.getConnection("jdbc:impala://Server:21050/default;AuthMech=3;UID=hostuser;PWD=password")
Impala with Kerberos
DriverManager.getConnection("jdbc:impala://Server:21050/default;AuthMech=1;)
Impala with Kerberos and SSL
DriverManager.getConnection("jdbc:impala://Server:21050/;AuthMech=1;KrbRealm=REALM.COM;KrbHostFQDN=Server.REALM.COM;KrbServiceName=impala;SSL=1;SSLTrustStore=C:\Users\mbigelow\.ssl\bdp3-prd-ts.jks;SSLTrustSTorePwd=*****;
Impala without any auth
DriverManager.getConnection("jdbc:impala://Server:21050/default;AuthMech=0;")
I think AuthMech could be left off here as it should be the default.
Cloudera has plenty of documents covering enabling Kerberos and LDAP, although both should be considered well before delving into them.
Created ‎01-09-2017 12:38 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. For Implementing the Impala JDBC username & password based connection, is it mandatory to have either Kerberos or LDAP or Sentry Implented?
You need to have LDAP auth enabled for Impala.
2. If not, then using JDBC with Impala local user credentials does need any additional parameters or change at the server level or change in Impala local user permission?
No changes to Impala or the local user beyond installing and configuring the JDBC driver and connection.
3. Can you please provide any example to implement it, like any server level or client level changes if my implementation is wrong.
Driver type1
Impala with LDAP
DriverManager.getConnection("jdbc:hive2://server:21050/default;auth=noSasl;","hostuser","password")
Impala without any auth
DriverManager.getConnection("jdbc:hive2://server:21050/default;auth=noSasl;")
Note: noSasl is required when SSL is not configured
Driver type2
Impala with LDAP
DriverManager.getConnection("jdbc:impala://Server:21050/default;AuthMech=3;UID=hostuser;PWD=password")
Impala with Kerberos
DriverManager.getConnection("jdbc:impala://Server:21050/default;AuthMech=1;)
Impala with Kerberos and SSL
DriverManager.getConnection("jdbc:impala://Server:21050/;AuthMech=1;KrbRealm=REALM.COM;KrbHostFQDN=Server.REALM.COM;KrbServiceName=impala;SSL=1;SSLTrustStore=C:\Users\mbigelow\.ssl\bdp3-prd-ts.jks;SSLTrustSTorePwd=*****;
Impala without any auth
DriverManager.getConnection("jdbc:impala://Server:21050/default;AuthMech=0;")
I think AuthMech could be left off here as it should be the default.
Cloudera has plenty of documents covering enabling Kerberos and LDAP, although both should be considered well before delving into them.
Created ‎01-09-2017 03:26 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was using openLdap ldap_baseDN like cn=test,ou=xyz,dc=impalabigdata,dc=net, when I changed it as ou=xyz,dc=impalabigdata,dc=net
and used the JDBC connection as
jdbc:hive2://server:21050/default;","test","ldappwd", it worked for me.
Thanks a lot for providing a complete details, as currently these things didn't get clarified in existing documentation.
Thanks,
Amit
