Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

Kerberos client failing on a client in cluster

avatar
Super Collaborator

I am enabling Kerberos in Ambari and its failing on one of the clients in a 5 node cluster with the error below

capture1.jpg

1 ACCEPTED SOLUTION

avatar
Super Collaborator
@Sami Ahmad

configure-kerberos.pngWhen enabling Kerberos on "configure Kerberos" page () please verify that all mandatory fields have been entered with correct value specially realm name. The value of realm name should be same as present in /etc/krb5.conf file on manually installed KDC server host

After that verify that "Test KDC Connection" works ok.

Verify that the admin principal and keytab that you have entered on this page can kinit successfully with the KDC server.

Hope this helps isolate the issue.

if you have customized any non-mandatory configuration on this page, please let us know so we can consider to analyze this issue.

View solution in original post

11 REPLIES 11

avatar
Super Collaborator

The error indicates that the KDC is not reachable here. Is the KDC server up ? You will need to check on that . Try doing a telnet or nc to the KDC server from the client node as below:

 nc -vz kdc_host 88

Eg: [kafka@ambari-slave1 SimpleJava]$ nc -vz ambari-slave2 88
Connection to ambari-slave2 88 port [tcp/kerberos] succeeded!
[kafka@ambari-slave1 SimpleJava]$

[kafka@ambari-slave1 SimpleJava]$ telnet ambari-slave2 88
Trying 192.168.59.13...
Connected to ambari-slave2.
Escape character is '^]'.
^CConnection closed by foreign host.
[kafka@ambari-slave1 SimpleJava]$




avatar
Super Collaborator

Also cross verify the /etc/krb5.conf to see if its set up right

avatar
Super Collaborator

the file exists on all nodes

[root@hadoop4 ~]# ls -al /etc/krb5.conf -rw-r--r--. 1 root root 553 Dec 28 14:12 /etc/krb5.conf [root@hadoop4 ~]#

avatar
Super Collaborator

yes its up , since other 4 clients have no issues . and also this node I can connect to port 88 on hadoop1 where kdc server is running

[root@hadoop1 ~]# /etc/rc.d/init.d/krb5kdc status
krb5kdc (pid  4908) is running...
[root@hadoop1 ~]#
[root@hadoop4 ~]# nc -vz hadoop1 88
Connection to hadoop1 88 port [tcp/kerberos] succeeded!
[root@hadoop4 ~]#



avatar
Super Collaborator

in the Install document of Kerberos there is no mention of what to do on client , how can I check if the client is ready to be a Kerberos client ?

avatar
Super Collaborator

Can you check and compare the o/p for /etc/krb5.conf from the working node and the non working node?

avatar
Super Collaborator
@Sami Ahmad

configure-kerberos.pngWhen enabling Kerberos on "configure Kerberos" page () please verify that all mandatory fields have been entered with correct value specially realm name. The value of realm name should be same as present in /etc/krb5.conf file on manually installed KDC server host

After that verify that "Test KDC Connection" works ok.

Verify that the admin principal and keytab that you have entered on this page can kinit successfully with the KDC server.

Hope this helps isolate the issue.

if you have customized any non-mandatory configuration on this page, please let us know so we can consider to analyze this issue.

avatar
Super Collaborator

hi Jaimin all the steps you mentioned are for the KDC server , not the client . and all these steps are fine and correct as you said they should be.

if they were not correct the 3 other clients would not get installed right ? There must be somethings that Kerberos is expecting on the client hadoop4 which is missing and thus the Kerberos client fails to install there.

avatar
Super Collaborator

Hi @Sami Ahmad

As per the attached screenshot you are getting error in the "Check Kerberos" action from one of the randomly selected client host by the ambari. It seems that install kerberos client went ok on all nodes. Its the kerberos service check that failed and so I believed issue was not on any particular client host.

In this case if ambari would have selected any other kerberos client host to do service check, then the action would have failed even on that host.