Member since
β11-14-2017
18
Posts
3
Kudos Received
1
Solution
My Accepted Solutions
Title | Views | Posted |
---|---|---|
6868 | β03-21-2018 05:48 AM |
β07-23-2018
11:15 PM
keytab file was generated on server side. Anyway the issue is solved, the machine where the ODBC client was being developed had /etc/krb5.conf and /etc/hosts both wrong. Anyway thank you for your reply π
... View more
β03-21-2018
05:48 AM
1 Kudo
Hello everybody, The settings we provided the app developers in the client side was right, they had some problem with /etc/hosts configuration making them to not authenticating properly to the KDC server, also, they had a bad /etc/krb5.conf. With that I close this topic
... View more
β03-20-2018
08:01 AM
Hello,
We have a kerberized clΓΊster and a user of us tells that the next setting on the ODBC for Impala is not working
impala <- src_impala(
drv = drv,
driver = "/opt/cloudera/impalaodbc/lib/64/libclouderaimpalaodbc64.so",
host = "hostname",
port = 21050,
database = "publication",
KrbRealm = "CLOUDERA",
KrbFQDN = "hostname",
KrbServiceName = "impala",
AuthMech = 1,
UseKeytab = 1,
UPNKeytabMappingFile = "/home/gentrif/talend.keytab"
)
Looking into the documentation I told them to use the next setting
impala <- src_impala(
drv = drv,
driver = "/opt/cloudera/impalaodbc/lib/64/libclouderaimpalaodbc64.so",
host = "hostname",
port = 21050,
database = "publication",
KrbRealm = "CLOUDERA",
KrbFQDN = "hostname",
KrbServiceName = "impala",
AuthMech = 1,
UseKeytab = 1,
DefaultKeytabFile = "/home/gentrif/talend.keytab"
uid = "principal"
)
As the user tells us this last configuration is not working for their application.
Maybe we are forgeting something important.
Thank you in advance
... View more
Labels:
- Labels:
-
Apache Impala
-
Kerberos
β12-13-2017
04:00 AM
We surpassed the error just configuring Cloudera to authenticate to a local KDC, we were using a KDC provided by WSO2, this problem got solved but not with the scenario it appeared first.
... View more
β11-30-2017
12:08 AM
Hi again @saranvisa, I checked the logs and I saw that the error that I was getting on starting a service was caused from a certain process so I got in that directory and looked for the error on hdfs.keytab. When doing the klist -kt hdfs.keytab I got the principals list, tried to make a kinit with one of them and it worked well. What I've seen is that the imported keytabs I was trying to klist were some old keytab files, modified few weeks ago, and the logs gave me the clue on which directory test the keytab files. So we are at the same point, seems that krb5-workstation commands work fine, keytabs were generated right and the service keeps outputing the same error again and again. Some more ideas to test? Thank you
... View more
β11-29-2017
11:48 PM
Hello @saranvisa I tested it again after doing a regenerate keytabs and when doing the klist -kt I got the next message. # klist -kt hdfs.keytab
Keytab name: FILE:hdfs.keytab
klist: Unsupported key table format version number while starting keytab scan This is not the same for other keytab files in other directories into /var/run/cloudera-scm-agent/process just for some of them. Any idea of what's happening? Why some processes are getting empty keytab files? I don't understand. Thank you for the help
... View more
β11-29-2017
08:01 AM
@saranvisa Yes I've done all the steps in multiple ocasions, kinit command works fine with the keytabs imported but HDFS continues writing that error in logs.
... View more
β11-28-2017
11:15 PM
Sorry, worked the kinit command, Cloudera keeps giving the first mentioned exception.
... View more
β11-28-2017
08:17 AM
Sorry for the late response. I did that and it worked with kinit and an imported keytab Thank you
... View more
β11-15-2017
05:42 AM
Yes, the realm name is in uppercase, the same as in the examples
... View more